Каковы основные подводные камни, которые следует учитывать при разработке новой игры?

На самом деле я только начал отслеживать (спасибо Дэвиду Янгу за исправление номенклатуры) пару новых веб-игр для Facebook несколько недель назад, и я только что был завален ментальными блоками и отстранением от перекодирования. Я работаю над чем-то похожим на пошаговую (Vampire Wars) стиль RPG. У меня есть навыки написания кода для игры, но я пытаюсь найти правильные шаблоны дизайна и сделать так, чтобы продукт соответствовал тому, что я вижу в уме.

Обычно, когда я создаю веб-сайт, мне нравится «думать в коде», и я нахожу более быстрым для меня просто изменить код / ​​HTML, чтобы настроить его. Это, вероятно, потому, что я ОЧЕНЬ комфортно в том, что я делаю, и я знаю, чего ожидать как я делал это снова и снова. На этом этапе разработки игр я снова начинаю писать на бумаге (как я привык к веб-сайтам), и мне интересно, не является ли это просто моим недостатком внимания и интуиции к игровой логике, или это подходящий способ высказать свои мысли в продвижение кодирования.

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

расширенный

Например, боевой движок, который в последнее время доставлял мне много проблем, берет простой навык атаки, а затем делает случайный бросок между -50% и + 50%, а затем умножает первоначальный навык атаки на этот процент. То же самое делается с защитой, а затем я объединяю их, чтобы определить, нанесен ли какой-либо урон здоровью противника. Я предполагаю, что должен осознать, что я нахожусь над своей головой, когда я начал спрашивать себя, является ли это даже правильным способом сделать это, или есть ли даже «правильный» путь. Одна из основных ошибок, которую я обнаружил, заключается в том, что два персонажа одного уровня могут иметь несколько «бросков», когда атака составляет -50%, а защита составляет + 50%, поэтому я получаю несколько ЧРЕЗВЫЧАЙНЫХ длинных последовательностей сражений, где никто ничего не делает. ПРОВАЛ

Возможно, мой пост должен был запрашивать ссылки, описывающие простую игровую логику.

Конец расширение

Спасибо всем заранее!

добавив слишком много функций. Сосредоточьтесь на ядре игры, постройте его, а затем, если все работает хорошо, добавьте функции. Люди слишком сосредоточены на добавлении интересных вещей и никогда не делают ничего.

Это отличная статья о том, как создать прототип игры. По твоему вопросу кажется, что тебе не хватает представления о том, каким должен быть прототип.

Прототипирование: вы (вероятно) делаете это неправильно

Вставка:

Ошибка № 4: Создание системы, а не игры
Когда вы создаете прототип, если вы когда-нибудь обнаружите, что работаете над чем-то, что не продвигает вас вперед, остановитесь прямо здесь. Как программисты, мы склонны пытаться обобщать наш код, делать его элегантным и уметь справляться с любой ситуацией. Мы считаем, что зуд ужасно трудно не поцарапать, но нам нужно научиться. Мне потребовалось много лет, чтобы понять, что дело не в коде, а в игре, которую вы поставили в конце.

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

Редактировать:

Я добавляю это просто чтобы прояснить разницу между Prototype и Tracer Code.

Всегда помните: прототип предназначен для выбрасывания! Код трассировки нет.

Подводный камень прототипа

... Подход кода трассировки решает другую проблему. Вам нужно знать, как приложение в целом висит вместе. Вы хотите показать своим пользователям, как взаимодействия будут работать на практике, и вы хотите дать своим разработчикам архитектурный каркас, на котором можно повесить код. В этом случае вы могли бы создать трассировщик, состоящий из тривиальной реализации алгоритма упаковки контейнера (может быть что-то вроде «первым пришел - первым обслужен») и простого, но работающего пользовательского интерфейса. После того, как все компоненты приложения объединены, у вас появится структура, которая будет показана вашим пользователям и разработчикам. Со временем вы добавляете в этот фреймворк новую функциональность, выполняя подпрограммы с заглушками. Но структура остается неизменной, и вы знаете, что система продолжит вести себя так, как она делала, когда ваш первый код трассировки был завершен.

Различие достаточно важно, чтобы оправдать повторение. Прототипирование генерирует одноразовый код. Код Tracer скудный, но полный и является частью остова конечной системы. Думайте о прототипировании как о разведывательном и разведывательном сборе, который происходит до того, как будет выпущена одна трассирующая пуля.

Дополнительная информация о дизайне кода Tracer от программиста Pragmatic

Tracer Bullets and Prototypes

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

Из вашего комментария к посту Джо:

Вы хотите, чтобы я закодировал боевой двигатель для встреч с монстрами, БУМ! Я переписывал свой двигатель по крайней мере три раза на этой неделе, и я никогда не чувствую себя хорошо по этому поводу. Я имею в виду, что математика работает, но когда я ее пробую, то чувствую себя вялой. Имеет ли это смысл?

Похоже, вы связываете движок с данными здесь. Ваш двигатель столкновения с монстром должен быть основан на данных. Если данные, которые влияют на ваш игровой баланс / веселье, неверны, вам не нужно полностью переписывать ваш движок - просто настройте переменные баланса, пока он не покажется правильным.

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

Чтобы проверить, что ваши недавно настроенные данные не испортили целую кучу других случаев, полезно сохранить несколько тестовых примеров и убедиться, что они не повреждены после настройки. Вот замечательный пример того, как вы это проверите.

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/

Он тоже программист. Его эксперименты по образу жизни вызвали интерес некоторых СМИ.