Программирование игр: как не изобретать велосипед

https://stackoverflow.com/questions/235151

04-07-2019
|

Вопрос

Краткое содержание:

Могу ли я запрограммировать игру «толстый клиент» в C без переосмысления колес, или я должен просто укусить пулю и использовать библиотеку или SDK?Я программист с умеренным C и не боюсь работать с указателями, структурами данных, местоположениями памяти и т. Д.Если это даст мне контроль, мне нужно сделать отличную игру «толстого клиента».Тем не менее, я думаю о том, чтобы отказаться от языков и фреймворков высокого уровня ради власти и контроля, нетпростота использования.

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

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

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

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

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

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

Решение

Мои текущие мысли таковы:

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

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

Другие советы

Я считаю, что вы действуете в заблуждении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow