Программирование игр - Как не изобретать велосипед - PullRequest
11 голосов
/ 25 октября 2008

Резюме:

Могу ли я запрограммировать "толстый клиентская игра в Си без переизобретений колеса , или я должен просто укусить bullet и использовать какую-нибудь библиотеку или SDK? Я программист умеренного Си и не боюсь работать с указателями, данными структуры, ячейки памяти и т. д., если это даст мне контроль, мне нужно сделать отличную игру "толстый клиент". Тем не менее, я думаю об избежании языки высокого уровня и рамки для ради власти и контроля, не простота использования.

Мне интересно когда-нибудь повозиться с 2D-файтингом / платформером в качестве побочного проекта. Я в первую очередь программист на стороне Linux с опытом работы с Python, Ruby и PHP. Я знаю, что на некоторых из этих языков есть отличные фреймворки, такие как PyGame . Я также знаю об успехе, достигнутом людьми с такими вещами, как Air и .NET ... но у меня есть некоторые опасения:

  • Производительность : языки сценариев общеизвестно медленны. Если я делаю игру в реальном времени, я хочу, чтобы она была максимально быстрой.
  • Огромные двоичные файлы : Использование каркасов, таких как .NET, или языков сценариев, таких как Ruby, часто приводит к большим CLR или библиотекам, которые в противном случае вам не нужны. Игра, которую я хочу сделать, будет маленькой и простой - я не хочу, чтобы ее CLR была больше, чем сама игра!
  • Дополнительные вещи : Честно говоря, мне просто не нравится идея наследования багажа какой-то большой игровой библиотеки, если я могу лучше обернуть голову вокруг своего собственного кода.

Я задаю этот вопрос, потому что я знаю, что я очень подвержен синдрому «Не изобретено здесь». Я всегда хочу запрограммировать это сам, и я уверен, что это тратит много времени. Тем не менее, у меня это работает довольно часто - например, вместо использования Rails (очень большой фреймворк для веб-проекта с встроенным инструментарием ORM и GUI), я использовал массив меньших инструментов Ruby, таких как стойка и продолжение , которые прекрасно сочетаются друг с другом.

Итак, я обращаюсь к вам, ТАК эксперты. Я наивный? Вот как я это вижу:

  • Использовать C
    • Против
      • Возможно, я буду ненавидеть программирование
      • Высокий риск изобретать колеса
      • Высокий риск того, что это займет так много времени, что я теряю интерес
    • Плюсы
      • Испытано и верно - большинство игр A-list сделаны на C (правда ли это сегодня?)
      • Высокий уровень контроля над управлением памятью, скоростью, управлением активами и т. Д., Которому я сам доверяю, чтобы научиться справляться с ним
      • Нет хуев
  • Использовать рамки или SDK
    • Против
      • Риск негабаритных поставок
      • Зависит от авторов оригинальных библиотек по всем аспектам разработки игр - что делать, если мне не нужна особенность? Мне придется запрограммировать его самому, что неплохо, но частично сводит на нет цель использования высокоуровневого фреймворка в первую очередь
      • Высокий риск проблем с производительностью
    • Плюсы
      • НАМНОГО быстрее время разработки
      • Может быть проще в обслуживании
      • Нет времени, потраченного на переосмысление общих парадигм

Что еще я могу добавить в этот список? Это чистое суждение или кто-то может заключить сделку для меня? Предложения книг приветствуются.

Ответы [ 14 ]

13 голосов
/ 25 октября 2008

Я считаю, что вы работаете под ошибкой.

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

Другими словами, у вас «высокий риск проблем с производительностью», если вы НЕ используете фреймворк.

8 голосов
/ 19 декабря 2008

Мое нынешнее мышление:

  • Если вы хотите научиться программировать, начните создавать игровой движок от базовых элементов вверх (даже реализуя базовые структуры данных - списки, карты и т. Д.). Я сделал это один раз, и, хотя это был опыт обучения, я допустил много ошибок, и я не буду делать это второй раз. Однако, за то, как научиться программировать, а также делать что-то классное и видеть результаты, я бы оценил это очень высоко.

  • Если вы хотите сделать правильную игру, используйте любые библиотеки, которые вам нужны, и проектируйте всю игровую инфраструктуру самостоятельно. Это то, что я делаю сейчас, и я использую все приятные вещи, такие как STL, ATL / WTL, Boost, SQLite, DirectX и т. Д. До сих пор я многое узнал об аспекте логики среднего / игрового мира. код и дизайн.

  • Если вы просто хотите создать игру с художниками и другими людьми, сотрудничающими для создания готового продукта, используйте один из существующих движков (OGRE, Irrlicht, Nebula, Torque и т. Д.) И просто добавьте в свою игровую логику и ст.

Последнее, что я узнал, это то, что не беспокойся о синдроме «Не изобретено здесь». Как я понял, другие библиотеки (такие как STL, Boost, DirectX и т. Д.) Имеют на порядок (или три) больше человеко-часов времени разработки, что намного больше, чем я когда-либо мог бы потратить на эту часть игры / движка. Поэтому единственная причина, по которой вы можете реализовать эти вещи самостоятельно, - это если вы хотите узнать о них.

7 голосов
/ 25 октября 2008

Я бы порекомендовал вам попробовать pyglet .

  • Обладает хорошей производительностью, так как использует OpenGL
  • Это компактная универсальная библиотека
  • У него нет дополнительных зависимостей, кроме python

Пройдите несколько тестов, посмотрите, сможете ли вы сделать это достаточно быстро для вас. Только если вы докажете себе, что это не переход на более низкий уровень. Хотя я вполне уверен, что python + pyglet справится с этим ... в худшем случае вам придется написать несколько расширений Си.

