Кто ему мешает платить такие же зарплаты в России? Там он платит много, здесь мало. Может дело не в стране, а в людях?
Ему мешает тот факт, что находясь в России, он зарабатывает меньше.
На российскм рынке цены на IT много ниже, а на западном заказчики при прочих равных предпочитают местных западных подрядчиков. Российских подрядчиков нанимают только в случае серьезной выгоды по цене.
Можно лучше. Скажем если этажей 100, то сначала бросаем с 10го. Если разбилось, то действуя далее вашим способом хватит 11 бросков максимум. Если нет, то к оставшимся 90 этажам применяем тот же способ.
Начинать с 10го этажа скорее всего не оптимально, но даже так выйдет лучше полного перебора
Тут немного шире проблема. Я был неточен.
Сам js на котором написана логика клиента — медленный и к тому ж однопоточный. Первый шаг в сторону его ускорения — asm.js Именно его использует Unity и, соответственно, эта игра.
Дальше ждем webassembly а также поддержку многопоточности.
Ну и работает пока нормально только webgl 1.0 (который обертка над opengl 2).
Кроме того, реализация поддержки его браузерами пока не идеальна и улучшается почти с каждой версией.
Эту статью я читал. Там не описан протокол, там дается введение в проблемную область. Что, конечно, тоже очень полезно.
Почему вы не увидели в моей статье описание протокола, мне непонятно. Вот же оно:
клиент отсылает на сервер положение мыши раз в 120мс
получив эту управляющую команду, сервер пересчитывает координаты корабля
асинхронно, на сервере работает нитка, которая ровно один раз в те же 120мс отправляет на клиенты координаты, в которых корабль должен быть к концу следующих 120мс
получив координаты, клиенты делают простой расчет: если сейчас кораблик находится в точке А, то с какой скоростью надо передвигать его в течение следующих 120мс, чтобы он оказался в пришедшей с сервера точке B
На сегодня 111 человек сохранили статью в избранное, что говорит о некоторой её полезности.
Насчет ссылки — тут дилемма. Поставь — вы упрекнете в рекламе. Не поставь — спросите: «Где пруфы, Билли?»
Можно, но сложновато. Не в том смысле, что лень делать. А в том, что каждый новый уровень сложности добавляет в систему хрупкости. Если можно не усложнять, нужно не усложнять.
Неудивительно. Но я не нашел ни на Хабре ни где-то еще четкого описания такого протокола. Именно с поиска я и начал. Но везде были только общие слова про обеспечение одновременности.
Тонкость в том, что поступающего из игры потока внутриигровой валюты должно хватать абсолютному большинству игроков. Статистика по нашим другим играм: 99% игроков играют бесплатно. 1% настоящих фанатов игры делают всю кассу.
Ему мешает тот факт, что находясь в России, он зарабатывает меньше.
На российскм рынке цены на IT много ниже, а на западном заказчики при прочих равных предпочитают местных западных подрядчиков. Российских подрядчиков нанимают только в случае серьезной выгоды по цене.
Начинать с 10го этажа скорее всего не оптимально, но даже так выйдет лучше полного перебора
Сам js на котором написана логика клиента — медленный и к тому ж однопоточный. Первый шаг в сторону его ускорения — asm.js Именно его использует Unity и, соответственно, эта игра.
Дальше ждем webassembly а также поддержку многопоточности.
Ну и работает пока нормально только webgl 1.0 (который обертка над opengl 2).
Кроме того, реализация поддержки его браузерами пока не идеальна и улучшается почти с каждой версией.
Кстати, если у вас комп с двумя видеокартами, то браузер всегда использует ту, что послабее.
WebGL штука прожорливая
Можно физически уменьшить окно браузера — это помогает видеокарте.
Можно зайти в настройки и повыключать все что можно (фон, вращение, качество моделей)
Но играть на таких настройках грустно.
Почему вы не увидели в моей статье описание протокола, мне непонятно. Вот же оно:
На сегодня 111 человек сохранили статью в избранное, что говорит о некоторой её полезности.
Насчет ссылки — тут дилемма. Поставь — вы упрекнете в рекламе. Не поставь — спросите: «Где пруфы, Билли?»