Ответ: Clear Engine (Понятный движок)
 

1) data driven & data oriented design

скажем если гейм\левел дизайнер не может взять ваш движок и вставить туда спрайт или скрипт сам - нафиг такой движок нужен

2) everything is data pipeline

если движок сам не может себе автоматически конвертить контент быстро и удобно - нафиг надо, юнити умеет потому юнити и популярное

3) object as pure aggregation

http://cowboyprogramming.com/2007/01...your-heirachy/

node ? component ? не нужно

4) SoA

вы все еще пишите float x,y,z ? не нужно

5) хардкод техник рендер пайплайна, как в UE, CryEngine и прочих

делать возможность впилить свое HBAO на уровне данных ? ой, а как вы его сделаете на мобилках ? рендер техники это code path forever

6) data flow programming, reactive programming для некоторых вещей наподобие пайплайна рендера и шейдеров

императивные подходы не всегда решают однако

7) clear C11 only

если подходить со стороны интерфейсов в data driven движке то ооп там не сильно надо, ибо это тупо плеер данных, как пример могу показать интерфейс моей библиотеки которая агрегирует разные социальные сдк под мобилки : https://github.com/Goortom/dd-publis...d_publishing.h, посмотрите насколько он чистый и простой, даже почти не нужна справка

или например интерфейс библиотеки загрузки изобрежаний : http://pastebin.com/xbdcZPC8 (пока не в паблике), посмотрите насколько он простой, нужно добавить к нему всего две функции и вы получите сверх мощную либу которая умеет грузить данные напрямую через memory mapped files

C11 это мощнейший язык, после того как перенесли потоки и атомарные операции в библиотеку мы почти полностью отвязались от POSIX, теперь стало возможно делать библиотеки без убер фреймворка, и писать их на чистом C11

и вообще


8) dual quaternions graph

как показывает практика - скейл объектов это очень вырожденный случай, и скейл в самом дереве трансформов не нужен, потому можем отказаться от матриц вообще и сильно ускорить все вычисления

9) lua

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

10) heap ? malloc ? new ?

тупо не нужно, вообще, просим страницы виртуальной памяти напрямую у ОС

11) everything is async, no callbacks

если можно сделать без коллбеков - делаем без коллбеков

ps. плюс еще куча мудрости, я так сходу и не вспомню =)

Ответ: Clear Engine (Понятный движок)
 

мм как? либо коллбеки, либо какая-то проверяющая хрень с интервалом ожидает готовности.

Ответ: Clear Engine (Понятный движок)
 

представь какая каша в коде получается если у тебя async file io в несколько потоков и коллбек после загрузки, ты просто погрузнешь в мьютексах чтобы правильно потом отработать загруженные файлы

а с проверяющей "хренью" у тебя получается чистый lock-free код, ты обрабатываешь результаты асинхронных операций по мере возможности, и никаких тебе мьютексов

в таком lock-free коде если ты встречаешь место где тебе нужно просто подождать - используешь await подобный паттерн, как в c# http://msdn.microsoft.com/en-us/libr.../hh156528.aspx

Ответ: Clear Engine (Понятный движок)
 

jimon, я хз про что ты тут распинаешься, но помоему все эти убер фичи, которые умеет Unity не вписываются в концепцию моего движка, да даже если я и захочу что-то запилить, разве составит проблем внести новую абстракцию? Зачем же тогда умные книжки про ООП? Для того, что бы потом не столкнуться с проблемами. Как же Ogre3D, он очень сильно ООП и популярен.

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

Ответ: Clear Engine (Понятный движок)
 

предлагаешь геймдизайнеру ставить вижуал студию и писать код ?

Ответ: Clear Engine (Понятный движок)
 

я тебя не понимаю. Игру пишет программист, причем тут гейм дизайнер...
и да dod нет смысла использовать. Ну с экономим 50% производительности, но это при условии, что мы заюзаем 100500 нод на сцене.
На самом деле никто такого использовать не будет. Unity игры вообще вон на C# пишут с наследованиями и ничего норм работает.

Ответ: Clear Engine (Понятный движок)
 

Ты недооцениваешь геймдизайнеров, они и не на такое способны.

Ответ: Clear Engine (Понятный движок)
 

ну вы скажите как должно быть ))) я походу не сильно в теме гейм дизайна

Ответ: Clear Engine (Понятный движок)
 

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

движки разные бывают, какой бы ты не писал - это уже опыт и это хорошо =)

Ответ: Clear Engine (Понятный движок)
 

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

Ответ: Clear Engine (Понятный движок)
 

Запилил работу с пост эффектами.

Ответ: Clear Engine (Понятный движок)
 

а свои шейдеры как?

Ответ: Clear Engine (Понятный движок)
 

scene->addPostProcessProgram(ownProgram);

Ответ: Clear Engine (Понятный движок)
 

и куда они рендерить будут, как отрендерить сколько-то пассов одними и потом заюзать в другом, как сделать даунсемпл в цепочку в 2 раза более маленьких текс до 1 пикселя (например, яркость экрана для хдр подсчитать), как дела с MSAA, где вообще выбираем РТ, ну и т. д.

Ответ: Clear Engine (Понятный движок)
 

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