p
Привет. Что почитать про архитектуру игр?
Size: a a a
2020 September 21
AK
Привет. Что почитать про архитектуру игр?
Если речь про техническую часть, то очевидный Game Engine Architecture.
p
Кхм, а что-то попроще? Я не хочу быть гейм девелопером, просто по фану делать простенькие игры в телеграмме/текстовые.
p
Писал по наитию, столкнулся с тем что система выходит нерасширяемой, и трудно добавлять новые фичи.
AT
Кхм, а что-то попроще? Я не хочу быть гейм девелопером, просто по фану делать простенькие игры в телеграмме/текстовые.
Тогда, должно быть, больше подойдёт так называемая "The Elm Architecture". 😊
AK
Кхм, а что-то попроще? Я не хочу быть гейм девелопером, просто по фану делать простенькие игры в телеграмме/текстовые.
Game Programming Patterns ещё неплохой. Проще и более абстрактно.
AT
Писал по наитию, столкнулся с тем что система выходит нерасширяемой, и трудно добавлять новые фичи.
На этот счёт написано несколько хороших книжек в области "паттернов проектирования" и вокруг. Несколько лет назад особо модной была "Domain Driven Design". Сечас в моду — особенно около разработки игр — входит "Data Driven Design".
AT
В контексте Rust более актуальной может быть "Domain Driven Design Made Functional", но это не точно.
AT
Вообще, в качестве реплики в сторону — "паттерны проектирования" предполагались к видоизменению и адаптации по месту использования, что означает "нужно думать головой". Чтобы адаптировать паттерны в контексте Rust головой придётся думать немного больше, чем обычно.
q
Насколько адекватно использовать 2 отдельных ECS мира (в hecs, например): один для ассетов/прототипов, один для игровых объектов/экземлпяров?
R
Если у тебя 2 "мира", то логично иметь 2 инстанса
Worldq
ну я про World и говорю, я о том, чтобы не смешивать Entity-шаблоны/ассеты и Entity-экземпляры.
q
Например в первый мир грузить текстуры, а во второй "спрайты" с позициями и ссылкой на текстуру из первого мира
q
Или в первый мир грузить шаблон юнита, а во второй экземпляр юнита, который "наследует" параметры шаблона
R
Не совсем понятно зачем вообще грузить текстуру в World
AT
Или в первый мир грузить шаблон юнита, а во второй экземпляр юнита, который "наследует" параметры шаблона
Звучит как instancing... 🤔
q
Не совсем понятно зачем вообще грузить текстуру в World
Например если у тебя большой игровой мир и ты не знаешь когда тебе какой то ассет понадобится, то можно при использовании какого то ассета писать ему к компонент последнее время использования. А потом в соответствующей систему проверять все давно неиспользованные ассеты и выгружать их из gpu или ram.
Ну и с ECS можно подобный механизм один раз сделать, а не дублировать его для каждого типа ассета/шаблона. как пример.
Ну и с ECS можно подобный механизм один раз сделать, а не дублировать его для каждого типа ассета/шаблона. как пример.
R
Например если у тебя большой игровой мир и ты не знаешь когда тебе какой то ассет понадобится, то можно при использовании какого то ассета писать ему к компонент последнее время использования. А потом в соответствующей систему проверять все давно неиспользованные ассеты и выгружать их из gpu или ram.
Ну и с ECS можно подобный механизм один раз сделать, а не дублировать его для каждого типа ассета/шаблона. как пример.
Ну и с ECS можно подобный механизм один раз сделать, а не дублировать его для каждого типа ассета/шаблона. как пример.
С шаблонным кодом можно тоже не дублировать код
R
А ссылаться из одного мира в другой, потом индексировать для получения каждой текстурки и меша, ну такое
R
Или в первый мир грузить шаблон юнита, а во второй экземпляр юнита, который "наследует" параметры шаблона
Вот давайте не изобретать наследование в ECS