Написание игрового движка с нуля с OpenGL [закрыто]


15

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

Мои языки программирования и инструменты:

  • C / C ++ хорошо ли использовать только C?
  • питон
  • OpenGL
  • Гит
  • GDB

Что я хочу извлечь из этого:

  • Основной игровой движок
  • Рендеринг / Графика
  • Game Play / Правила
  • Ввод (клавиатура / мышь / контроллеры и т. Д.)

В рендеринге / графике:

  • 3D
  • затенение
  • Осветительные приборы
  • Текстурирование

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

8
Второе: распространено мнение о том, что другие люди будут говорить, что вы не должны фокусироваться на создании движка без игры. Двигатель без игры означает, что вы не можете доказать, что ваш двигатель полезен . Хорошие двигатели требуют, чтобы люди ели свою собачью еду. Блог, на который обычно ссылаются на этот аргумент, можно
найти

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

1
Я не вижу смысла в ваших списках. Тот факт, что вы знаете C / C ++ и Python, помогает нам, но зачем перечислять, что вы можете использовать контроль версий и отладчик?
Коммунистическая утка

2
@TheCommunistDuck: Эй, это лучше, чем некоторые разработчики. :)
ChrisE

Ответы:


11

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

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

  • Основной игровой движок

  • Рендеринг / Графика

  • искусственный интеллект

  • сетей

  • Game Play / Правила

  • Звук

  • Ввод (клавиатура / мышь / контроллеры и т. Д.)

и т.д. Оттуда вы можете даже иметь подтемы. В рендеринге / графика

  • 2D или 3D?

  • моделирование

  • затенение

  • Осветительные приборы

  • Текстурирование

  • ГПИ / Huds / интерфейсы.

  • и т. д.

Только одна из этих подтем может съесть много часов (или лет!) Обучения!

Итак, сначала определите, что вы хотите узнать. Начните просто.

Используйте любой язык, который вам удобен - хотя некоторые лучше подходят для определенных задач. Например, ядро ​​и рендеринг, вероятно, лучше всего выполнять с языком «более низкого» уровня, таким как C / C ++ (если вам нужна производительность); но что-то вроде ИИ или правил игры может быть лучше сделано на языке более высокого уровня. Ничто не говорит, что вы не можете смешивать и сочетать. Вы можете написать свой движок на C ++, ваш рендеринг на C (поскольку он хорошо работает с OpenGL), а затем использовать LUA для написания сценариев ваших правил игры и т. Д.

В качестве примера, есть игровой движок под названием Slick2D. Он написан на Java и имеет открытый исходный код. Это пример простого 2d движка, написанного и спроектированного очень хорошо. Из этого вы можете изучить основные понятия, такие как игровые циклы, управление игровыми состояниями и т. Д.

Если вам удобно с C / C ++; Я бы посоветовал взглянуть на SDL / OpenGL. Он обрабатывает некоторые домашние операции, такие как ввод, звук, создание окон и т. Д., И может сосредоточиться на других вещах.


4
Ааа, дни, когда я изучал C ++ и консольные игры, были потрясающим развлечением ... [создает новый консольный проект ...]
Ник Бедфорд,

Я обновил свой вопрос, надеюсь дать мне много удивительных ресурсов :)
Wazery

4

SDL + OpenGL - отличный выбор для запуска пользовательского игрового движка.

Я лично использую C-версию C ++, потому что я обнаружил, что она работает лучше всего для меня. Я имею в виду, что я не использую никаких исключений. Для этого есть две причины: в первую очередь исключения требуют кода безопасности исключений, чего с OpenGL и SDL добиться непросто. Однако, что еще более важно, таким образом очень легко выставлять объекты C ++ поверх C ABI, что невероятно полезно, если вы попытаетесь внести в сценарий язык сценариев.

Я нахожусь в той же лодке, что и вы, и я записал некоторые из моих приключений с SDL и OpenGL в блоге ( immersedcode.org ) на случай, если кто-то заинтересован.

