Як зробити гру? [зачинено]

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

Як ви підтримуєте зацікавленість розвивати гру чи розвиватися взагалі?

Як дизайнер я схильний розглядати людей як колекцію статистичних даних та змінних. Коли ви ставите своє запитання, я можу легко зрозуміти, як [Pong_Dev_Interest] зменшується і [Spa_Inv_Dev_Interest] збільшується. Коли різниця між двома більша, ніж [Dev_Project_Inertia] (дещо пов'язана з [Dev_Completion_Desire]), активізація на [Pong_Dev] зупиняється і [Spa_Inv_Dev] починається.

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

Коли вам нудно, продовжуйте працювати. Коли це буде чудово, продовжуйте працювати. Коли впаде лайно, продовжуйте працювати! Наполегливо! Будьте маленьким чортом, який міг! Я вірю в тебе!

Ахм. Там трохи перенапружений. Але ви отримуєте дрейф.

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

І це буде відчувати себе так goooooood.

Я завжди задаю собі одне і те ж питання, і є кілька речей, які ви можете зробити, щоб мотивувати себе (багато з них уже розміщено тут). Що добре для мене - це те, що я чув на одному з переговорів з Інді на цьогорічному GDC, я думаю, що це був хлопець, який робив гру в Монако :-)

По-перше, знайдіть проект, який добре відповідає вашому досвіду. Тобто не починайте робити FPS, якщо ви навіть не знаєте основ OpenGL / DirectX. (якщо тільки ви не використовуєте ігровий движок, але тут справа не в цьому ;-))

Потім складіть собі список дій, які потрібно зробити, і важливих етапів, яких ви хочете досягти, щоб ви завжди знали, куди йти. TODO - це важлива частина. Визначте свої завдання так, щоб кожне завдання можна було легко виконати в день або за пару годин . Отже, коли ви починаєте кодувати, проектувати, моделювати і т. Д., Ви вже бачите світло в кінці тунелю. Ніщо не пригнічує, ніж розробити і кодувати ваш великий Game Engine протягом місяця, не наближаючись до фінішної лінії. Розбийте великі завдання на більш дрібні. Виконання завдання швидко дійсно корисне і продовжує продовжувати роботу. Наприклад, це був мій список завдань для невеликої гри в космічну стрілку свого часу:

• Звукові ефекти
• Музика
• Переробити корабель
• Переробляти ракети
• Виявлення колізії між пострілами та гравцем / ворогом
• Змусити ворогів стріляти
• Титульний екран
• Оцінка / Життя / Енергія Що б не наклала

Усі ці завдання було легко виконати, і коли вони працюватимуть у грі, ви можете переглядати ці ділянки та відполірувати їх.

І ось я закінчив маленьку гру. Це не дуже, але це в основному зроблено, що було дійсно корисним у підсумку :-)

Ви повинні визначити проблему, перш ніж ви зможете її вирішити. Чому ви втрачаєте інтерес?

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

Один із способів я можу вдосконалити мотивацію - це зробити ітеративне прототипування чи якусь форму розробки тестових програм. Зазвичай це включає автоматизацію тестових випадків, але оскільки ігри є інтенсивними графікою, ви не можете автоматизувати екрани та анімацію як тести, але ваша логіка гри може бути автоматизована.

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

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

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

Дивіться цю та цю іншу публікацію.

Якщо ви не знаєте, як правильно структурувати гру, ви повинні почати вчитися абстрагувати їх елементи в незалежні від ігор блоки. Це може допомогти вам багатьма способами (окрім цікавого), такими як: поділ абстракцій від реалізацій, краща експлуатація спадщини та дизайну інтерфейсів, або просто як розмістити гру в декілька файлів, щоб вона виглядала професійно (або надавала доцільність реалізацій за допомогою використання динамічних бібліотек зв’язків або інших застосувань інтерфейсу). Рано чи пізно ви зрозумієте, що все можна зробити, і тоді вже опинитеся без проблеми мотивації (ви просто це зробите).

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

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

Спочатку ви повинні спробувати виправити помилку за допомогою налагоджувача, але я не знаю, чи ваша мова навіть підтримує відладчик ... але якщо ви випадково використовуєте C ++ або щось подібне (що я рекомендував би, якщо ви хочете зробити ігри), ви повинні краще використовувати свій налагоджувач, оскільки це дуже допоможе вам швидко знайти помилку за один пробіг.

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

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

PS Мені було цікаво ... що ви використовуєте для створення гри?

[мав на увазі залишити коментар до відповіді Анона, який був видалений під час публікації. Він зазначив, що він функціонував усіма цими функціональними можливостями, а потім розділив код одного файлу на кілька файлів, тільки для того, щоб все розпалося]

Re: рефакторинг, речі можуть трапитися навіть до профі. Іноді навіть при використанні хороших інструментів, таких як Git, злиття може бути невдалим, тому замість функції A та B функціонує як робота, так і робота! Єдиний вибір - повернутися до А та спробувати ще раз. На щастя, контроль версій збереже цей код для вас; якщо ви не використовуєте реальний контроль версій, принаймні робіть це вручну, регулярно перетягуючи папку Dev - простору в HD просто недорого! На закінчення поверніться до того, що працює і рефактор меншими кроками, переконайтесь, що гра все ще працює на кожному кроці. Очищати код дійсно гнітюче, лише щоб побачити, як все розпадається. Просто поверніться до старого коду.

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

Щоб проілюструвати мою думку, я можу вам сказати, як часто йдуть справи: спочатку ви створюєте кілька спрайтів, переміщуєте їх на екрані зі своїм прото-рамкою і ви в захваті! Ви можете бачити свій прогрес, і він іде добре; ви можете показати своїм друзям.

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

Отже, пам’ятайте: створюйте ігри, а не ігрові двигуни. Тільки рефактор, коли потрібно. Не будьте занадто гнучкими - просто мінімум. *

*: звичайно важливі рефакторинг та гнучкість. Але не так важливо, як насправді мати закінчену гру.

Спробуйте зробити програвальну версію за день, неважливо, наскільки просто. Потім повторіть.

1. Не намагайтеся зробити свою гру занадто складною!

2. Розділіть своє завдання на невеликі, конкретні, вимірювані підзадачі. Якщо якийсь підзадач здається занадто великим, тоді підрозділіть його далі.

3. Переконайтеся, що ви пишете "ЗРОБАНО" великими літерами у своєму списку завдань (я використовую .txt файл), коли ваше завдання виконано. Не знімайте завдання, бо тоді це не виглядатиме так, як ви прогресуєте.

Це я і роблю. Це працювало в минулому.