А можно объяснить, как Юнити связана с серверной стороной и что она там делает? Я думал, это движок для отрисовки, который выполняется только на клиенте.
А-а, ты начал статью практически так же, как и я. Теперь мне придётся переписывать абзац. Давай организуемся, чтобы не переводить одно и то же по два раза.
В мире Java всё — ООП, кроме чисел, символов и булевых переменных. Так что, в моём понимании, объекты — это уже ООП.
А для хайлоада и реляционная модель неактуальна, на её место приходит NoSQL, как я понял. И хайлоад для ММО, в принципе, не нужен особо, если у нас 5к человек на сервер. По-моему, тут больше проблема в геймдизайне, чтобы сделать интересную игру, а не в технической реализации. Так что, лучше писать, как проще, и уже когда игровая схема взлетит, тогда и заниматься оптимизацией производительности.
На одном из сайтов написали новость про Мейл, и там особенно повеселило это предложение:
Издателем станет всем нам знакомая компания Mail.ru, под крылом которой уже находятся такие будущие проекты, как Ashes of Creation и Conqueror's Blade.
То есть, Мыло знаменито благодаря будущей Ashes of Creation. Не тем, что они делали Аллоды и Скайфорж, а также локализовывали кучу игр. Это мелочи, по мнению авторов заметки, и больше раздражает игроков. Зато Ashes of Creation делает Мыло крутым и знакомым.
Всё равно для Мыла корейцы делали отдельный билд, а не просто выдали тот же файл, что работал для Кореи. Видимо, вручную копировали или включали рецепты, и забыли включить один из них. Обычная человеческая ошибка.
Исправить это легко, да. Видимо, поленились, или решили, что невысокий приоритет у этого бага, игроки подождут неделю-две.
Посмотрел всю эту презентацию. На этапе, где они заменили цикл на переменную, а вложенный цикл на обычный, подумал: «Авторы презентации, вы что, меня за идиота держите?». Ясное дело, что если убрать вложенный цикл, то производительность возрастёт в разы. Вот только это ничуть не противоречит ООП. Дальше в презентации аналогично. Если сохранить PositionComponent в переменную, а не искать её каждый раз в списке с проверкой типа, то очевидно, что программа будет работать быстрее.
Единственное, где они отошли от ООП — это на последних слайдах, где вместо списка объектов сделали несколько списков, по одному списку для каждого поля. И это ускорило программу аж 28% в их случае (43ms→31ms update). Улучшение небольшое, и я думаю, что более сложный код не стоит того. Но в некоторых особо сложных ситуациях может помочь.
Выводы, что я сделал: ООП живее всех живых и отлично работает. А если писать лишние циклы, то это будет тормозить при любой парадигме программирования.
Плюсов всё равно больше, чем от изобретения своих велосипедов.
Небесных портов и арктического биома, думаю, не будет в 2019 году. Хоть бы войны за территории сделали и поисправляли баги в них.
А для хайлоада и реляционная модель неактуальна, на её место приходит NoSQL, как я понял. И хайлоад для ММО, в принципе, не нужен особо, если у нас 5к человек на сервер. По-моему, тут больше проблема в геймдизайне, чтобы сделать интересную игру, а не в технической реализации. Так что, лучше писать, как проще, и уже когда игровая схема взлетит, тогда и заниматься оптимизацией производительности.
То есть, Мыло знаменито благодаря будущей Ashes of Creation. Не тем, что они делали Аллоды и Скайфорж, а также локализовывали кучу игр. Это мелочи, по мнению авторов заметки, и больше раздражает игроков. Зато Ashes of Creation делает Мыло крутым и знакомым.
Исправить это легко, да. Видимо, поленились, или решили, что невысокий приоритет у этого бага, игроки подождут неделю-две.
Единственное, где они отошли от ООП — это на последних слайдах, где вместо списка объектов сделали несколько списков, по одному списку для каждого поля. И это ускорило программу аж 28% в их случае (43ms→31ms update). Улучшение небольшое, и я думаю, что более сложный код не стоит того. Но в некоторых особо сложных ситуациях может помочь.
Выводы, что я сделал: ООП живее всех живых и отлично работает. А если писать лишние циклы, то это будет тормозить при любой парадигме программирования.