LINUX.ORG.RU

Game_engine. Черновой вариант применения. Сишники, геймдевелы прошу в студию.

 , , ,


1

2

Что же продолжу, вчера наткнулся на свою старую доку в которой для себя описывал работу игрового движка который я пытался написать давным, давно(но он канул в лету, мир его праху). Разрабатывая в настоящее время опять движок подумал хоть он и не готов(и будет это ещё не скоро) главное в голове сформирована архитектура на основании которой можно написать вариант использования движка,
для того чтобы стало ясно как с ним работать. И я практически от балды накидал малюсенький шаблон. Она не призвана к тому чтобы объяснить всё. я хочу чтобы вы поняли и рассудили подход к использованию движка, а не конкретный код.

Имена функций и переменных от балды.

Рекомендуется к хоть по беглому взглянуть на это и это.

#include <engine.h>


int map_init()
{
/*
Описание ресурса, движек сам ищет необходимый файл по имени
если путь не указан,так же передаём тип объекта что бы менеджер 
ресурсов знал с чем имеет дело при формировании списка на обработку
конвееру.

*/
int map=load_object("map_street_01",model);                    ///загрузим модель.
int giga_texture=load_object("giga_texture_street_01",texture);///загрузим для неё текстуру.
/*
Физические параметры это тоже объект, это файл
с описанием физических характеристик объекта.
*/
int physix_map=load_object("physix_street_01",physix);         ///загрузим физические параметры.


/*
Виртуальный объект это набор идентификаторов которые передаются 
менеджеру ресурсов по идентификаторам, менеджер ресурсов знает кто чем является 
формирует список и передаёт его конвееру который последовательно прогоняет даные 
по подсистемам и производит все необходимые операции. 
*/
return virtual_object(map,giga_texture,physix_map);///создадим новый объект модель+текстура+физика
};


/*описываем объект*/
int car_init()
{

int car=load_object("car_audi",model);       ///загрузим модель.
int car_texture=("audi_texture_red",texture);///загрузим для неё текстуру.
int physix_car=("audi_physix",physix);       ///загрузим физические параметры.




return virtual_object(car,car_texture,physix_car);///создадим новый объект модель+текстура+физика
};





int main()
{
init_all();                ///лень возиться, инициализируем что есть разом.
base_vfs("/data/data.pak");///указываем  расположение нашей виртуальной фс.
base_dir("/data/conf");    ///указываем  где брать конфиги.
init_config("game.conf");

int map_street_01=map_init_street();///формируем объект карта.
int car_audi_red=car_init();        ///формируем объект бибика.


while(set_key_q!=1)
{

flip_game();///Заводим исполнение конвеера.


/**

GAME CODE

**/

};

quit_all();


return 0;

/**
Список- это последовательность объектов над которыми должны произойти преобразования.

Конвеер это подсистема которая завязывает все остальные подсистемы в цепь обработки.
*/



};

★★★★★

Последнее исправление: Dron (всего исправлений: 1)

Вот то, что ты делаешь в car_init можно вынести в скрипты, как это сделано в сам_знаешь_где.

netcat ★★
()
Ответ на: комментарий от netcat

Да ты прав, по идее планируется и скрипты и на прямую.

Объект можно целиком и полностью описать его конфигом который потом просто проинициализировать и всё.

Dron ★★★★★
() автор топика

Предлагаю упростить загрузку модель+текстура+физика до

return virtual_object("car_audi","audi_texture_red","audi_physix")

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

trex6 ★★★★★
()
Ответ на: комментарий от trex6

Предлагаю упростить

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

необходимо хранить ссылки на загруженные ресурсы

Да конечно, эта работа возложена на менеджер ресурсов.

Dron ★★★★★
() автор топика

Некоторые моменты:

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

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

unfo ★★★★★
()
Ответ на: комментарий от unfo

одна текстура для модели — слишком грустно

Это просто пример. а не ограничение не стоит переживать по этому поводу .

есть куча форматов, в которых модель уже с тестурами

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

нюансы, например, добавление шейдеров к объектам

Тут всё гораздо проще чем с физикой на самом деле.

операции с дочерними элементами модели

А вот это действительно нужно как то разрулить не руша архитектуру проекта. Зачётное замечание.

надо изучить как можно больше других.

Да конечно, но и головой тоже думать весело.

Dron ★★★★★
() автор топика
Ответ на: комментарий от netcat

Вот видишь, Dron.

Да, но это не отменяет кайфа от реализации своих мыслей.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

надо изучить как можно больше других.

Да конечно, но и головой тоже думать весело.

<friday-mode>

Говорил Ленька Поттеринг, злобно ухмыляясь и потирая ручонки :)

</friday-mode>

unfo ★★★★★
()
Ответ на: комментарий от unfo

Говорил Ленька Поттеринг, злобно ухмыляясь и потирая ручонки :)

Ох не думаю что это вообще можно сравнивать.

