Пустой, или как его еще называют, маркерный интерфейс это вполне нормальное явление, даже в готовом продукте. А вот пустой класс заранее понятно, что он должен будет что-то из себя представлять.
И кстати совсем необязательно делать общехлебный интерфейс, ведь он же понадобится только при потреблении хлеба, а не при производстве, те есть может он нам и не будет нужен совсем. Чуть более простым кажется вариант, где у печей по методу на хлеб, пирожок и торт. Ну и на кирпичи понятное дело.
Но, даже заранее не зная что будет дальше, делать их все одним классом с перечисляемым полем… ну даже не знаю, у всех свой путь самурая, конечно же.
Ну вот, сразу появились «стратегии», базовые и наследуемые классы и пр. Я имел в виду то, что «хлеб» в исходной статье это переупрощение. Вряд ли кто-то пожелает, чтоб ему закодили сделать пустой класс, без состояния и поведения, в котором только тип BakeryProduct type. В реальном мире у него будут методы и события, в каждом торте и пирожке свое, и тут получится либо четырехкратный if-else, либо большой нечитаемый switch. Если его не делать изначально базовым с наследниками, то рано или поздно он придет к состоянию, когда все придется переписать с нуля, даже если требования заказчика не метания белки по лесу, а логичные и последовательные. Принцип YAGNI он, конечно же, более чем правилен, создание лишних сущностей и лишних связей между ними Борису явно не стоило даже пытаться делать. Но и Маркуса это никак не оправдывает, и то что, благодаря переупрощению, код получился без лапши еще не означает, что в реальном проекте ее не будет.
С одной стороны не надо пытаться предусмотреть какие то «изменяющиеся сущности», которых нет в требованиях, а с другой стороны не надо писать «универсальный код», когда эти сущности уже есть, лучше его разнести по классам, а не по if-else. Тут где-то и кроется та самая золотая середина, как мне кажется…
Как мне кажется, это переупрощение. Позволю себе сочинить список требований.
1) Игра походовая. Сетка гексагональная. Солдаты ходят, друг друга рубят, либо стреляют.
2) Герой должен иметь свои характеристики, которые добавляются к солдатам, плюс сам должен уметь периодически швырять какое то заклинание. Сила регулируется какой-то характеристикой героя, плюс само заклинание может быть одного из трех уровней.
3) Добавить магов, Маги должны швырять ту же магию, что и герой по типу, но рассчет силы от количества солдат. Отличие от стрелков — магия накладывает пост-эффекты, например горение постепенно сжигает здоровье, а оглушение не дает ходить какое то время и т.п.
4) Добавить препятствия и летающих солдат. Ну и сразу непролетаемые препятствия и телепортирующихся солдат.
5) Добавить солдатам активные расходуемые навыки, например лучник может один раз за игру огненную стрелу запустить. Также пост-эффекты.
6) Добавить персональные свойства, например тяжелобронированные солдаты получают меньше урона в ближнем бою, а «ловкие» периодически уворачиваются от урона, но не от магии.
На этот момент аццкая лапша имхо обеспечена, если изначально подходить к делу энумерацией. А фантазий у геймдизайнера еще немало.
А мне напоминает «лошади продают автомобили». 123 лошади в хундае это же настолько круче, чем 107 лошадей в фольксвагене. А то что они едут при этом одинаково — кого ж это волнует.
Вот так все и играют во все игры, особенно сетевые. Печально, с тоской в глазах. А ведь кроме того, что симулятор делает предпросчет, еще есть пинг, еще есть двойной или даже тройной видеобуфер, еще есть инпут лаг на телевизоре. Сколько факторов означающих, что ты уже мертв, но еще этого не знаешь, Бггг…
Вот только если игровыми объектами движет только физика, то из этого никакой игры в принципе никогда не выйдет. Ни печальной ни радостной. Казуальщина только, вроде злых птиц.
В полезности отвязки от переменного фреймрейта сомнений нет. Есть сомнения в полезности ручной интерполяции.
В отвязке без интерполяции смысла очень мало как раз, как написал автор, движение объектов будет сильно дискретным ака рывками.
Это прекрасно, что в движке SupremeCommander'а реализован continuous collision detection.
Для интерполяции не нужно детектирование коллизий. Интерполяция происходит между двумя просчитанными состояниями. Коллизии уже просчитаны. Экстраполяция отсутствует. Фиксед.
А рэгдоллы и теннисные мячики могут в игровом мире и не участвовать. Физика для них может быть также развязана по частоте от игрового мира, как и графика.
Приведу в пример игру supreme commander. Там игровой мир обсчитывается всего 10 раз за секунду. Рассчитываются не только движения юнитов и боезарядов, а еще нахождение пути A* и какой-никакой AI для тысяч этих самых юнитов.
Никаких прохождений ракет сквозь самолеты не наблюдается. Тормознутости игрового мира нет и в помине. А вот если низкий фреймрейт, то видно сразу. Теорикрафтинг это хорошо, но если развязку игрового мира от фреймрейта придумали, то значит это кому то нужно.
В какой то из статей приводилась так же и возможность изменения скорости обсчета игрового мира, при которой FPS сопадает с отсчетами игрового мира, при этом следующий отсчет рассчитывается с учетом того, сколько времени занял предыдущий, ну или среднее время нескольки предыдущих.
В сетевой игре такое неприемлемо. FPS у людей может отличаться, проблемы в этом нет, а количество отсчетов игрового мира должно совпадать. В противном случае разная погрешность вычислений приведет к тому, что объекты сместятся настолько, что, например, один игрок в другого выстрелит и попадет, а у того на системе пуля пройдет мимо и он останется жив, то есть произойдет рассинхронизация. По этой же причине исключается возможность создания так называемых реплеев.
Эта же погрешность присутствует и на отрисовке, но на ней она не накапливается.
Это — единственный образец «более строгой типизации».
Отнюдь, int нельзя присвоить в short, например, возникает ошибка предлагающая принудительный каст. Хотя «расширение» происходит автоматически.
Но это еще ладно, а вот bool меня шокировал до глубины души.
=>Какой результат оно должно выдавать, где логика?
Если честно я вообще нигде логики нашел.
Из того, что я знаю, между C# и С++ есть такие отличия, навскидку
1)Конструктор базового класса всегда вызывается в С++, а в С# ему надо указывать, иначе не вызовется.
2)protected в С# позволяет вызвать методы базового класса только на this и не позволяет вызвать их на другом объекте того же класса, в C++ это можно.
3)Более строгая типизация, нельзя int использовать как bool, например, но это уже более очевидно.
При этом у меня почему то не возникало мыслей, о том, что человеческий разум оказывается понять поведение языка C#, когда в плюсах я делал вот так а теперь не работает. Хотя местами, если не сказать большинством, эти «хочу странного», как правильно сказали, и на плюсах не имеет смысла и не будет компилиться.
ЗЫ и вообще, все эти «хочу странного» приводят к нечитаемому и неподдерживаемому коду, когда натыкаешься, хочется автора казнить ректально и прилюдно.
Для этого 180 надо разогнать, пока что таких психов не видел. Только в роликах на ютюбе, в посмертных.
Интересно было бы создать опрос, узнать будет ли человек снижать скорость, или продолжит лететь, зная что 100% упрется в красный.
И кстати совсем необязательно делать общехлебный интерфейс, ведь он же понадобится только при потреблении хлеба, а не при производстве, те есть может он нам и не будет нужен совсем. Чуть более простым кажется вариант, где у печей по методу на хлеб, пирожок и торт. Ну и на кирпичи понятное дело.
Но, даже заранее не зная что будет дальше, делать их все одним классом с перечисляемым полем… ну даже не знаю, у всех свой путь самурая, конечно же.
С одной стороны не надо пытаться предусмотреть какие то «изменяющиеся сущности», которых нет в требованиях, а с другой стороны не надо писать «универсальный код», когда эти сущности уже есть, лучше его разнести по классам, а не по if-else. Тут где-то и кроется та самая золотая середина, как мне кажется…
1) Игра походовая. Сетка гексагональная. Солдаты ходят, друг друга рубят, либо стреляют.
2) Герой должен иметь свои характеристики, которые добавляются к солдатам, плюс сам должен уметь периодически швырять какое то заклинание. Сила регулируется какой-то характеристикой героя, плюс само заклинание может быть одного из трех уровней.
3) Добавить магов, Маги должны швырять ту же магию, что и герой по типу, но рассчет силы от количества солдат. Отличие от стрелков — магия накладывает пост-эффекты, например горение постепенно сжигает здоровье, а оглушение не дает ходить какое то время и т.п.
4) Добавить препятствия и летающих солдат. Ну и сразу непролетаемые препятствия и телепортирующихся солдат.
5) Добавить солдатам активные расходуемые навыки, например лучник может один раз за игру огненную стрелу запустить. Также пост-эффекты.
6) Добавить персональные свойства, например тяжелобронированные солдаты получают меньше урона в ближнем бою, а «ловкие» периодически уворачиваются от урона, но не от магии.
На этот момент аццкая лапша имхо обеспечена, если изначально подходить к делу энумерацией. А фантазий у геймдизайнера еще немало.
Вот только если игровыми объектами движет только физика, то из этого никакой игры в принципе никогда не выйдет. Ни печальной ни радостной. Казуальщина только, вроде злых птиц.
Для интерполяции не нужно детектирование коллизий. Интерполяция происходит между двумя просчитанными состояниями. Коллизии уже просчитаны. Экстраполяция отсутствует. Фиксед.
Никаких прохождений ракет сквозь самолеты не наблюдается. Тормознутости игрового мира нет и в помине. А вот если низкий фреймрейт, то видно сразу. Теорикрафтинг это хорошо, но если развязку игрового мира от фреймрейта придумали, то значит это кому то нужно.
В сетевой игре такое неприемлемо. FPS у людей может отличаться, проблемы в этом нет, а количество отсчетов игрового мира должно совпадать. В противном случае разная погрешность вычислений приведет к тому, что объекты сместятся настолько, что, например, один игрок в другого выстрелит и попадет, а у того на системе пуля пройдет мимо и он останется жив, то есть произойдет рассинхронизация. По этой же причине исключается возможность создания так называемых реплеев.
Эта же погрешность присутствует и на отрисовке, но на ней она не накапливается.
Перепутал с джавой, видимо.
Отнюдь, int нельзя присвоить в short, например, возникает ошибка предлагающая принудительный каст. Хотя «расширение» происходит автоматически.
Но это еще ладно, а вот bool меня шокировал до глубины души.
Если честно я вообще нигде логики нашел.
Из того, что я знаю, между C# и С++ есть такие отличия, навскидку
1)Конструктор базового класса всегда вызывается в С++, а в С# ему надо указывать, иначе не вызовется.
2)protected в С# позволяет вызвать методы базового класса только на this и не позволяет вызвать их на другом объекте того же класса, в C++ это можно.
3)Более строгая типизация, нельзя int использовать как bool, например, но это уже более очевидно.
При этом у меня почему то не возникало мыслей, о том, что человеческий разум оказывается понять поведение языка C#, когда в плюсах я делал вот так а теперь не работает. Хотя местами, если не сказать большинством, эти «хочу странного», как правильно сказали, и на плюсах не имеет смысла и не будет компилиться.
ЗЫ и вообще, все эти «хочу странного» приводят к нечитаемому и неподдерживаемому коду, когда натыкаешься, хочется автора казнить ректально и прилюдно.
Интересно было бы создать опрос, узнать будет ли человек снижать скорость, или продолжит лететь, зная что 100% упрется в красный.