Обычно движки работают с некимactor, смесью Monster и подконтрольного игроку Hero.
В оригинале: Most of the engine just deals with “actors”, the superclass of both Monster and the player-controlled, gender-nonspecific Hero. (Основная часть (моего) движка работает с actor, надкласса как Monster так и управляемого игроком бесполого Hero.)
Текущая версия Dart [15 июля 2014] полностью основана на ASCII, хотя, что забавно, использует canvas API.
В оригинале: The current Dart version is all ASCII-based right now, ironically rendered using the canvas API. (Текущая версия (игры) на (языке) Dart работает только с ASCII визуализацией, хотя, что забавно, используя canvas API) - там дальше он упоминает о версии игры на C#.
Зачем привязываться к смещениям для вызова реализации из наследника? Можно объявить нужные "абстрактные" методы в базовом объекте, с реализацией по умолчанию (на всякий случай).
И, как выше упоминали, у вас получаются жирные объекты за счет того что они несут все функции в себе. Это прототипное ООП (как в JS), иногда имеет смысл конечно, но при более сложной модели стоит выделить такие функции в мета-объекты (классы) и держать единственную ссылку на класс в каждом объекте.
Раздувание ПО трогает только тех кто привык контролировать внутреннюю работу своих железок, знать что сколько ресурсов занимает, и скрупулезно следить за файлами и процессами.
Типичный современный пользователь об этом может вообще не знать, и когда сталкивается с отсутствием свободного места, проблема решается просто и относительно дешево - стереть лишнее или прикупить диск побольше. И то что новая железка (в купе с новой версией ПО) делает примерно тоже самое и примерно с той-же скоростью, для него не так важно. Зато это новая железка (в рекламе которой производитель показал лучшие цифры чем в прошлой) и новая программа (покрасивее, больше анимации и т. д.).
А с точки зрения бизнеса, все вообще хорошо, продажи растут, и надо продолжать в том же духе.
В переводе местами смысл теряется. Например:
В оригинале: Most of the engine just deals with “actors”, the superclass of both Monster and the player-controlled, gender-nonspecific Hero. (Основная часть (моего) движка работает с actor, надкласса как Monster так и управляемого игроком бесполого Hero.)
В оригинале: The current Dart version is all ASCII-based right now, ironically rendered using the canvas API. (Текущая версия (игры) на (языке) Dart работает только с ASCII визуализацией, хотя, что забавно, используя canvas API) - там дальше он упоминает о версии игры на C#.
Зачем привязываться к смещениям для вызова реализации из наследника? Можно объявить нужные "абстрактные" методы в базовом объекте, с реализацией по умолчанию (на всякий случай).
И, как выше упоминали, у вас получаются жирные объекты за счет того что они несут все функции в себе. Это прототипное ООП (как в JS), иногда имеет смысл конечно, но при более сложной модели стоит выделить такие функции в мета-объекты (классы) и держать единственную ссылку на класс в каждом объекте.
Раздувание ПО трогает только тех кто привык контролировать внутреннюю работу своих железок, знать что сколько ресурсов занимает, и скрупулезно следить за файлами и процессами.
Типичный современный пользователь об этом может вообще не знать, и когда сталкивается с отсутствием свободного места, проблема решается просто и относительно дешево - стереть лишнее или прикупить диск побольше. И то что новая железка (в купе с новой версией ПО) делает примерно тоже самое и примерно с той-же скоростью, для него не так важно. Зато это новая железка (в рекламе которой производитель показал лучшие цифры чем в прошлой) и новая программа (покрасивее, больше анимации и т. д.).
А с точки зрения бизнеса, все вообще хорошо, продажи растут, и надо продолжать в том же духе.