Dron ★★★★★
() автор топика
Ответ на: комментарий от netcat

Ну неет :)

Я немного заразился идеей «всё есть файл» и на самом деле прыгаю от этого немного исказив «всё есть объект» в том плане что его можно просто взять и задать свойства.

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

Разраб может прикрутить скажем другой физ движек(будем стараться что бы это было возможно), но интерфейс обращения к физике останется прежним.

Сам движек мне проще и логичнее бить на части аля модульный подход(мне просто так легче и удобней), каждый занимается своим делом. Поэтому у каждой подсистемы своё api для обращения к ней на этих маленьких внутренних api и работает движок, благодаря этому можно заменять подсистемы скажем SDL можно заменить на allegro и тому подобное. Но это всё скрыто от разработчика за основным api, но если ему надо будет интерфейс для ковыряния во внутренностях.

Dron ★★★★★
() автор топика
Ответ на: комментарий от netcat

Дерзаю, время и люди рассудят.

Ну, а ты как со своими идеями решил распорядиться? Пилить своё, разбираться в существующем или выбрал что другое.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

движек
движек
движек
движек
движек
движек

ААААА!!!

А вообще, на C ты ничё не сделаешь. У тебя за спиной нет ведь серьёзных прожектов?

amphibrakhij
()

ТС, а тебе ссылку на мой рендерер ландшафта с карты высот дать? По мотивам Сильвермановского написан

amphibrakhij
()
Ответ на: комментарий от amphibrakhij

движек

Ну наконец то хоть кто то заметил :)

А вообще, на C ты ничё не сделаешь

Процедурный подход чем не устроил?

У тебя за спиной нет ведь серьёзных прожектов?

У всех это бывает первый раз.

Dron ★★★★★
() автор топика
Ответ на: комментарий от amphibrakhij

ТС, а тебе ссылку на мой рендерер ландшафта с карты высот дать?

До этого ещё далеко, но давай.

Dron ★★★★★
() автор топика

хендлы в виде интов это както не круто, не понятно как разделять объекты по типам: меш, текстура т.д.

комментарии парусске ужасны, это я тебе как русофоб говорю.

что подразумевается под ковейером не понятно.

я бы вообще посоветовал прежде, чем костылять движок, написать чтото простое, с минимумом подгрузок извне. даже если это тупо 100 кубиков в текстуре, которые умеют реалистично падать. возникнет понимание того, какие сущности тебе нужны и как ими управлять.

x0r ★★★★★
()
Ответ на: комментарий от amphibrakhij

Кстати, не уверен, годится ли он на что-то серьёзное, так как вся карта сразу хранится в текстуре и доступ к ней хоть и не случайный, но тоже не особо и локальный

amphibrakhij
()
Ответ на: комментарий от Dron

Процедурный подход чем не устроил?

Как будто дело в этом. Да и для игрового движка ООП был бы уместней.

amphibrakhij
()
Ответ на: комментарий от Dron

Процедурный подход чем не устроил?

1) Для игрового движка более уместно ООП
2) Для больших проектов ООП подходит намного лучше
3) Посмотри на gtk

netcat ★★
()
Последнее исправление: netcat (всего исправлений: 1)
Ответ на: комментарий от x0r

хендлы в виде интов это както не круто

Размер не устраивает, думаю пока мне хватит надо будет больше long спасёт.

не понятно как разделять объекты по типам: меш, текстура т.д.

Ну пока я всё поверхностно изложил так что ничего удивительного тип указывается при указании объекта. Если объект составной модель + сторонняя текстура. То можно обратится к составной части объекта я сейчас думаю как это реализовать.

что подразумевается под ковейером не понятно.

Конвеер это прослойка за которой лежат все системы рендер,звук,физика и т.д. при запросе к менеджеру ресурсов он составляет что-то вроде списка модель+наложить текстуру+ещё чего нибудь+отрендерить, конвеер выполняет этот список «заданий». дёргая подсистемы .

написать чтото простое.

Да конечно, но пока мне хватает кучи сторонних исходников для изучения.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

Ну пока я всё поверхностно изложил так что ничего удивительного тип указывается при указании объекта. Если объект составной модель + сторонняя текстура. То можно обратится к составной части объекта я сейчас думаю как это реализовать.

Ну а интроспекция будет хоть?

amphibrakhij
()
Ответ на: комментарий от amphibrakhij

Ты не понимаешь. int не информативен

Это идентификатор для менеджера ресурсов не более того. Ну, а если хочется информации то можно вернуть структуру по этому id.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

Размер не устраивает

моя бывшая так и сказала, когда бросала. вообще я имел ввиду std::shared_ptr<ResourceType> как хендл.

x0r ★★★★★
()
Ответ на: комментарий от unfo

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

Хм… не чем не напоминает? http://xkcd.com/927/

beastie ★★★★★
()
base_vfs("/data/data.pak");///указываем  расположение нашей виртуальной фс.

