Архитектурные компромиссы в разработке игр

[axel_pervoliajnen]

Солидно. Интересно.Откуда столько подробностей про внутреннею архитектуру всех (!) приличных игр?

[dalerank]

В основном gdc, но все интересное обычно платное, много в книгах и блогах разработчиков. Часть материала лежит или лежала в сети, к каким-то материалам был или есть доступ.

[strannik_k]

Спасибо за интересную, полезную и крутую статью!

В такую большую статью было бы здорово добавить ссылки-якоря на главы для удобства навигации.

[dalerank]

Сделаю. Хорошая идея

[vvzvlad]

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

[AtariSMN82]

Сколько времени делалась статья?

[dalerank]

Это материал, который не попал в книгу по тем или иным причинам. Поднял черновики и немного сократил и упростил, выкинул примеры, а на написание самого текста ушло вечера четыре

[lgorSL]

Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.