Мне ещё нравился Белвер, который локализовывал Рифт. Правда, перевод был не очень и рассказывали, что при закрытии игры они плохо себя повели. Но зато не делали отсебятины и более-менее вовремя устанавливали обновления.
Но лучше самого разработчика, конечно, ничего нет.
Не думаю, что кто-нибудь из существующих локализаторов сумел бы как-то улучшить подход к локализации по сравнению с корейской версией, поэтому, действительно, или разработчик, или кто-то, кто отсебятину хотя бы пороть не будет. В этом плане мне Destiny с локализацией Теры понравились.
Поначалу понравилось, а потом начали так расхваливать ECS, будто пытаетесь мне её продать.
Любая оптимизация, поиск багов и исправления в уже существующих системах очень сильно упрощается за счет полной изоляции.
Если сущности изолированы, как они будут взаимодействовать между собой?
любые взаимодействия могут быть созданы буквально простым добавлением данных в таблицу.
Я так и не понял разницу между добавлением поля в сущности и добавлением поля в обычном объекте. Что там, что там одна строчка кода для поля плюс логика обработки.
Возможность создавать сущности, которые имеют любые свойства прямо в игре абсолютно без ограничений и без необходимости что-то дописывать это очень удобно, поверьте.
Чем это отличается от объектов в JavaScript и других динамических языках? Там тоже можно добавлять любые свойства в процессе выполнения программы. Или обычным HashMap, где ключ — название поля, а значение — любой объект в качестве значения поля? Только производительностью?
В конце статьи ссылка на статью, написанную 11 лет назад, что ECS — это будущее. Теперь это будущее уже наступает?
Подход, в общем-то, тот же, но Mail умеет вносить в него дополнительные нюансы, скажем так. По опыту Revelation, например, это дополнительная монетизация через сайт (билеты на рулетки и другие «весёлые» акции) и игромаркет, а ещё — перенос ивентовых наград в шоп.
Мы не стали делать вид, что написание действительно быстрой и удобной ECS нам под силу, так что выбрали очень многообещающий открытый проект, вот ссылочка. Товарища можно поддержать на птреоне, ато там с поддержкой что-то совсем все грустно(
Лично яб с радостью еще один плюсик заметке поставил бы только за отсылку к статьям Адама Мартина (T-Machine). :)
Любому инженеру, решившему понять семейство ES парадигм, в первую очередь стоит обратиться к статьям и wiki этого человека. Адам занимается развитием этого семейства еще с начала нулевых. Тема CO/ES/ECS является очень старой. Без это всего реализация таких игр как, например, Prototype, стала бы крайне затруднительной.
William_Godwin , мне вот что стало интересно. Какую реализацию компонентного подхода вы решили выбрать для своего проекта?
Существует подход под названием DDP (Data-Driven Programming). В рамках этого подхода программа разбивается на уровни ответственности.
Есть подозрение что это вообще хороший тон при написании больших программ.
Ответственность растет от человека, где она минимальна, в сторону кремния, где ответственность максимально высокая.
Не уверен. На постановщиках и архитекторах намного больше отвественности. Их ошибка может запороть работу кодеров намного сильнее чем наоборот.
Код с высоким уровнем ответственности создается в виде разрозненных и атомарных блоков логики.
Есть подозрение что ТЗ стоит тоже включить в эту иерархию и тогда код с высоким уровнем пишется вообще на естественном бюрократическом или экономическом языке.
Простой вопрос всем кто считает что локализацией Lost Ark должен был заниматься другой издатель, напишите пожалуйста что за компания это должна быть? и почему?
У тебя получилась крайне спорная дихотомия. Или оно не нужно клиентам, или владельцы бы не выбрасывали продукт.
А что если старый продукт нужно выбросить для того, чтобы следующий твой продукт начал бы приносить больше прибыли? Суть в этом.
Меняются технологии, меняются взгляды, меняются методы оплаты. Продукт, созданный из расчета на одну модель оплаты, вряд ли может быть перестроен на другую модель. Потому что после перестройки на другую модель оплаты продукт может оказаться уже немного другим. Или совсем другим.
Я понимаю что вы имеете ввиду, и в укоре есть определенный смысл. С другой стороны люди, которые делали игру в которую я играю сейчас, больше ее не разрабатывают и не продают. Они выбросили ее на свалку и делают совершенно другой продукт. Мне не стыдно что я не играю в то, что сейчас называют Lineage 2. Сейчас я играю в настоящую Линейку (без рейтов, шопа, мечей в виде рыб, шоколадок и прочего скама). Отдаю, так сказать, дань уважения труду разработчиков игры, а не гуру графиков-поводков.
Своими действиями я не пытаюсь сэкономить и не заплатить правообладателю, получив доступ к пиратской копии их продукта. Я хочу получить то, что правообладатель буквально — выбросил.
Значит большинству игроков это не нужно, иначе бы не закрывали а делали сервы по отдельным версиям хроник. Рынок сделал свое дело
Но лучше самого разработчика, конечно, ничего нет.
Если сущности изолированы, как они будут взаимодействовать между собой?
Я так и не понял разницу между добавлением поля в сущности и добавлением поля в обычном объекте. Что там, что там одна строчка кода для поля плюс логика обработки.
Чем это отличается от объектов в JavaScript и других динамических языках? Там тоже можно добавлять любые свойства в процессе выполнения программы. Или обычным HashMap, где ключ — название поля, а значение — любой объект в качестве значения поля? Только производительностью?
В конце статьи ссылка на статью, написанную 11 лет назад, что ECS — это будущее. Теперь это будущее уже наступает?
Любому инженеру, решившему понять семейство ES парадигм, в первую очередь стоит обратиться к статьям и wiki этого человека. Адам занимается развитием этого семейства еще с начала нулевых. Тема CO/ES/ECS является очень старой. Без это всего реализация таких игр как, например, Prototype, стала бы крайне затруднительной.
William_Godwin , мне вот что стало интересно. Какую реализацию компонентного подхода вы решили выбрать для своего проекта?
Не уверен. На постановщиках и архитекторах намного больше отвественности. Их ошибка может запороть работу кодеров намного сильнее чем наоборот.
Есть подозрение что ТЗ стоит тоже включить в эту иерархию и тогда код с высоким уровнем пишется вообще на
естественномбюрократическом или экономическом языке.А что если старый продукт нужно выбросить для того, чтобы следующий твой продукт начал бы приносить больше прибыли? Суть в этом.
Меняются технологии, меняются взгляды, меняются методы оплаты. Продукт, созданный из расчета на одну модель оплаты, вряд ли может быть перестроен на другую модель. Потому что после перестройки на другую модель оплаты продукт может оказаться уже немного другим. Или совсем другим.