Wrong. У каждой системы есть свои стандарты расположения временных файлов, и движок не в праве их нарушать. Тем более не в праве давать пользователю движка такую возможность.

base_dir("/data/conf");    ///указываем  где брать конфиги.
Агалогично, бесполезно указывать путь к конфигам.
init_all();                ///лень возиться, инициализируем что есть разом.
init_config("game.conf");
Все эти иниты не нужны. Максимум — стандартный для каждой поддерживаемой платформы способ организации функции main.

int map_street_01=map_init_street();///формируем объект карта.
int car_audi_red=car_init();        ///формируем объект бибика.

while( set_key_q!=1)
{

flip_game();///Заводим исполнение конвеера.

Сначала загрузка, и лишь потом основной цикл — не очень удачный подход. Где задел для многопоточности? Где заставка и прогресс-бар загрузки, вполне себе требующие цикла сообщений? Где реакция на Esc или закрытие окна? Гораздо проще (и общепринято) загрузку ресурсов производить уже после запуска основного цикла. Например, движок оперирует понятием «сцена» и заставка с загрузкой ресурсов — это одна из сцен, за которой следует сцена основного меню.

Оперировать одними int — не самая удачная идея. Легко перепутать, никаких проверок соответствия данных и обрабатывающей их функции. И если в динамических языках это компенсируется рефлексией, то в C не скомпенсируется ничем.

Аналогично — load_object. Да и вообще, не надо задумывать божественную функцию, которая делает всё.

quiet_readonly ★★★★
()
Ответ на: комментарий от Dron

Тут (в шейдерах) всё гораздо проще чем с физикой на самом деле.

Голословное утверждение. Паттерны проектирования типа «декоратора» придуманы неспроста.

Да конечно, но и головой тоже думать весело.

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

quiet_readonly ★★★★
()
Ответ на: комментарий от amphibrakhij

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

int car=load_object(«car_audi»,model);

car хранит идентификатор.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron
void foo ()
{
    int id = ololo_load();
}

void bar ()
{
   // Как мне получить доступ к объекту через id?
}

Почему бы тогда не использовать простые указатели?

amphibrakhij
()
Ответ на: комментарий от quiet_readonly

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

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

Dron ★★★★★
() автор топика
Ответ на: комментарий от amphibrakhij

Почему бы тогда не использовать простые указатели?

Нее нужен идентификатор, так как он указывает на структуры объектов, а рулит ими менеджер передавая на обработку конвееру.

Как мне получить доступ к объекту через id?

:) А вот и самое интересное приехало я этого ждал, мы в теории можем создавать объекты, комбинировать их и настраивать, но я уже исплевался весь придумывая как подойти к вызову на исполнение объекта в конвеере.

Ну по идее надо зарулить ещё одну общую функцию аля load_object(); но теперь передавая ей идентификатор и параметры в char,но тут придется городить целый список комманд.

Dron ★★★★★
() автор топика
Последнее исправление: Dron (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

Да и вообще, не надо задумывать божественную функцию, которая >делает всё.

Она ничего не делает кроме передачи данных менеджеру ресурсов и возврата идентификатора объекта (ресурса).

Dron ★★★★★
() автор топика
Ответ на: комментарий от amphibrakhij

не обратил внимания, что он пишет на С

x0r ★★★★★
()

tl;dr

1. int для всего — ужасно. typedef int object хотя-бы, но лучше для каждого типа объекта иметь свой тип.

2. Почитай про организацию игрового цикла. На хабре было. Вкратце - он состоит из двух фаз — обновление мира и рендеринг. while(set_key_q!=1) ты не отделаешься. Нужно уметь распределять время между двумя фазами, что-бы не получить разную скорость игры и проседания FPS.

Конвеер это подсистема которая завязывает все остальные подсистемы в цепь обработки.

WUT?

public
()
Ответ на: комментарий от Dron

но я говорил что обсуждать конкретно код выше бесполезно это просто пример логики работы а не реализации.

Тогда чертите UML (в блокноте или Dia/Umbrella, как вам удобнее), без указания деталей реализации.

quiet_readonly ★★★★
()
Ответ на: комментарий от Dron

load_object загружает любой объект — типичная божественная функция. Даже если она передаёт управление какой-нибудь load_object2, это уже не имеет большого значения.

Идентификатором ресурса является указатель на declared, но не defined структуру или RAII-класс. Нет смысла воспроизводить недостатки прямого доступа к OpenGL, особенно в фреймворке, нацеленном на удобство.

quiet_readonly ★★★★
()
Последнее исправление: quiet_readonly (всего исправлений: 1)

P.S. (но очень важный). Рекомендую не упарываться движком, а писать игру. Параллельно придется к ней и движок писать так же, но задачи для движка будет рождать конкретная игра, а не больная фантазия программиста (у нас это профессиональное).

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

trex6 ★★★★★
()
Ответ на: комментарий от unfo

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

поправил )

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.