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

Question

Резюме:

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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