4 голосов
/ 11 января 2009

Я удивлен, что никто не упомянул XNA . Это основа, построенная вокруг DirectX для выполнения управляемого программирования DirectX, в то же время устраняя много ошибок и многословия низкоуровневого программирования DirectX.

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

Еще одно интересное преимущество XNA заключается в том, что большая часть кода может быть запущена на Xbox 360 и даже может быть отлажена по сетевому соединению, если игра работает на Xbox. Игры XNA теперь могут быть одобрены командой Xbox Live для распространения и продажи на Xbox Live Arcade. Поэтому, если вы хотите перевести проект в коммерческое состояние, возможно, у вас есть доступные средства распространения.

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

4 голосов
/ 25 октября 2008

Вы должны спросить себя, хотите ли вы создать движок или создать игру. Если ваша цель - создать игру, вам обязательно стоит взглянуть на установленный игровой движок. Для разработки 2D-игр посмотрите Torque Game Builder . Это очень мощный 2D игровой движок / SDK, который позволит вам начать работу с первого дня. У них есть множество инструментов, которые интегрируются с ним, пакеты контента, и вы получаете полный исходный код, если хотите внести изменения и / или изучить как это устроено. Он также совместим с Mac OSX и имеет версии для Linux в сообществе.

Если вы ищете что-то на стороне консоли, у них это тоже есть.

4 голосов
/ 25 октября 2008

Сегодня я полагаю, что вы находитесь в такой точке, когда вы можете спокойно игнорировать проблему производительности, если вы специально не пытаетесь сделать что-то, что выходит за пределы. Если ваша игра, скажем, не сложнее, чем Quake II, то вы должны выбрать инструменты и библиотеки, которые позволят вам максимально использовать время .

Почему я выбрал Quake II? Поскольку он работает в версии, скомпилированной для .NET , он работает с программным средством визуализации с более чем приемлемой частотой кадров на текущем компьютере. (Если хотите - сравните MAME, который эмулирует несколько процессоров и графическое оборудование с приемлемой скоростью)

2 голосов
/ 19 декабря 2008

Одним из соображений в пользу C / C ++ / obj-C является то, что вы можете смешивать и сопоставлять различные библиотеки для разных проблемных областей. Другими словами, вы не застряли с реализацией функции в рамках.

Я использую этот подход в моих играх ; использование chipmunk для двумерной физики, Lua в качестве встроенного языка сценариев и реализация openGL ES от Apple. Я пишу клей, чтобы связать все это вместе на языке Си. Конечным продуктом является способность определять игровые объекты, создавать их экземпляры и обрабатывать события, когда они взаимодействуют друг с другом в функциях C, доступных для Lua. Этот подход используется в многих высокопроизводительных играх с большим успехом.

2 голосов
/ 25 октября 2008

Что касается того, что люди говорили о C / C ++ / Python, я разработчик игр, и моя компания поощряет C. Не б / с C ++ - это плохо, а потому, что плохо написанный C ++ является ядом для разработки игр из-за его сложности читать / отлаживать по сравнению с C. (C ++ дает преимущества при правильном использовании, но пусть младший делает с ним некоторые ошибки, и ваше время очень велико)

Что касается актуального вопроса: Если ваша цель - просто заставить что-то работать, используйте библиотеку.

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

Часто библиотеки делают то, что вы хотите, и это замечательно, но иногда ВАШ конкретный вариант использования очень плохо обрабатывается библиотекой lib, и вы получите большую выгоду от написания своего собственного. Это особенно на консолях по сравнению с ПК

(edit :) Относительно скрипта и сборки мусора: он убьет на консоли, в недавней игре мне пришлось переписать основные части сборки мусора на Unreal просто для того, чтобы удовлетворить наши потребности в редактор часть. Еще больше нужно было сделать в реальной игре (не только я) (чтобы быть справедливым, хотя мы выдвигали за пределы оригинальных спецификаций Unreal)

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

2 голосов
/ 25 октября 2008

Самым распространенным языком реализации для игр A-list сегодня является C ++, и во многих играх для сценариев игровых событий используется язык сценариев (например, Python или Lua).

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

Вообще говоря, современные ПК достаточно быстры для запуска 2D-платформеров, написанных на языках сценариев. Использование языка сценариев позволит вам быстрее создавать прототипы и у вас будет больше времени для настройки игрового процесса. Опять же, это ничем не отличается от любого другого проекта.

Если вы используете C ++, и ваши причины не должны быть более сложными, чем «потому что я хочу», я бы посоветовал вам взглянуть на SDL для поддержки рендеринга и аудио. Это немного облегчит жизнь.

Если вы хотите изучить базовые технологии (DirectX или по каким-то извращенным причинам хотите писать оптимизированные блиттеры), тогда непременно используйте C ++.

Сказав все это, я бы предостерег вас от преждевременной оптимизации. Для 2D-игры вам, вероятно, будет лучше сначала использовать Python и PyGame. Я был бы удивлен, если эти инструменты окажутся неадекватными на современных ПК.

2 голосов
/ 25 октября 2008

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

Для двумерной игры, я не думаю, что производительность будет проблемой, я рекомендую пойти с чем-то, что даст вам результаты на экране в кратчайшие сроки. Если у вас большой опыт работы с Python, тогда pyGame - хороший выбор.

Если вы планируете делать какие-то 3d игры в будущем, я бы порекомендовал взглянуть на Ogre (http://www.ogre3d.org).). Это кроссплатформенный движок трехмерной графики, который абстрагирует графические API. Однако для 2d проекта это вероятно, перебор.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...