История изменений

Любая игра, примитивно, — это банальный цикол опроса в котором дергаются подсистемки, которые сами знают чего им делать, что описывается конечным автоматом если не лень а обычно длинный свич «апдейтания» всего подряд :) Логика игоря только оркеструет чего грузить, да в каком порядке рисовать, как реагировать на ввод от юзиря, да как считать коллизии и исходы. А всякие «класс Elf наследует от BaseCharacter руки-ноги + длинные ухи» — это устаревшее «ненужно», существующее только на уровне скриптов, и то не всегда, внутри двигла никто так щас не делает: все игровые объекты — тупо коллекции «свойств», обрабатываемых в своих подсистемах (еще тупее - коллекции индексов экземпляров ресурсов, обрабатываемых исключительно в подсистемах в виде плоских коллекций. Особенно если ориентируемся на современный OpenGL и шейдеры, которыми обрабатываются плоские коллекции... вершин треугольников. В примитивных игрушках типа тетриса даже любимый почем зря «граф сцены», ни octree не нужны от слова вообще) Именно поэтому Lua отлично справляется с описанием этих табличек свойств и часто пристегивается к готовому движку, который ничо про логику конкретного игоря не знает, в качестве настраивательной скриптоты (хотя мне больше нравится AngelScript или js): игрологика получается такая - «Загрузи пачку моделек», «загрузи пачку звуков», «а между модельками и звуками задай вот такие соответствия», «чекай такие коллизии, показывай то-то и вон тот клевый звук еще», «чекай такой-то ввод — делай то-то» - для удобства дезигнера обычно оперируют спеками игровых объектов (смотрим любой редактор — описание объекта — тупо табличка, даже визуально), но внутри движка-то их все одно нет — только плоские коллекции каждая в своей подсистеме :) Внутри подсистем/компонентов никто не запрещает пользоваться «ООП по канонам», но развесистых иерархий тоже не будет — благо все ресурсы конкретной подсистемы однотипные :) Где можно применить ООП? Ну, в описании сцен, если скриптовой клей позволяет — и то наследование тут с успехом заменяется агрегацией :) Но примитивно сцена — ох, щи... опять коллекция описаний объектов :)

Любая игра, примитивно, — это банальный цикол опроса в котором дергаются подсистемки, которые сами знают чего им делать, что описывается конечным автоматом если не лень а обычно длинный свич «апдейтания» всего подряд :) Логика игоря только оркеструет чего грузить, да в каком порядке рисовать, как реагировать на ввод от юзиря, да как считать коллизии и исходы. А всякие «класс Elf наследует от BaseCharacter руки-ноги + длинные ухи» — это устаревшее «ненужно», существующее только на уровне скриптов, и то не всегда, внутри двигла никто так щас не делает: все игровые объекты — тупо коллекции «свойств», обрабатываемых в своих подсистемах (еще тупее - коллекции индексов экземпляров ресурсов, обрабатываемых исключительно в подсистемах в виде плоских коллекций. Особенно если ориентируемся на современный OpenGL и шейдеры, которыми обрабатываются плоские коллекции... вершин треугольников. В примитивных игрушках типа тетриса даже любимый почем зря «граф сцены», ни octree не нужны от слова вообще) Именно поэтому Lua отлично справляется с описанием этих табличек свойств и часто пристегивается к готовому движку, который ничо про логику конкретного игоря не знает, в качестве настраивательной скриптоты (хотя мне больше нравится AngelScript или js): игрологика получается такая - «Загрузи пачку моделек», «загрузи пачку звуков», «а между модельками и звуками задай вот такие соответствия», «чекай такие коллизии, показывай то-то и вон тот клевый звук еще», «чекай такой-то ввод — делай то-то» - для удобства дезигнера обычно оперируют спеками игровых объектов (смотрим любой редактор — описание объекта — тупо табличка, даже визуально), но внутри движка-то их все одно нет — только плоские коллекции каждая в своей подсистеме :) Внутри подсистем/компонентов никто не запрещает пользоваться «ООП по каноннам», но развесистых иерархий тоже не будет — благо все ресурсы конкретной подсистемы однотипные :) Где можно применить ООП? Ну, в описании сцен, если скриптовой клей позволяет — и то наследование тут с успехом заменяется агрегацией :) Но примитивно сцена — ох, щи... опять коллекция описаний объектов :)

Любая игра, примитивно, — это банальный цикол опроса в котором дергаются подсистемки, которые сами знают чего им делать, что описывается конечным автоматом если не лень а обычно длинный свич «апдейтания» всего подряд :) Логика игоря только оркеструет чего грузить, да в каком порядке рисовать, как реагировать на ввод от юзиря, да как считать коллизии и исходы. А всякие «класс Elf наследует от BaseCharacter руки-ноги + длинные ухи» — это устаревшее «ненужно», существующее только на уровне скриптов, и то не всегда, внутри двигла никто так щас не делает: все игровые объекты — тупо коллекции «свойств», обрабатываемых в своих подсистемах (еще тупее - коллекции индексов экземпляров ресурсов, обрабатываемых исключительно в подсистемах в виде плоских коллекций. Особенно если ориентируемся на современный OpenGL и шейдеры, которыми обрабатываются плоские коллекции... вершин треугольников. В примитивных игрушках типа тетриса даже любимый почем зря «граф сцены», ни octree не нужны от слова вообще) Именно поэтому Lua отлично справляется с описанием этих табличек свойств и часто пристегивается к готовому движку, который ничо про логку конкретного игоря не знает, в качестве настраивательной скриптоты (хотя мне больше нравится AngelScript или js): игрологика получается такая - «Загрузи пачку моделек», «загрузи пачку звуков», «а между модельками и звуками задай вот такие соответствия», «чекай такие коллизии, показывай то-то и вон тот клевый звук еще», «чекай такой-то ввод — делай то-то» - для удобства дезигнера обычно оперируют спеками игровых объектов (смотрим любой редактор — описание объекта — тупо табличка, даже визуально), но внутри движка-то их все одно нет — только плоские коллекции каждая в своей подсистеме :) Внутри подсистем/компонентов никто не запрещает пользоваться «ООП по каноннам», но развесистых иерархий тоже не будет — благо все ресурсы конкретной подсистемы однотипные :) Где можно применить ООП? Ну, в описании сцен, если скриптовой клей позволяет — и то наследование тут с успехом заменяется агрегацией :) Но примитивно сцена — ох, щи... опять коллекция описаний объектов :)