Відповіді:
Прототип. Спробуйте втілити свою концепцію гри, використовуючи якийсь інструмент швидкої ітерації. Спробуйте python або просто легкий у роботі з api з відкритим кодом, щоб запустити "ідею гри". Постарайтеся максимально спростити, використовуйте кульки замість символів, опускайте зір на якесь візуальне зображення. Таким чином, ви завжди можете на це подивитися, обговорити, обговорити і дати відгуки. Поставте встановлену часову шкалу для кожного прототипу (можливо, 2 дні? Можливо тиждень вершини?). Таким чином, ви повинні зробити лише стільки, скільки ви хочете зробити в прототипі.
Іноді, можливо, ви зможете побудувати свою ідею на маленькому аркуші паперу, якщо це досить просто. Після того, як ви встановите свою ідею, почніть планувати, щоб побачити, які саме системи та механіка вам потрібні. Постарайтеся структурувати часові рядки для речей і дізнайтеся, чи можна їх виконувати. Якщо ви - купа людей, які хочуть зробити гру разом, вам потрібно зробити це разом. Робіть це за пивом особисто або за допомогою програми голосового чату. Як тільки ви знаєте, що робити - кожен може почати з того, що робить. Переконайтеся, що у вас є спілкування. Постарайтеся провести зустрічі команди з частим інтервалом залежно від того, скільки часу ви хочете відкласти.
Якщо ви займаєтеся власною грою, пам’ятайте, що час обмежений, і ви не можете все зробити прекрасно. Можливо, сфер і кубів буде достатньо, щоб графіка вийшла, якщо ви програміст. Усвідомлюйте свої обмеження та працюйте з ними, а не проти них.
Я сподіваюся, що ці кілька порад допоможуть :)
Як викладач, я бачу багато проектів хобі студентів, які провалюються. Незмінно найвищою причиною невдачі є перебіг: проект починається, коли це грандіозне бачення величезної речі, яка занадто велика, щоб можливо завершити, все більше людей виховуються, поки вона не руйнується під вагою власного дизайну, і всі залишає почуття розчарування та деморалізації.
Найкращий засіб для цього - безжально обмежувати свою сферу. Замість того, щоб сказати, "як мені тримати енергію достатньо, щоб закінчити довгий проект?" замість цього вам слід сказати "як я розробити проект, який досить короткий, щоб я міг його закінчити, перш ніж мені набриднути?"
Події "ігрового заклинання" (всілякі речі, що складаються з гри у вихідні) - це чудовий спосіб розпочати роботу, і вони чудово підходять для побудови хороших звичок під час створення швидких прототипів. У WORST ви проводите вихідні, роблячи веселу гру ... ви, напевно, щось навчилися в процесі ... І ви заощадили собі кілька місяців роботи над ідеєю, яка в кінцевому підсумку не була такою крутою, як ви спочатку думали. У кращому випадку ви виявите, що у вас є щось дійсно особливе, і ви можете почати додавати невеликі функції по одному, поки у вас не буде повноцінний проект.
У моїх власних невеликих хобі-проектах, інше, що я виявив, що допомагає, - це почати з повного списку всіх відомих завдань розвитку, які потрібно виконати, замовити та зменшити, щоб кожне окреме завдання було виконано і перевірялось 30 - 60 хвилин, верхівки. Це дуже наполегливо зробити невелике завдання, побачити, як він працює в грі, і перекреслити його зі списку ... що потім просто робить це набагато ймовірнішим, що я зроблю наступне в списку, оскільки останній був так легко, а потім наступне ... подібне до вживання в їжу картопляних чіпсів.
Ще одна підказка: щоразу, коли ви успішно реалізуєте нову функцію, зробіть резервну копію (або використовуйте керування вихідним кодом, що в основному одне і те ж, але не кожен використовує керування джерелом, якщо це лише вони працюють над власним особистим проектом). Таким чином, якщо ви повністю викручуєте код о 2 ранку і не можете зрозуміти, як повернути його в робочий стан, проект не мертвий і не потрібно його перезапускати з нуля; натомість ви просто повертаєтесь до останнього завершеного і працюючого рубежу та намагаєтесь знову.
Я б сказав, що дійсно важлива річ - це завжди щось показувати.
Я маю на увазі, ви могли витрачати віки та епохи в системі сутностей, керованих даними, із відкладеною візуалізацією та дійсно високим FPS, і все це. Але ймовірно, що вам буде нудно, що нічого не показувати, і відмовитеся. Якщо ви спершу спробуєте отримати кілька моделей на екрані, перемістити їх і піти звідти, у вас буде набагато більший шанс.
Я думаю, що перший - це розвиток знизу вгору; робота від рамки до фактичного контенту, а друга - зверху вниз; працюючи над отриманням деякого вмісту та надбудовою звідти.
Трохи, але щось, що справді допомагає.
Як самотній розробник, я вважаю, що це допомагає реалізувати звук на початку. Я вважаю, що це мотивує мене більше працювати над іншими можливостями, оскільки навіть у перші кілька тижнів (з графікою, обмеженою яскравими кольорами багатокутників, виявленням лускатих зіткнень, відсутніми елементами управління тощо) звук все ще дає відчуття «майже там . "
Я колись працював над проектом, який, здавалося, все зробив правильно. Вони створили веб-сайт / дошку оголошень для всіх, хто працює над проектом. Вони представили всім конкретні строки та цілі, і сама гра була гарною концепцією. Незважаючи на це, люди все-таки пройшли лише близько 2 місяців, щоб люди почали випадати з карти. Через 3 місяці розробка була закінчена і гра так і не була завершена.
Тож якщо ви працюєте в команді, то, я думаю, вам потрібен стимул. Вам потрібно, щоб хтось постійно контактував з усіма, переконуючись, що вони виконують роботу, та нагадуючи їм, чому вони хочуть продовжувати це робити.
Якщо ви працюєте поодинці; Я не надто впевнений. Мені страшно з творами мистецтва і т. Д., Тому я переважно зосереджуюсь на стороні двигуна. Цього завжди достатньо, щоб зацікавити мене :)
Розробники завжди скажуть вам не переходити на нові області, поки ви не закінчите ту, над якою працюєте зараз. Якщо ви намагаєтеся створити гру самостійно, я не думаю, що це занадто грізно, якщо ви вирішите порушити це правило. Робота над чимось свіжим - це хороший спосіб підвищити рівень хвилювання!
Є багато хороших відповідей, але я додам і свою:
Я хотів би трохи розширити останній пункт, оскільки я бачив, що це відбувається неодноразово: ніколи не будуйте основу спочатку. Причин багато, але в основному у вас не буде необхідного бачення, щоб зробити все правильно, ви витратите багато часу на роздуми про те, що - якщо ви втратите мораль, коли після X днів / тижнів роботи буде нічого для цього не показувати.
Проблема полягає в тому, що рамки часто потрібні кінцевому продукту, тож що робити кодер? Починайте будівництво конкретно, із жорсткими кодованими значеннями. Коли вам потрібно буде змінити значення, зробіть його змінним у параметрах. Коли вам потрібно зробити дві подібні речі, абстрагуйте подібні частини разом, але решту слід зберегти конкретними. Якщо ви продовжуєте це робити, ви фактично закінчитеся рамкою, яка зароджується через необхідність, замість того, щоб спочатку витрачати час на те, що робити.
Після того, як ви побудуєте X-й гру, ви зможете подумати, що почати з рамки, до цього часу у вас буде достатньо досвіду, щоб зняти її.
У мене було два-три зошити, варті ідеї, перш ніж я почав розробляти свою першу гру. Я кілька місяців грав у подібні ігри для дослідницьких цілей - визначаючи, які риси мені подобалися чи не подобалися. Я, як правило, намагаюся спершу зосередитись на механіці і пізніше вирішувати зовнішній вигляд (але будучи обережним, щоб не ігнорувати зручність використання). Я рекомендую мати грубний, але ретельний дизайн, перш ніж зануритися в розробку. Не намагайтеся забивати кожну деталь занадто рано, оскільки ваш дизайн обов'язково розвиватиметься для вирішення питань відтворення, обмежень технологій тощо.
Переконайтесь, що ваша ідея сповнена мозковим штурмом та записом деяких ключових цілей дизайну. Я проходжу процес, який я називаю в пошуку гри «душа». IE, що є основною причиною, коли я роблю цю гру. Звідси я формулю ще кілька концепцій та ідей, які підтримуватимуть цю головну мету. Весь цей процес може зайняти години, дні, тижні чи довше, залежно від того, як ідея приходить до вас.
Звідси вийдіть щось видиме і кінетичне. Я вважаю, що вміти грати з грою та отримувати від неї зворотній зв'язок є життєво важливим фактором у підтримці мотивації. Я схильний реалізовувати візуальні та звукові ефекти, а також просту обробку вводу та обробку просто так, що щось відбувається ', і це відчувається як реальність, а не мрія.
Незалежно від того, як йде ваша стратегія розвитку, я не можу наголосити достатньо, щоб ви не зациклювалися на спробі розробити і кодувати ігровий «двигун». Кожна функція, яка не має видимого або тактильного впливу на гру, запропонує дуже невелику винагороду. Щоб допомогти це компенсувати основними основними системами, розмістіть інформацію про розробку на екрані. IE FPS, змінні AI та будь-який інший текст, який допоможе виявити, що там є щось, чого раніше не було. Немає нічого більшого, ніж витратити 10 годин на кодування системи, компілювати та мати такий самий досвід, як і раніше.
Я написав статтю кілька років тому про те, як знайти свою ігрову душу, яку ви можете зацікавити тут: http://deleter.phatcode.net/index.php?page=articles&a=8
редагувати: І ще одне, що я бачу згадане в іншому дописі, про яке я хочу розглянути. Грайте в ігри не тільки під час проектування своєї гри, але й у будь-який час ви не дуже вмотивовані працювати над власною грою. Я вважаю, що грати в подібні ігри допомагає мені запам'ятати, чому я хочу заробляти свою гру, і допомагає дати мені той додатковий імпульс, який мені потрібно продовжувати.
Крім того, ви можете створити "банк натхнення" з картинок, відео, музики та звукових кліпів, які містять елементи того, що ви хочете вкласти у свою гру. Кожен раз, коли вам потрібен напрямок, поверніться до цих джерел, щоб допомогти керувати своїми рішеннями. Це допоможе вам бути вмотивованим і в курсі.
Почніть з ігрової концепції, встановіть причину гри, геймплея, вигляд гри, яку ви хочете зробити.
Звідти ви можете почати складати функції та списки активів, щоб програміст та художник могли принаймні почати працювати над чимось, в той час як дизайнер займається деякими думками чи налаштуваннями ігрової механіки.
Таким чином, ви принаймні маєте трохи коду та активів протягом декількох днів або тижнів, щоб підвищити мораль і розпочати проект.
s/moral/morale
Для мене це допомагає подумки "скласти" карту ідеї гри перед її запуском. Я спробую розібратися в головній механіці, базовій структурі внутрішньої гри, можливо, трохи деталей про те, як я хочу, щоб вона працювала. Тоді я наношу гуму на дорогу, і починаю роботу, згинаючи або ламаючи частини моєї ментальної карти, де код потребує іншого налаштування. Я можу записати деякі речі (посилання, можливо, ключові особливості), але в цей момент дизайн зазвичай занадто сильно зміщується, щоб документ був корисний.
В іншому випадку я якось зупинився з тим, що закінчується як провальний проект на початку: /