[Лог #6] Немного о структуре движка.

» опубликован
Темой этого лога будет «движок» или «думы об игровой структуре».
Всё очень просто – будет текст с диаграммами, которые не содержат кода, но надеюсь дают понять, как же будет работать сама программа. Не претендую на «это самая крутая организация программы» или «вот как надо делать, учитесь!», скорее лог ориентирован (как и вся серия) на некий диалог с сообществом, ведь среди читателей, возможно, есть те, кто уже делал подобное и\или готов поделиться своими мыслями по этому поводу.
Для начала расскажу про кроссплатформенность, вернее что это значит для моих проектов. Когда выходит новая игра и она «кроссплатформенна», то обычно это значит, что проект выходит, например, на <PC, PS3, Xbox360, PS4. Честно говоря не знаю как труЪ-инди попасть на консольки (насколько я знаю нужна специальная девелоер версия консоли? И аккаунт разработчика, короче, кто знает – поделитесь), поэтому для меня кроссплатформа – это ОС семейства Windows и Linux-подобные, а для Mac ситуация практически аналогичная консолям – нужно спец.железо и статус разработчика (могу быть не прав, поправьте если это не так).
Собственно моя игра должна быть ориентирована на две «платформы» - Windows и Linux (или же SteamOS).
Для каждой операционки нужно будет компилировать проект отдельно - это в лучшем случаи, а в худшем - переписывать значительную часть кода, поэтому логичнее всего избежать двойной\тройной\N-ой работы и свести её к минимуму, а для этого я планирую «распилить» архитектуру приложения так, что часть, зависимая от конкретной платформы была как бы отделена от основного игрового кода.

Работа с окнами

В Windows каждый элемент графического интерфейса – это «окно», даже кнопка – это «окно», разумеется в рамках кода. Для игры же необходимо минимум одно окно, в которое будет рисоваться сцена, отправляется сообщения ( нажатия клавиш, например) - это немного. Собственно тут нет ничего сложного, «платформозависимая часть» - это специфичный код для ОС, например, создание окна программы, отлавливание различных событий, например, нажатие клавиш, изменение положения мыши, сворачивание или закрытие программы.
Весь код, который будет работать с API(application programming interface) ОС нужно завернуть в более простую "упаковку" (можно сказать, создать свой API), например, функции создания окна, позиционирования его на экране и установке его размера можно разместить в своей функции и назвать её, скажем, CreateAppWindow( тут-параметры ).

Общая часть

Здесь уже нужно «изолироваться» от ОС. Отличным примером общего кода служит набор функций\классов математической библиотеки - различным векторам и матрицам не важно какую ОС вы используете, как и большей части игровой логики. Для набора игр можно определить какие-то базовые структуры, например, игровой объект, сцена, где происходит всё действие или же функции-указания как загружать 3Д модель.
Иногда всё же необходимо работать с ОС, вернее использовать её функции в игровых целях. Например, если необходимо получить список файлов сохранения в какой-то папке – это может сделать ОС, а для простоты использования можем написать функцию (в платформозависимой части), что-то типа GetFilesInDir( path ), а результат такой функции будет список имён файлов, например.

Конкретная часть

Это уже реализация самой игры, вернее её код. Генерация предметов идёт уже в эту часть.
Помимо всяких специфичных для игры функций, здесь можно написать и жанровые заготовки, например, полёт камеры как в RTS, конечно если реализовывать жанры, то получится ещё один «уровень», что может пригодиться в будущем, если планируется писать кучу игр разных жанров :)

Графика, звук и сетевая часть

Программа должна показывать на экране картинку - игровую сцену, но как ей это делать? Хотя скорее вопрос «чем?». Я уверен, что вы слышали о DirectX и OpenGL, ведь именно они являются «слоем» между видеокартой и программой, по сути именно они и рисуют. Но какую же лучше библиотеку использовать? Когда-то я использовал DirectX, затем перешёл на OpenGL, думаю и дальше буду использовать OpenGL т.к. он кросплатформенный.
Со звуком аналогичная ситуация, можно взять специфичную библиотеку или найти общее решение. Больше использовал DirectSound (часть DirectX), потом немного программировал с OpenAL, ещё слышал, что есть XAudio для Windows.
Сетевая часть … что? Но ведь в игре не планировался мультиплейр, зачем же тогда сеть реализовывать? А ответ вот такой: даже синглплейр может быть устроен как мультиплейр, конечно это какая-то бредовая фраза, но лучше приведу пример. Надеюсь все знают и играли в Half-Life 2 ( или другие игры на движке Source), а ведь в ней только одиночная игра и при этом реализованная она как клиент-сервер, только вот сервер этот локальный. Я думаю это очень крутая идея – реализовать игру как клиент-сервер и не брать во внимание то, что она только для одного игрока. В чём же прикол такого подхода? Всё просто – более быстрая реализация мультиплейра (если он предусмотрен заранее), просто ввести дополнительные игровые правила и всё. Такой подход даст возможность реализовать "Бродилку" для одного игрока, а через какое-то время сделать, например, мультиплейрные баталии, скажем PvE.

