Мне ещё нравился Белвер, который локализовывал Рифт. Правда, перевод был не очень и рассказывали, что при закрытии игры они плохо себя повели. Но зато не делали отсебятины и более-менее вовремя устанавливали обновления.
Но лучше самого разработчика, конечно, ничего нет.
Поначалу понравилось, а потом начали так расхваливать ECS, будто пытаетесь мне её продать.
Любая оптимизация, поиск багов и исправления в уже существующих системах очень сильно упрощается за счет полной изоляции.
Если сущности изолированы, как они будут взаимодействовать между собой?
любые взаимодействия могут быть созданы буквально простым добавлением данных в таблицу.
Я так и не понял разницу между добавлением поля в сущности и добавлением поля в обычном объекте. Что там, что там одна строчка кода для поля плюс логика обработки.
Возможность создавать сущности, которые имеют любые свойства прямо в игре абсолютно без ограничений и без необходимости что-то дописывать это очень удобно, поверьте.
Чем это отличается от объектов в JavaScript и других динамических языках? Там тоже можно добавлять любые свойства в процессе выполнения программы. Или обычным HashMap, где ключ — название поля, а значение — любой объект в качестве значения поля? Только производительностью?
В конце статьи ссылка на статью, написанную 11 лет назад, что ECS — это будущее. Теперь это будущее уже наступает?
Сказать такое — всё равно, что заявить, будто дома строят не строители. А строители просто ставят кирпичи. Игры создают все — и программисты, и геймдизайнеры, и тестировщики, и даже игроки. Не нужно преуменьшать ценность кого-то из них.
В статье, правда, много воды. Также хотелось бы реальных примеров, а не иерархий диалогов печати файла и сохранения шаблонов, которые не имеют отношения к играм.
Не соглашусь с объявлением ООП виновником всех бед. Если сталкиваетесь с проблемами в иерархиях, то не нужно делать такие длинные и развесистые иерархии, а лучше использовать композицию. Я хоть и не игру делаю, но у меня обычно трейт или абстрактный класс, который расширяет библиотечный класс, и у него пара наследников. Всё.
Писать многопоточный код намного сложнее, чем однопоточный, но причём здесь ООП? Разве многопоточный код со struct-ами на чистом С или даже ассемблере выглядит проще и понятнее? В любом случае нужно или куча синхронизаций при работе с shared mutable state, или неизменяемые объекты и функциональный подход (всё равно объекты, как ни крути). Или пересылать сообщения в очередях.
Для высоконагруженных систем есть микросервисы, которые, опять же, на объектно-ориентированных языках обычно пишутся.
Работает — не трогай
Этот принцип подходит далеко не всегда, а только для тех частей программы, которые Не нужно развивать. Например, ланчер или окошко настроек. Их один раз написали, и больше новых функций от них не потребуется. А вот для основного кода, который всё время развивается, лучше другой принцип — постоянный рефакторинг. Тогда и будет нормальный код, который не придётся полностью переписывать, а только частично поменять при добавлении новой механики.
Любой, кто будет писать ерунду или в неподобающем тоне, получит минусы. Это как раз правильная дорога. А вот обижаться на обоснованные минусы — такое мы не раз уже видели.
Это ещё не самое страшное, тут хотя бы не получится купить предмет в шопе, чтобы пропустить часть игры. Играть нужно, и наверняка много, чтобы получить толк от дополнительных прохождений данжа. Хотя, всё равно влияет на баланс.
А это легко проверяется. Допустим, вам дали задание разрабатывать игру по подписке и сказали: «Ваша задача, как геймдизайнера, сделать интересную игру. Про доход не волнуйтесь». Стали бы вы тогда делать периоды, где игрок страдает, а потом влачит жалкое существование? Я уверен, что нет, так как эта игра просто распугала бы игроков. Они перестали бы платить подписку и советовать игру своим друзьям.
Официальный дискорд на английском языке. Или Мыло уже сделало свой?
А, вижу, в официальном дискорде сделали русские каналы, и есть даже 2 русских КМа. Но цитата эта от обычного игрока, который, видимо, запустил гуглоперевод, а не официальная.
Обычно я беру или не беру квесты мышкой. Можно кнопкой F взять, а эспкейпом закрыть диалог. Но намного лучше, если квесты берутся сами, когда заходишь в зону его выполнения, либо постоянно висят в списке (как ачивки).
Но лучше самого разработчика, конечно, ничего нет.
Если сущности изолированы, как они будут взаимодействовать между собой?
Я так и не понял разницу между добавлением поля в сущности и добавлением поля в обычном объекте. Что там, что там одна строчка кода для поля плюс логика обработки.
Чем это отличается от объектов в JavaScript и других динамических языках? Там тоже можно добавлять любые свойства в процессе выполнения программы. Или обычным HashMap, где ключ — название поля, а значение — любой объект в качестве значения поля? Только производительностью?
В конце статьи ссылка на статью, написанную 11 лет назад, что ECS — это будущее. Теперь это будущее уже наступает?
В статье, правда, много воды. Также хотелось бы реальных примеров, а не иерархий диалогов печати файла и сохранения шаблонов, которые не имеют отношения к играм.
Не соглашусь с объявлением ООП виновником всех бед. Если сталкиваетесь с проблемами в иерархиях, то не нужно делать такие длинные и развесистые иерархии, а лучше использовать композицию. Я хоть и не игру делаю, но у меня обычно трейт или абстрактный класс, который расширяет библиотечный класс, и у него пара наследников. Всё.
Писать многопоточный код намного сложнее, чем однопоточный, но причём здесь ООП? Разве многопоточный код со struct-ами на чистом С или даже ассемблере выглядит проще и понятнее? В любом случае нужно или куча синхронизаций при работе с shared mutable state, или неизменяемые объекты и функциональный подход (всё равно объекты, как ни крути). Или пересылать сообщения в очередях.
Для высоконагруженных систем есть микросервисы, которые, опять же, на объектно-ориентированных языках обычно пишутся.
Этот принцип подходит далеко не всегда, а только для тех частей программы, которые Не нужно развивать. Например, ланчер или окошко настроек. Их один раз написали, и больше новых функций от них не потребуется. А вот для основного кода, который всё время развивается, лучше другой принцип — постоянный рефакторинг. Тогда и будет нормальный код, который не придётся полностью переписывать, а только частично поменять при добавлении новой механики.
А, вижу, в официальном дискорде сделали русские каналы, и есть даже 2 русских КМа. Но цитата эта от обычного игрока, который, видимо, запустил гуглоперевод, а не официальная.