Просмотр полной версии : Игровой движок общими усилиями
Предполагаю написать на C# под Net.Framework и DirectX игровой движок общими усилиями. Как программист я не очень, но 3d maxом пользуюсь 6 лет. Есть базовые понятия и неплохой склад ума, позволяющий выполнять некоторые логические решения.
Предполагаемая структура движка
*.exe - собственно то, что объединит все написанное в одну кучу.
*.core.dll - библиотека для *.exe файла, которая будет являться каркасом приложения (графический интерфейс, элементы управления, ссылки на файлы конфигурации и ссылки на необходимые составляющие элементы игрового движка).
objects - папка с моделями и текстурами (с форматом моделей пока не определился, склоняюсь к написанию собственного).
scripts - папка со скриптами в формате (*ini, *.lua или аналогичном)
sounds - звуки
Это первоначальная задача. На данном этапе можно попробовать реализовать хотя бы это - сделать *.dll библиотеку с основными классами и прикрепить к ней простенький *.exeшник (на подобие dxmut).
А зачем?
Для дальнейшего использования сего в собственных целях...
А в чём проблема взять уже готовый? Тот же Unity3D...
Не люблю копаться в чужом белье. Проще написать что-то свое, чем изучать чужое. Тем более каждый "писатель" пишет код "под себя" своим методом и со своей "архитектурой"...:sml:
Все же предлагаю взяться за написание *.dll библиотеки с базовыми классами и параллельно писать к ней *.exe.
Я предпочитаю время тратить на создание игры используя готовые решения. К тому же кустарный двиг будет хуже тех, что есть сейчас на рынке, начиная с того же Юньки. Движки писать это на любителя, а игры всё же делать интереснее...
Движки писать это на любителя, а игры всё же делать интереснее
Если писать двиг с нуля, то такой подход к девелопингу позволит создать новый продукт, который будет являться уникальным в своем роде и не иметь аналогов. Если же использовать готовые решения в области построения игр, то такие проекты не увенчаются успехом...
Достаточно много успешных игр делается на UDK, CryEngine, Unity3D и других топовых движках. Так что ты не прав в этом изречении. ;) Например http://www.youtube.com/watch?v=f-2DyMTdDC4 делалась на Юньке. И сколько потребуется времени и сил на самопальный движок, чтобы он начал выдавать такую картинку http://www.youtube.com/watch?v=RMk5xf8DpCE ?
Достаточно много успешных игр делается на UDK, CryEngine, Unity3D и других топовых движках.
Реализовать (выпустить) такие продукты будет весьма сложно. Я не думаю, что лицензия на CryEngine дешево стоит... Если делать проекты, используя готовые решения, то только для себя (не в коммерческих целях)...
Лицензия на Unity3D стоит $1500. Но даже на бесплатной его версии с урезанными функциями можно делать и продавать игры. UDK более хапужный но и он последнее время к инди разработчикам повернулся на половину лицом. :) Однако до политики Юнитеха, UDK ещё долго поворачиваться. Так что уже с движками не всё так плохо. А Юнити уже по моему мнению картинку может выдавать не хуже чем тот же UDK. Только Юнитех больше прогеры, чем дизайнеры и у них таких красивых демок как на UDK пока нету (ну вон тот футуристичный мостик сделан на Юньке профессиональным дизайнером для своего портфолио).
Разработка игры на готовом движке:
1. Кротчайшие сроки сборки
2. Простота в использовании
3. Совместимость со многими форматами
Разработка игры на своем движке:
1. Универсальность
2. Безграничные возможности
3. Полный контроль над авторскими правами
Что значит безграничные возможности? И что даёт полный контроль над авторскими правами к любительскому движку, который никогда не дотянет да топовых (среди которых и Юнити)?
Да, универсальность так же у Юньки присутствует. :)
Предполагаемая структура движка
Это не структура. Это просто набор файлов и папок. Структура - это совершенно другое.
Да и вообще. Не имея опыта создания движков что-то серьёзное не напишешь. Далее, на этом форуме не так много высококлассных программистов готовых реализовать такой сложный проект просто ради себя. За этим нужно идти на специализированные форумы. Ну и наконец, писать что-то своё глупо. Есть масса уже готовых решений на любой вкус. Бери, да пользуйся!
Структура - это совершенно другое
То, что я предлагаю - является не игровым движком, а базовым каркасом для будующей игры с возможностью внесения\изменения кода\скриптов... По мере написания будут подключаться новые библиотеки, компоненты, файлы и прочие составляющие...
Предполагаемая структура корневого каталога предполагаемой игры
Objects - папка, в которой будут находиться все игровые объекты (модели и текстуры). В папке будут еще две: Models и Textures соответственно. В папке Models будут следующие подпапки: Static - статические объекты и Dynamic - динамические. Статические объекты - это геометрические модели, которые используются в играх как стационарные (объекты не подлежащие деформации, анимации и прочим видоизменениям. Так же они не могут быть перемещены, повернуты и масштабированы в процессе игры). Динамические объекты - это объекты, которые полностью взаимодействую с игровым миром при помощи сложной системы скриптов (персонажи, техника, анимированные объеты, прочие). Я не стану описывать полную структуру папки Objects, приведу лишь краткий список... Примерный...
Objects
---Models
------Static
---------Buildings
---------Other
------Dynamic
---------Characters
---------Vehicles
---------Animated
---------Vegetation
---------Other
---Textures
------Static
------Dynamic
Пакпка Scripts будет содержать в себе все игровые скрипты. Скрипты будут написаны на основе заранее подготовленного кода, и будут представлять собой файлы с доступным для редактирования форматом. Скрипты будут делиться на группы: Main - главные скрипты, необходимые для глобальных данных, Locations - скрипты определенных локаций, Weapons, Vehicles - скрипты с техническими характеристиками оружия, Others - прочие скрипты.
Scripts
---Main
---Global
---Weapons
---Vehicles
---Others
---Weathers
Звуки будут в папке Sounds. Сама папка будет разбита на несколько подпапок: Ambient - звуки окружения, Sounds - игровые звуки, Music - игровая музыка...
Sounds
---Ambient
------Sounds
------Weapons
------Vehicles
------Voice
---Music
В корневом каталоге игры будут лежать файлы *.dll - динамические библиотеки, содержащие информацию о каркасе приложения.
LINE_BLOD
30.03.2012, 14:08
Предполагаемая структура корневого каталога предполагаемой игры
Нам-то это зачем,все приведенное выше не имеет смысла без самого движка.
Nirnaeth
30.03.2012, 15:39
Вот свой движок кстати должен давать наивысшую производительность (при условии что программист знает что делает). Далее правда встанет вопрос о его универсальности, то есть - можно ли будет на нём же сделать игру достаточно отличного жанра от самого первого. Но просто "на раз" - лучше делать самому.
Да и что понимать под этим словом?
Графику - думаю ей можно заняться в последнюю очередь. Организовать просто для визуализации хоть какой-то кубики-шарики-пирамидки, а не нормально спроектированные машины и т.д. Если сильно не мудрить - замена далее пройдёт быстро.
Физика - важно. Хотя зависит от жанра, опять же.
ИИ - а вот тут надо работать очень осторожно. В одной из своих любимых стратегий уже видел как боты с "новой" тактикой создавали страшнейшие лаги, в то время как официальный ИИ вполне прилично работал.
Сам игровой процесс (отношение объектов в ООП, если выберешь этот стиль, что скорее всего - да) - начинать стоит именно с этого.
Приведённая структура папок, действительно, к созданию движка имеет самое последнее отношение.
Сам сейчас занят над чем-то подобным. Начал с важнейшего - алгоритм поиска пути. Взял стандартный волновой алгоритм, и улучшаю его по мелочам пока. Понимаю - дальше будет ещё сложнее. Но у меня много интересных идей :)
Nirnaeth, Для начала необходимо создать базовые классы, которые будут составлять некий каркас приложения. Затем, по мере написания кода, постепенно добавлять такие элементы, как графический пользовательский интерфейс, элементы управления, затем уже можно немного поэксперементировать в области построения рендеринга и попробовать организовать базу, которая позже составит модель скриптов...
P.S. Как программист я не очень. В свое время упустил это. Я художник, моделлер, имеющий богатый опыт работы в 3D Max`е. Если я немного затупляю, или же просто пишу всякую хрень, не имеющую смысла, так и скажи.
Nirnaeth
30.03.2012, 16:30
Да, примерно так. Только экспериментировать не надо особо - можно из-за неопытности очень много мин раскидать которые под конец работы встретишь. Надо заранее определить приоритетные задачи в соответствии с тем что будет за игра, и работать только по ним.
Если например делаешь авиа\автосимулятор - то тут само собой на первом месте будет стоять физическая модель. И только потом графика и т.д. Начав с того что полностью опишешь модели самолётов и наложишь текстуры - это само по себе работу не продвинет. Хотя и это может быть важным, если например хочешь сделать красивые модели разрушений. Надо же будет хоть с чем-то работать для этого?
Или другой пример - Geometry wars. ИИ врагов примитивен, движения по карте описываются фундаментальными формулами. Зато масса работы с графикой - потому что там в ней вся красота.
Надо заранее определить приоритетные задачи
1) Написание *.dll библиотеки, которая будет отвечать за каркас приложения (форма, элементы управления, внутренняя структура). Написание к этой *.dll файла *.exe, который собственно и будет игрой (в будущем).
2)Написание *.dll библиотеки, которая будет отвечать за рендер (работа с устройством, методы рендеринга, прочее). Эта библиотека будет являться неким графическим движком. К ней из вне будут прицеплены прочие элементы этой группы.
3) Написание *.dll библиотеки, отвечаюшей за скрипты. Здесь немного сложнее. Придется делать примитивную структуру этих скриптов. Скрипты в открытом формате (*.ini, *.txt).
4) Проработка геймплея и создание базовых элементов управления этим творением.
5) Графика, текстуры, прочее.
6) Звуки, музыка, прочее.
Ну и хрень собачью я написал. Нда, неверное, не стоит этим заниматься. Особенно на VS2005 под Net.Framework и DirectX.
Xenar,
Со структурой папок ты затупляешь это да. Думаешь от того что в каких папках будет храниться каким то боком относится к движку? Ну да изменить путь к папке внутри исходного кода дело 1 минуты.
Структура движка это нечто другое. И делать абстрактный движок в ваакуме действительно бессмысленно. Есть какая нибудь цель? Без программироваия или знания построения архитектуры приложений все твои усилия обречены.
Я бы помог, но затея изначально на уровне "а давайте сделаем чтобы можно грабить корованы, я уже джва года жду"
Pharaon, Я пытаюсь, но я не программист. Единственное, что у меня получается - приложение, работающее в полноэкранном режиме, умеющее читать 3d модели стандартных форматов, которыми некто не пользуется. При всем своем долбаном оптимизме я смогу еще сделать меню, все. В теории я смогу сделать структуру движка, но реализовать это в виде кода у меня не получится.
Nirnaeth
30.03.2012, 20:04
Ладно, я вот тоже не особо много знаю по игрострою, но кое-что вот по этим темам посмотри:
Совершенно необходимо для подавляющего большинства игр знать как работает алгоритм поиска пути. Классический волновой алгоритм, A* или какой-либо другой. Без этого никуда.
Также очень важен алгоритм движения группы объектов. Если будешь делать стратегию - придётся изучать. В принципе его можно организовать варварским способом из готового для перемещения только одной точки, но лучше не надо. Применяй мат. анализ.
Обратись к теме двумерных и трёхмерных (тензоров) матриц и их преобразований.
Многопоточное программирование - тут я сам почти ничего не знаю. Но чтобы игра не провисала на одном единственном действии надо изучать эту тему. Использовать готовые классы потоков, или рисковать без синхронизации с простым освобождением очереди - сам решишь.
Что это было? Это боты на форуме?
Xenar,
Условно говоря движок можо разделить на несколько управляющих структур и модулей, как ты правильно выразился.
Но все таки начинать делать от общего к частному, то есть от движка к игре, не имея понятия о нужном функционале, как минимум необычно).
Итак если подойти к вопросу с практичской точки зрения - можешь поглядеть;
http://ru.vlab.wikia.com/wiki/UML_проектирование_гибкой_архитектуры_игр
http://habrahabr.ru/post/123220/
А вообще советую скачать http://vortex2d.codeplex.com/releases/view/60496 (как раз таки под .НЕТ)
Потому что проектировать структуру движка без понимания того как оно вообще работает... ну это я думаю понятно))
Разобраться там в целом не сложно.
Когда то я также фанател от создания своей игры но подошел к вопросу с практической точки зрения. И понял что игра, которая играется и игра, которая разрабатывается это совершенно разные и абсолютно непохожие вещи, первая это развлечение, вторая - работа, причем работа ничуть не уступающая например постройке собственного дома.
И если продолжить эту аналогию, то вот такие слова при постройке собственного дома примут такой вид
Предполагаемая структура движка
Предполагаемый план строительства дома
*.exe - собственно то, что объединит все написанное в одну кучу.
Дом - собственно то что объединит все в одну кучу.
*.core.dll - библиотека для *.exe файла, которая будет являться каркасом приложения (графический интерфейс, элементы управления, ссылки на файлы конфигурации и ссылки на необходимые составляющие элементы игрового движка).
Бревна - Материал для Дома, который будет являться его каркасом (крыша, стены, пол, а также другие составляющие его элементы)
objects - папка с моделями и текстурами (с форматом моделей пока не определился, склоняюсь к написанию собственного).
Подвал на моей даче - место с краской и гвоздями (с длиной пока и цветом пока не определился)
scripts - папка со скриптами в формате (*ini, *.lua или аналогичном)
Чердак на моей даче - место с чертежами (txt, jpg или аналогичном)
sounds - звуки
Кухня - кухня
Это первоначальная задача. На данном этапе можно попробовать реализовать хотя бы это - сделать *.dll библиотеку с основными классами и прикрепить к ней простенький *.exeшник (на подобие dxmut).
Это первоначальная задача. На данном этапе можно попробовать хотя бы найти материал с гвоздями и сделать из этого домик (на подобие кукольного).
Если уж понять эту аналогию, то в твоем плане нет ни чертежей дома ни структур ни тем более даже видения того каким он должен быть. Надеюсь аналогия стала понятной и пока ты не выдашь конкретные предложения с конкретными задачами.
А-ля:
Предлагаю начать новый опен-сорс проект для реализации игрового движка. Можно обсудить имеет ли смысл писать свой рендер и физическую подсистему или мы попытаемся объединить кучу фреймворков в одно с целью создание некого шаблона для будущей игры.
Pharaon, В целом ты прав. Более того я даже понимаю, о чем идет речь. Темку я сделал как раз для того, чтобы люди вроде тебя смогли внести свой вклад в общее дело.
или мы попытаемся объединить кучу фреймворков в одно с целью создание некого шаблона для будущей игры
Если тебе удастся найти dxmut, то тебе не составит труда изучить его и вынести свой вердикт. А по поводу объединения фреймворков - из этого ничего не получится. Я пытаюсь сказать, что нам необходимо сделать что то свое, на подобие такого вот фреймворка и постепенно доводить его до ума.
P.S. Если надо, то я попытаюсь найти dxmut и прикрепить его к теме. Файл будет в виде проекта *,csproj написанный на шарпе. Екзешник с примером прилагается.
Xenar,
Чтобы сделать свой полноценный движок с открытым кодом... Для этого потребуется целое сообщество заинтересованных людей. При этом обладающих специфическими знаниями. Как минимум нужно толково показать а почему собственно твоей проект будет лучше того же Юнити или Огра? Требуется просто гигантская работа, на которую уйдет не один год чтобы собрать даже предварительную альфу или бетку, поэтому в основном и обращаются к уже готовым решениям.
Но... Если тебя не смущает потратить несколько лет своей жизни, собрать вокруг себя команду и создать продукт который может заинтересовать сообщество - вперед. Только согласись одной темой на форуме игромании не отделаешься, тут нет профессионалов, котоыре нужны, а если и есть то их очень мало и их нечем впечатлить. Потому что Опен-сорс как философия, еще не проела всем мозг настолько чтобы окунаться в неё с головой.
Скажем так, можно попытаться, сделать Роад-мап, определиться с приоритетами, то есть отойти от абстрагрования "а давайте сделаем движок" и подойти непосредственно к технологиям "что и кто нам нужны".
Ты предлагаешь начать с шаблона? Тогда сразу давай определим технические требования к движку. Если пока ничего не понятно, я могу еще отписаться, но и я в этой области еще особо не ходил.
P.s. Ты предлагаешь писать движок используя технологии дотНет и директХ. Тут можно пойти несколькими путями. Писать собственноручные обертки по код шарпа, то есть по сути создание собственного Апи поверх ДиретХ, что будет все-таки медленней оригинальной работы напрямую с ДХ, или брать уже готовые но со своими костылями.
Ты хочешь все своё, это похвально, есть как минусы так и плюсы, однако под уровень кризиса выйти скорее всего не получится, и даже больше, используя тот же ДиректХ все равно придется дело иметь с неуправляемым кодом, если хочешь серьезно этим заняться вот она первая цель - DirectX .Net Api, дальше будет все еще сложней)
Но опять же встает вопрос уровень возможностей конечного продукта, что упирается в создание своего роад мапа и все по кругу...)
В общем требуется некая определенность, которую может решить тот кто собственно и создает продукт, идейный вдохновитель, если ты не сможешь взять на себя такую роль, то никто не сможет, ведь те кто могут уже это сделали)
vBulletin® v3.8.0, Copyright ©2000-2025, Jelsoft Enterprises Ltd.