Для общей архитектуры у меня есть два предложения: если вы хотите 3D-движок, посмотрите книгу «Архитектура игрового движка» Джейсона Ландера. Если все, что вам нужно, это 2D, сделайте дизайн как можно более простым и позвольте себе вдохновиться XNA или другими проектами.

И наконец: не называйте OpenGL повсюду. Сделайте себе одолжение и выделите его в пару мест, чтобы у вас была возможность переключаться между настольным OpenGL / OpenGL ES или даже DirectX на более позднем этапе, если вы хотите.


0

Не используйте C, если детали реализации не держат вас под прицелом. В противном случае используйте C ++, потому что это значительно более мощный язык, и вы всегда можете отказаться от использования этих возможностей позже. У меня лично нет ничего за / против Python, я никогда не использовал его.

Я не рекомендовал бы OpenGL против DirectX, потому что DX имеет современный объектно-ориентированный подход, который намного чище и более понятен / менее подвержен ошибкам. Интерфейс, предлагаемый OpenGL, чрезвычайно плох по сравнению.

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


4
"OpenGL vs. DX". Тот факт, что DirectX - это больше ОО, на самом деле не важен. Насколько понятнее ... OpenGL (до 3-х) предоставляет довольно простой интерфейс, который легко сканировать, так как все это в императивной методологии в стиле Си. «Установите матрицу проекции на это. Начните треугольники. Вот вершина. Вот вершина. Вот вершина. Концы треугольников». Серия API OpenGL 1.x хороша для того, чтобы погрузиться в графическое программирование, и в сочетании с SDL (или даже GLUT ... urg) позволяет загружать приложение в 30-50 строк кода.
ChrisE

2
@ChrisE: Конечно. Там что-то называется extern "C", и его правильное использование делает написание интерфейса на C довольно тривиальным, особенно для Python, где в Boost существует конвертер, который облегчает привязку к нему. Как насчет особенностей языка C ++? Они великолепны . Более широкое использование языковых возможностей C ++ повышает надежность проекта и упрощает массовое кодирование для более чем приемлемого очень незначительного компромисса производительности. Языковые особенности Си по сравнению с этим жалки. Например, правильное использование современного компилятора C ++ может гарантировать отсутствие утечек памяти. Сделайте это в C.
DeadMG

1
@DeadMG: Если ООП действительно имеет большое значение, ответ здесь - Java или C #, а не C ++. В чем я не согласен, так это в том, что использование функций C ++ не делает ваш код лучше, быстрее или даже более надежным; Вы должны знать, как использовать эти функции, и является ли изучение языка в дополнение к созданию движка действительно полезным временем? Нет, не для тех, кто делает это в первый раз. Вы можете выучить все C за день или два, с комфортом, и никогда не задумываться над тем, что делает язык. OpenGL, полезный базовый вызов, установленный по любому тарифу, предлагает ту же прозрачность.
ChrisE

2
ООП не так уж важно, не в высокопроизводительных игровых движках. Конечно, это полезно, но часто это неправильная абстракция. Наличие хорошего потока данных, расположение и расположение памяти обычно лучше. Хотя многие команды используют C ++, они не используют большинство функций C ++. Нет исключений, как можно меньше виртуалов, нет RTTI, нет STL / Boost. Почему? Предсказуемое и быстрое выполнение и небольшой код на нескольких платформах. Я кодирую на C, и есть только две области, в которых я бы предпочел использовать C ++: блокировки с областями видимости и универсальные массивы. Не стоит хлопот ИМХО.
аннулировано

4
На GL против D3D: в ядре GL3 / 4 нет стека матриц и нет стека атрибутов. И GL, и D3D отображаются на одну и ту же аппаратную архитектуру, но много времени GL чувствует себя хуже. Конечно, конечный автомат GL - это немного хлопотно, но то же самое относится и к реальному оборудованию;) Изучение любого из них - это хорошо, и если вы понимаете, что на самом деле происходит, вы можете легко переключаться на другое (или консольный API).
аннулировано
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.