Какие есть хорошие ресурсы по дизайну игрового движка в 2D?

Сделайте игру. После того, как вы закончите, сделайте еще один. Посмотрите, что вам понравилось, а что не понравилось, а затем сделайте еще одно.

Если серьезно, вы можете прочитать все руководства по «передовому опыту» по игровому дизайну, которые вам нужны, но в конечном итоге все сводится к опыту. Единственный способ получить опыт - это сесть и написать игру. Сделав это несколько раз, вы получите лучшее представление о том, как писать игру.

Практически любая книга, одним из авторов которой является Андре Ламот.

Разработка игр также имеет массу статей.

Обычно я обращаюсь к Gamedev.net, чтобы получить представление о том, что делают другие люди в сообществе разработчиков игр.

Тем не менее, я боюсь, что вы обнаружите, что идея «лучших практик» в разработке игр более изменчива, чем большинство других. Игры, как правило, являются настолько специализированными приложениями, что практически невозможно дать какой-либо универсальный ответ. То, что отлично работает для Тетриса, окажется бесполезным с Астероидами, а модель, идеально подходящая для Halo, скорее всего, потерпит неудачу для Марио.

Вы также быстро обнаружите, что не существует такого понятия, как «отраслевой стандарт» для форматов текстур, сеток, уровней, звука или анимации. Каждый просто катится самостоятельно или использует то, что удобно для платформы. Иногда вы видите такие вещи, как КОЛЛАДА, что приятно, но все же это всего лишь промежуточный формат, предназначенный для упрощения написания экспортеров.

Если вы новичок в разработке игр, мой совет будет следующий: не убивайте себя из-за структуры кода с первого раза. Попробуйте простую игру, например, астероиды, и продолжайте рубить, пока она не сработает, каким бы «уродливым» ни был код. Используйте простые форматы, с которыми вы знакомы, не беспокоясь о том, насколько хорошо они будут работать в более крупных проектах. Не беспокойтесь о плагинах, скинах, редакторах и прочей ерунде. Просто заставь это РАБОТАТЬ! Затем, когда вы закончите с этой первой, самой важной игрой, выберите другую и на этот раз очистите один или два аспекта вашего кода (но не переусердствуйте!) Оттуда повторите итерацию!

Я обещаю вам, что это позволит вам продвинуться дальше быстрее, чем любое количество поисков в Интернете "правильного пути" (это исходило от того, кто МНОГО тыкал).

И последняя мысль для вас: если вам удобнее работать в более четко определенном пространстве, взгляните на XNA или аналогичную библиотеку. Они заранее определят некоторые из «лучших» форматов для использования и дадут вам инструменты для работы с ними, что избавит вас от некоторых первоначальных догадок.

Удачи и, прежде всего, помните: игры (и их разработка) должны быть УДОВОЛЬСТВИЕМ! Не зацикливайтесь на мелочах!

Поскольку об этом еще не упоминалось, почему бы не начать с рассмотрения существующего движка, выпущенного для сообщества? Поскольку вы говорите о 2D, я бы вернулся и порекомендовал что-то вроде Злоупотреблять. Да, он древний, и большинство интересных моментов есть в Лиспе, но на какое-то время игра стала очень популярной, что означает, что они что-то делали правильно.

На самом деле, я думаю, что тот факт, что большая часть оригинальной игры была на Лиспе, является очень полезным уроком. Выберите наиболее надежный язык / инструмент и не беспокойтесь о производительности. Вы всегда можете оптимизировать медленные части в C позже.

Не могу с вами больше согласиться: корпоративные приложения не готовят вас к программированию игр.

Я создал несколько небольших игр на python, java, html / php и perl. Как вы, наверное, знаете, основная структура игры такова:

Основной цикл:
  handleInput ()
  updateGameLogic ()
  renderImages ()

Это все хорошо для одноэкранных однопоточных игр, как и все, что было из 70-х или 80-х годов. Но я не считаю эту структуру особенно подходящей для многоэкранных игр (например, ролевых игр) или чего-то более экзотического. Это не очень хорошо. Код становится довольно забавным, так как вам нужно обрабатывать множество входных данных. Он плохо масштабируется.

Однако, прежде чем я буду слишком сильно отказываться от этой метафоры, обратите внимание, что это ОТЛИЧНОЕ место для начала. Я бы даже порекомендовал изучить Python / Pygame и начать создавать игры с помощью этого инструмента, а не C++, что усложняет процесс проектирования и реализации. Когда вы создадите прототип на Python, вы увидите, что игра обретает форму намного быстрее и сталкивается с проблемами, не зависящими от языка.

Для меня самые сложные и трудоемкие аспекты программирования игр - это графические и звуковые ресурсы. Хотя я немного фанат аудио и музыкант-любитель, создание правдоподобной и подходящей музыки и спецэффектов - это отдельный проект. У меня нет графического таланта, поэтому я должен полагаться на изменение существующих изображений или использование свободно доступных. К счастью, есть широко доступные бесплатные шрифты, которые можно использовать для игр (и немного больше, поскольку они почти всегда плохие).

Наконец, нет ничего лучше открытого исходного кода, чтобы увидеть, как другие проекты справляются с этим. Battle of Westnoth - зрелая игра среднего размера. Возможно, вы захотите посмотреть, что там происходит. Опять же, игры на Python часто предоставляют доступ к своему исходному коду, так что вы можете просмотреть там сотни проектов. Вы также можете декомпилировать atari 2600 ROM, но это мало что скажет о программировании сегодня. Старый VCS был специализированным устройством, которое обрабатывало свои приложения очень зависимым от системы способом. :-D

Наконец, мне также нравится Андре Ламот. У меня есть его старая книга 1993 года толщиной в миллион страниц. Хотя это по-прежнему хороший справочник по некоторым общим идеям игр, во многих случаях он устраняется наличием бесплатных доступных библиотек и фреймворков, которых тогда не существовало.

Удачи с вашим проектом.