Обновить
4
Виталий Качан@MANAB

.Net Developer

0,1
Рейтинг
1
Подписчики
Отправить сообщение

Ну допустим, пока старфид разрабатывался, могли параллельно для новой TES писать квесты, сценарий, разрабатывать лор и прочее. Движок скорее всего возьмут от старфилда, натянут на него скины средневековья. На космический корабли натянут кожу дракона, вместо космических станций будут замки, бластеры заменят на посохи, вымершие предтечи станут дворфами, вместо тысячи планет сделают тысячу сгенерированных локаций. Вжух и TES6 готов.

И начнется с того, что главный герой находит артефакт свиток.

Вся статья ради рекламы finprophet который мертв?

От чела, торгующего 5 лет, странно видеть 2 статьи про алготрейдинг с "водой" - почти никак к алготрейдингу не относящиеся.

Тоже хотел отметить, что архитектура сильно завязана на то, какие инструменты и материалы можно использовать. К примеру, имея только песок и воду вряд ли можно реализовать 3х этажный коттедж, нужен еще сам строитель и придумать, как сделать чтобы песок с помощью воды превратился в достаточно крепкий материал и приобретал нужную для использования форму.

Т.е. архитектура учитывает не только инструменты, но и параметры реализуемого объекта.

Предположу, что сложно запомнить бесконечную иерархию. Почти тоже самое, что запоминать спагетти-код)

Ну многие живые оргинизмы и нашли сразу же батискаф поврежденный, 100%. Не уверен правда, что на дне много передвигающихся слепых. Но для тех, кто наверху от них толку нету - сигналы не поступали.

А приручить выполнять любой приказ нужно для чего? Для реализации своих целей. Ок, согласен, гнобление это результирующий эффект, не самоцель.

Этот дебилизм плановой экономики появился не просто так, а из идеологии конкретных людей. И возвращаясь к этому заново вопрос (риторический) - было ли гнобление людей самоцелью.

Было ли гнобление самоцелью, когда расстреливали миллионами для выполнения плана? Ну да, гнобили еще и для ускоренной индустриализации, но было и то и другое, а не что-то одно.

А можно узнать, сколько времени из 1/600.000 уходит в вашей реализации на сериализацию/десериализацию и что вообще в это время у вас входит?

Этот подход можно заметить и в WEB серверах (apache, nginx) и менеджерах процессов PHP - FPM где нужно вручную указать количество этих параллельных потоков (процессов) - они называются в них workers

Я именно этот абзац комментировал. Подход в много воркеров там в основном по другой причине.

А если посмотреть скорость сериализации/десериализации то отличие на порядки также в пользу бинарной. Но с json проще прототип начать делать.

В веб серверах количество воркеров или потоков именно для работы с CPU, а не чтобы максимально быстро данные с сетевой карты считать. Обработка http-запросов занимает от миллисекунд до секунд, и оптимизация микросекундныхзадержек тут на самом последнем уровне. А вот сколько запросов параллельно обсужит от пользователей - как раз на первом, но это количество тоже до тысячи обычно, а то и 64 стандартно.

По идее бесшовность и распределение по физическим машинам нужна для динамического управления нагрузкой на сервер. Тогда в разные моменты времени каждый сервер обрабатывает разные размеры карт. У вас такое заложено?

Ну и далее мне видится, что должны бытт сервера, которые обсчитывают физику и взаимодействие, а должны еще быть типа прокси - куда игрок стучится и от кого получает обновляемые данные мира + всякие агрегируемые данные, типа сообщения в чатах и т.п.

Вроде и работал с Unity, но видимо надо разобраться с ECS, т.к. не понял ни сути проблемы, ни решения, ни области, к которой это применяется. Все очень абстрактно для меня.

<занудство>

Я один в первом абзаце увидел "расскажу как ускорить бинарный поиск в сотни раз", а в конце сравнение резульиатов менее чем в 2 раза? Понимаю, что не все рассказали, но хотелось бы получать то, что заявлено или тогда уже переформулировать, что "в конце цикла статей вы узнаете как ускорить бинарный поиск в сотни раз".

</занудство>

<занудство>

Ну как минимум если у вас кликер и числа обновляются чаще раза в секунду - уже стоило задуматься на реализации без ToString, чтобы избежать лишних вызовов GC.

Ну и вместо BigInteger, раз все равно сокращаете, можно было бы использовать double. Если нужно реально больше 300 цифр в числе - можно придумать свой формат, где будет double + степень. При обновлении все что меньше определенной точности итак не имеет значения. BigInteger на больших числах может быть слишком медленным и тоже утечки памяти провоцировать.

</занудство>

А так вообще прикольно.

Если тестовое прислали и что-то не так, то просьба это переделать - уже звоночек о кидалове. Если что-то не так, то или 1) вы нам не подходите, или 2) давайте обсудим, почему вы сделали так, а не по другому, т.к. потенциал виден, может и подойдете.

Я вот много чего хочу делать для себя, но малейшая сложность и "лучше новости читану". А когда припрет - то сложности все решаются.

Информация

В рейтинге
4 332-й
Откуда
Warszawa, Mazowieckie, Польша
Дата рождения
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Разработчик игр
Ведущий
От 10 000 $
C#
.NET
Git
SQL
Английский язык
REST
ASP.NET
ASP Classic
.NET Core
Unity3d