Игровое программирование - Как избежать повторного использования колеса

Сводка:

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

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

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

Я задаю этот вопрос, потому что знаю, что я очень восприимчив к синдрому Inv Invented Here Syndrome. Я всегда хочу запрограммировать его сам, и я уверен, что он тратит много времени. Однако это работает для меня очень часто - например, вместо использования Rails (очень большая структура веб-проекта с ORM и инструментарий GUI, испеченный в), я использовал массив меньших инструментов Ruby, таких как rack и sequel, которые прекрасно сочетаются.

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

Использовать C
- против
  - Вероятно, мне придется программировать ненависть.
  - Высокий риск переосмысления колес.
  - Высокий риск того, что он будет так долго, что я потеряю интерес
- Pros
  - Tried and true - большинство игр A-списка выполняются в C (это все еще верно сегодня?)
  - Высокий уровень контроля над управлением памятью, скоростью, управлением активами и т.д., которым я доверяю себе, чтобы научиться обрабатывать
  - Без трещин
Использовать фреймворк или SDK
- против
  - Риск негабаритных поставок
  - В зависимости от авторов оригинальной библиотеки для всех аспектов разработки игры - что, если нет функции, которую я хочу? Мне придется запрограммировать его самостоятельно, что неплохо, но частично поражает цель использования высокоуровневой структуры в первую очередь.
  - Высокий риск проблем с производительностью.
- Pros
  - МНОГО ускорение разработки
  - Может быть проще поддерживать
  - Не тратится время на повторное использование общих парадигм

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

Ответ 1

Мое современное мышление:

Если вы хотите научиться программировать, начните создавать игровой движок из базовых элементов вверх (даже реализуя основные структуры данных - списки, карты и т.д.). Я сделал это один раз, и, хотя это был опыт обучения, я допустил много ошибок, и я бы не стал делать это во второй раз. Однако для того, чтобы научиться программировать, а также сделать что-то классное и увидеть результаты, я бы очень оценил это.
Если вы хотите сделать правильную игру, используйте любые библиотеки, которые вы хотите, и сами создайте всю инфраструктуру игры. Это то, что я сейчас делаю, и я использую все приятные вещи, такие как STL, ATL/WTL, Boost, SQLite, DirectX и т.д. До сих пор я много узнал о аспекте средней/игровой логики код и дизайн.
Если вы просто хотите создать игру с художниками и другими людьми, сотрудничающими для создания готового продукта, используйте один из существующих движков (OGRE, Irrlicht, Nebula, Torque и т.д.) и просто добавьте в свою логику игры и искусство.

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

Ответ 2

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

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

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

Ответ 3

Я бы посоветовал вам попробовать pyglet.

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

Кроме того, если вы используете существующую библиотеку языков сценариев для создания вашей игры, большинство критических областей производительности (например, графики) могут быть записаны на С++ в любом случае (надеюсь, библиотеками игр). Таким образом, 80% ЦП действительно может быть потрачено на С++-код в любом случае, несмотря на то, что большая часть вашего проекта написана, скажем, Python.

Я бы сказал, спросите себя, чего вы хотите больше: написать игру от начала до конца и узнать о разработке игры или узнать новый язык (С++). Если вы хотите написать игру, сделайте это на языке сценариев. Если вы хотите изучить новый язык, сделайте это на С++.

Ответ 12

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

Лично мне нравится рекомендовать Torque Game Builder (он же Torque 2D) от GarageGames. Но вы, вероятно, можете найти некоторые бесплатные игровые движки, которые также будут соответствовать вашим потребностям.

Ответ 13

Я уверен, что большинство современных игр выполнены на С++, а не C. (Каждая игровая компания, с которой я когда-либо брал интервью с вопросами на С++).
Почему бы не использовать С++ и существующие библиотеки для физики + коллизии, звук, графический движок и т.д. Вы все еще пишете игру, но постигаете мирские вещи.

Ответ 14

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

В моем текущем проекте используются С#, DirectX 9, HLSL и SlimDX. Каждый из них предлагает тщательно откалиброванный уровень абстракции. HLSL позволяет мне читать код шейдера, который я пишу, и SlimDX/С# позволяет мне игнорировать указатели, круговые зависимости и обработку неуправляемого кода.

Тем не менее, ни одна из этих технологий не влияет на простоту разработки моего ИИ, освещения или физики! Мне все же приходится вырывать мои учебники таким образом, чтобы я не имел более высокого уровня.

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

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

Как идея, возможно, стоит брать разные библиотеки/фреймворки (определенно сделать XNA одной из ваших остановок, даже если вы решите, что не хотите ее использовать, это отличный тест) и пытается создать различные прототипы. Возможно, пейзаж (с кучей воды) или демоника космической физики.