Які найбільші підводні камені слід враховувати при розробці нової гри?

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

Зазвичай при створенні веб-сайту мені подобається «думати в коді», і мені здається, що мені швидше просто змінити код / ​​HTML, щоб його змінити. Це, мабуть, тому, що мені ДУЖЕ комфортно в тому, що я роблю, і я знаю, що чекати як я робив це знову і знову. У цей момент з розвитком ігор я знову починаю з паперу (як я звик із веб-сайтами), і мені цікаво, чи це лише моя відсутність уваги та інтуїції з ігровою логікою чи це правильний спосіб розгорнути свої думки заздалегідь кодування.

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

Розширений

Наприклад, бойовий двигун, який видає мені стільки проблем, останнім часом використовує просту навичку атаки, а потім робить випадковий відкат між -50% і + 50%, а потім примножує початковий навик атаки на цей відсоток. Те ж саме робиться із захистом, а потім я забиваю тих, щоб визначити, чи завдано шкоди здоров’ю противника. Я думаю, я повинен усвідомити, що я перебуваю над головою, коли я почав запитувати себе, чи це навіть правильний спосіб зробити це, чи існує навіть "правильний" шлях. Однією з головних помилок, які я виявив у цьому, є два символи, що знаходяться на одному рівні, можуть мати декілька "роллів", коли атака становить -50%, а захист - 50%, тож я закінчую деякими НАДЗВИЧНО довгими бойовими послідовностями, де ніхто нічого не робить. НЕПРАВНО

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

Кінцеве розширення

Дякую всім заздалегідь!

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

Це чудова стаття про те, як прототипувати гру. З вашого питання, схоже, ви пропускаєте уявлення про те, яким повинен бути прототип.

Прототипування: Ви (певно) робите це неправильно

Розмиття:

Помилка №4: Створення системи, а не гри
Під час створення прототипу, якщо ви коли-небудь працюєте над тим, що не рухається безпосередньо вперед, зупиніться прямо там. Як програмісти, ми схильні намагатися узагальнити наш код, зробити його елегантним та вміти впоратися з будь-якою ситуацією. Ми виявляємо, що свербіж страшенно важко не подряпати, але нам потрібно навчитися. Мені знадобилось багато років, щоб зрозуміти, що справа не в коді, а в грі, яку ти зрештою відправляєш.

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

Редагувати:

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

Завжди пам’ятайте: Прототип призначений для викидання! Tracer Code - ні.

Прототип Опад

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

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

Детальніше про дизайн коду Tracer Code від Прагматичного програміста

Кулі та прототипи слідів

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

З вашого коментаря до публікації Джо:

Ви хочете, щоб я кодував бойовий двигун для зустрічей з монстрами, БУМ! На цьому тижні я переписав свій двигун щонайменше три рази, і ніколи не відчуваю цього добре. Я маю на увазі, математика працює, але коли я спробую це, я просто відчуваю неприємність. Чи має це сенс?

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

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

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

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

Напр. Якщо ви будете називати це за допомогою PlayerStats.Level == 5 та MonsterStats.Level == 3, ви очікуєте, що гравець завжди переможе цього монстра.

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

Відповідь, шукайте ресурси щодо дизайну ігор та ігрового балансу. Насправді є університети, які присвячують цілу чотирирічну програму навчання темам, які ви піднімаєте, тому просто дати вам швидку та брудну відповідь неможливо (так само, як ви, мабуть, заступитесь, якби хтось сказав " так, у мене є така ідея для гри, але я не знаю, як її запрограмувати, на що слід стежити? "). Є книги, курси та онлайн-статті про дизайн гри; шукати їх.

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

Я рекомендую статті Стіва Павліна про управління часом та самомотивацію: http://stevepavlina.narod.ru/

Він теж програміст. Його експерименти з стилем життя викликали певний інтерес до ЗМІ.