Проектування гри - з чого почати? [зачинено]

Ми з другом плануємо разом грати над тим, щоб попрацювати у вільний час. Це не велика гра, але і не проста.

Він працює над історією гри, поки я працюю над графікою та кодом.

Я насправді не знаю, з чого почати гру. Ми знаємо, який основний тип гри буде і як це буде грати, але мені важко насправді знати, з чого почати.

У мене відкритий Xcode, але я навіть не знаю, що я повинен розробляти.

Яка порада для блоку цього письменника? З чого вдало почати з гри? Чи повинен я створити всю графіку та макет, перш ніж навіть торкнутися Xcode? Чи повинен я програмувати те, що знаю, у мене виникнуть труднощі з першим, перш ніж перейти до легких речей?

Почніть з того, щоб щось підняти та відтворити. Не витрачайте більше години на графіку, просто візьміть гру зі сміттями. Ігри не мають об'єктивних вимог, до яких слід скласти: ключова вимога полягає у тому, щоб вона була веселою, і оцінювати, чи гра весела чи не вимагає її грати; як результат, дизайн гри повинен дотримуватися ітеративного підходу. (Рекомендую Тома Вуеца щодо завдання зефіру як орієнтацію на ітеративний дизайн.

Створіть щось на папері, і під цим я маю на увазі зробити макетну дошку та вирізані шматки. Складіть правила та пограйте у свою гру на макеті з паперу. Використовуйте це, щоб розбити свій дизайн коду на набори функцій та модулі, над якими можна працювати. Цей процес допоможе вашому другові створити історію та як працює гра теж.

Можливо, ви захочете записати додаткові функції у свій код, уникайте цього. Ви прототипуєте, щоб побачити, що буде працювати.

Як тільки у вас є невеликий шматок, який ви працюєте, ви повинні працювати повторно, і на кожній ітерації отримуйте ще одну функцію. Коли щось не добре грає, повертайтеся та змінюйте функції. Продовжуйте змінювати і змінювати.

Основна ідея полягає у створенні довгострокового бачення, заснованому на макеті з паперу, і з цього випливає низка короткотермінових цілей, щоб працювати над тим, щоб ви потрапили туди, куди ви хочете піти за часом і без стресу " omg, що мені робити далі? "

Спершу оцініть свої вимоги. Кодування без плану створює багато відходів пізніше.

Що гра потрібно функціонально робити? Які рамки вам потрібні, щоб зробити цю роботу? Які елементи можна запозичити з існуючих рамок, і що потрібно написати самому?

Перш ніж відкрити Xcode, це може допомогти просто зробити вирізи з паперу та спочатку пройти всі ігрові інтерфейси та діалоги. Це дасть вам деяке уявлення про те, що потрібно створити в Interface Builder.

Далі, як взаємодіють речі? Які потрібні виразні стилі взаємодії? Це має дати вам деяке уявлення про те, як потрібно розповсюджувати, запускати та зупиняти контролери.

Не плануйте це до смерті, але чітко визначте свої вимоги, і як тільки ви зможете розбити проект на шматки розміром (30 хв. На 1 годину), ви готові розпочати кодування.

Дивлячись на 2 дні, 2 тижні або, що ще гірше, два місяці завдань, пов’язаних із боротьбою, спричиняють бій чи реакцію на політ. Розбийте його на досить маленькі шматки, які ви зможете відкусити один одного послідовно, не задушившись, і я здогадуюсь, що ви точно знатимете, з якого укусу почати, а з якого піти далі.

Якщо гра повинна вписатися в існуючий жанр, або вона якось схожа на іншу гру, просто спробуйте зробити грубу, просту імітацію цієї гри або зробити «типовий» приклад жанру. Якщо ви не хороший кодер, дотримуйтесь навчального посібника, який допоможе вам провести гру, схожу на вашу.

Через деякий час ви, природно, відчуєте бажання «розходитися» зі своєю моделлю та починати вести гру у власному напрямку. Звідти йде низхідна дорога: додайте туди функцію, виправте помилку тут і загалом покращуючи невеликими кроками.

Якщо є певна концепція, яка певним чином унікальна для вашої гри, ви також можете почати з побудови найпростішої демонстрації цієї концепції. Існує також можливість просто побудувати свою гру навколо цієї концепції.

Зробіть те, що дає вам відтворюваний прототип якомога швидше.

Перші 1-2 тижні ви, мабуть, не можете скласти хороших оцінок, тому що ви новачок у двигуні. Тому в перший тиждень (ів) це, мабуть, марна трата часу, щоб робити кошториси. Але зауважте час, який ви витратили на речі, так що у вас є досвід, на якому ви можете базувати свої перші оцінки. Після цього починайте планувати, оцінювати та встановлювати пріоритети!

Три речі, які я дізнався за останні 6 місяців, коли я був частиною невдалого ігрового проекту (мені заплатили за те, щоб розробити логіку ігор):

1. Не змінюйте свій план щодня! Очевидно, що добре пройти спритний шлях, але якщо ви в кінцевому підсумку змінюєте цілі щодня, явно щось не так.
2. Слідкуйте за часом, який ви витрачаєте на роботу. Порівняйте прогнозований та ефективний час. Спочатку ви, мабуть, відзначите велику різницю, але з часом ви зможете робити кращі оцінки.
3. Враховуйте оцінки, встановлюючи пріоритети.

Важливо: час від часу огляньте проект і подивіться, що пішло добре, а що пішло не так. Я думаю, ви можете визначити частини, де ви витратили занадто багато часу на щось не потрібне. Спробуйте залишити такі речі наступного разу. (Наприклад: Якщо ви працюєте над гаджетом, який ваш гравець може використовувати 1 або 2 рази в грі протягом 2 секунд, не витрачайте на реалізацію цілий місяць.)

Якщо ви не знаєте, як правильно розробити проект, я пропоную прочитати розділ 1 «Мислення Брюса Еккеля на C ++» (книга безкоштовна), є розділ «Аналіз та дизайн». Це гарне вступ.

Не забудьте оформити мислення Брюса Еккеля в C ++ том 2 .