Программа – бесконечный цикл

Вот примерная блок-схема программы.
Нет ничего сложного :)

Ввод пользователя или осмысленный копипаст с Quake\Doom\Half-Life

Копирование заключается в консольной части, уж больно мне понравилось как они это сделали - "динамические" переменные программы и различные команды. Возможно вы знаете эти команды, например, "noclip" или "impulse 101". Но не только в командной консоли дело, ещё очень крутой вещью является "биндинг клавиш", например, "bind W +move" (или как-то так). Суть биндинга\привязки заключается в назначении клавише консольной команды, конечно вряд ли смогу использовать всю мощь, которую даёт такой подход, но по крайней мере пользователь сможет сам настроить управление.

Что дальше ?

На самом деле понятия не имею) Скорее всего, что-то по концептам будет.
Так и не сделал лог#5+ :(
Вообще планировал больше диаграмм и картинок, но как-то не пошло : (


Просмотров: 8 893

» Лучшие комментарии


Это сообщение удалено
I_D_ #2 - 5 лет назад 0
Для взаимодействия с консолью придётся парсер писать муторное дело :(
Кросплатформенность сделать не так тяжело если сразу об этом задуматься и не привязывать логику к ОС, тогда нужно только работу с окнами и файлами будет переделать под другую платформу.
А вот насчёт сервер-клиент он должен перед отрисовкой идти (может быть).
И насчёт кросплатформенности как начёт SDL
H #3 - 5 лет назад 2
Не пойму зачем изобретать свои велосипеды, когда все уже давно придумано. На любой язык для геймдева есть кросплатформенный фреймворк, с графическими, сетевыми и логическими функциями, которые отлично отлажены и работают на любой платформе.
alexprey #4 - 5 лет назад 2
H, самопознание же
Kozinaka #5 - 5 лет назад (отредактировано ) 0
Я думаю это очень крутая идея – реализовать игру как клиент-сервер и не брать во внимание то, что она только для одного игрока. В чём же прикол такого подхода? Всё просто – более быстрая реализация мультиплейра (если он предусмотрен заранее).
Похоже, что вытачивая на токарном станке шахматы, ты первым начинаешь вытачивать себе журнальный столик, на котором эти шахматы будут стоять. Во-первых, это в два раза дольше пилить, а во-вторых, всё равно придётся выбросить и делать заново, т.к. разрабатывая сингл ты ещё не знаешь проблем, которые встанут при реализации мультиплеера. Скорее всего, у ребят, с которых ты берёшь пример, уже была разработана клиент-серверная архитектура для другого проекта, и они вписали в неё новый проект.
H, кроссплатформенные фреймворки умирают даже быстрее, чем появляются. Юнити один и живёт, остальные через пару-тройку лет глохнут. Если я к релизу игры 5 лет иду, то мне полюбому в процессе придётся мигрировать с движка на движок, снова изучать какую-то внешнюю байду, которая скоро откинет копыта. Впрочем, это старый спор, не думаю, что из него ещё что-то конструктивное можно вытянуть. Попрепираемся, да и разойдёмся каждый со своим мнением и движком. :)
alexprey #6 - 5 лет назад 2
кроссплатформенные фреймворки умирают даже быстрее, чем появляются.
Ты наверное про те, что делаются ноунеймами?
Kozinaka #7 - 5 лет назад 0
alexprey, я не очень в этом глубоко в теме. Когда думал заюзать движок для спрайтовой графики всё натыкался на какие-то заброшенные проекты. Отбило охоту доверять свою свой проект-деточку каким-то анонимным ленивым засранцам. :)
DarkDes #8 - 5 лет назад 0
Kozinaka:
Не спорю, что придётся дольше писать и проблемы могут возникнуть и там и там, но я ещё думаю над этим )
Первые альфы конечно будут реализованы "в лоб", без всяких наворотов.
H:
Многие так яро хотят посадить велосипедиста на иглу движок, но если так уж хочется то конечно я могу написать на каком-нибудь GameMaker или Unity3D тест игровой механики, ладно если механика игры примитивна (как у меня).
Вообще не понимаю зачем писать змейку на Unreal Engine 4 :)
nvc123 #9 - 5 лет назад 3
DarkDes, у тебя до этого были мультиплеерные игры?
если нет то пиши обычный сингл
I_D_ #10 - 5 лет назад 0
Kozinaka:
alexprey, я не очень в этом глубоко в теме. Когда думал заюзать движок для спрайтовой графики всё натыкался на какие-то заброшенные проекты. Отбило охоту доверять свою свой проект-деточку каким-то анонимным ленивым засранцам. :)
Точно сказано та-же проблема.
А действительно нормальные двиги в большинстве своём платные увы.
quq_CCCP #11 - 5 лет назад 0
Ну а что не попасть на консоли, www.engadget.com/2013/07/16/sony-ps4-development-kit-fcc покупаем девкит, по цене несколько раз выше цены потребительской консоли...
У сони на ps4 вроде 1000 баксов в сша девкит стоил...
На старые платформы (ps3\xbox360) нужна прошитая консоль и собственно софт для компиляции и сборки игры, на б\у прошитые консоли ценники куда демократичнее.
Kozinaka #12 - 5 лет назад 0
quq_CCCP, чё, купил девкит и скомпилил и ага, можно продавать? В смысле, при наличии игрухи я могу попасть в PlayStation Store просто за штуку баксов? Мне кажется на окончании разработки игры история только начинается.
quq_CCCP #13 - 5 лет назад 1
Не ну конечно же в комплекте есть договор с Sony, какие там условия я незнаю, скорее всего твоя игра попадет в раздел демок и будет доступна пользователям ps+ а ты бабок не получил пока твоя ига не станет популярной и небудет 10000 скачиваний.
Kozinaka #14 - 5 лет назад 0
quq_CCCP, прикольно, такой PS-Greenlight
Nortiul #15 - 5 лет назад 0
Хотелось бы что бы попала)
ZLOI_DED #16 - 5 лет назад 2
Да. На первых этапах столкнулся с той же проблемой.
Потом уже уходишь в детали и дай Бог если хватит сил думать об архитектуре и продолжать её выстраивать как надо. Иначе грядёт большой рефакторинг. Именно так строится разработка в одиночку.
Kozinaka #17 - 5 лет назад 0
ZLOI_DED, рефакторинг будет в любом случае, это неизбежно. Заранее всё не спроектируешь, жизнь она штука непредсказуемая по большей части.
alexprey #18 - 5 лет назад 0
Kozinaka, однако чем больше опыта, тем меньше рефакторинга)
Kozinaka #19 - 5 лет назад 0
alexprey, не соглашусь. Десять лет назад я вообще не знал, что это такое. Я писал код не оглядываясь. :D
alexprey #20 - 5 лет назад 0
Kozinaka, а я писал код, потом понимал что тлен и писал с 0, знаю уже о проблемах, которые возникнут :D Так я переписывал 4 раза свой сервер для игрушки :D
Kozinaka #21 - 5 лет назад 0
alexprey, это не рефакторинг, это зановопереписывинг. :)
alexprey #22 - 5 лет назад (отредактировано ) 2
Kozinaka, ну это и есть рефакторинг :D Только такой, глобальный в рамках всего проекта
ZLOI_DED #23 - 5 лет назад 2
alexprey:
Kozinaka, ну это и есть рефакторинг :D Только такой, глобальный в рамках всего проекта
Ага. Написал 10К строчек кода - переписал 8К. Как-то так)))
Это сейчас модно на XGM логи разработки вести? Ок. Как-нибудь напишу свой)
DarkDes #24 - 5 лет назад 0
а я писал код, потом понимал что тлен и писал с 0
Ооо, как это мне знакомо :D
Это сейчас модно на XGM логи разработки вести?
Логи - это всегда модно интересно :)
Kozinaka #25 - 5 лет назад 0
ZLOI_DED, стильно, модно, молодёжно! Вливайся!