node — 0.4.12. Насчет флагов просвещусь. Но это не только v8, firefox также себя ведет.
«for (… in ...) должен приводить к деоптимизации всей функции» очень интересно понять, о чем вы говорите :) можете поделиться ссылками, где можно прочитать про внутренности v8?
я проверяю наличие вебсокетов. если их нет, то будет сообщение об этом. а вот если websocket есть, а подключиться через прокси не удается — то возможно бесконечно «подключение...» висеть будет.
тут две причины: или вы начинаете игру когда еще не набралось игроков на две команды, то есть три и более игроков. или вы наткнулись на баг, о котором я еще не знаю. скорее всего первое.
пока-что сервер не загружается больше чем на 40%. Бесконечная загрузка, может быть из-за того, что вы за прокси рубящей websocket траффик. я не знаю как потестить эту ситуацию, у меня то сервер под рукой. поэтому внятного сообщения об ошибке не могу пока сделать. Как вариант можно на странице websocket.org/echo.html проверить работу websocket. Хотя если тесты на websocket.org работают, это еще не значит что между моим сервером и вами нету такой прокси.
Виноват, в статье смешал два понятия клиента. В общем, на сервере есть объект user. Этот объект каждые 50мс проверяет, если ли что отправить браузеру и отправляет данные, если они есть. То есть клиен-браузер не дергает сервер, а объект user на сервере, как клиент лога событий, запрашивает изменения у этого самого лога.
В node, как я понял, все асинхронное, и мой код только «просит» отправить данные клиенту, и тут же продолжает выполнение. А отправка данных происходит уже позже.
Возможно как раз придется реализовывать эту идею, потому что я уперся в объем трафика.
Слать изменения немедленно очень накладно, за один игровой шаг может измениться с десяток свойств, придется рассылать изменение каждого свойства по отдельности. Слать изменения пакетами должно быть быстрее. Сокеты нужны потому что: 1) — это одно постоянное подключение. 2) клиент не дергает каждый раз сервер, если есть что послать клиенту, сервер каждые несколько миллисекунд сам отправляет данные.
Пересылка только начала движения и остановки, и вычисление текущего положения самим клиентом имеет смысл как оптимизация, когда пересылка текущих координат станет узким местом. Но пока я этого делать не стану, потому что тут будут проблемы рассинхронизации в случае тормозов на сервере. Я бы не назвал алгоритм исправления таких погрешностей простейшей задачкой.
Готовится статься про оптимизацию, думаю до конца месяца будет готово. Проблема с пересечениями решена. Решена не идеальным способом, но теперь на первом плане в результатах профилирования совсем другие вещи.
Кто-то под ником aim в чате игры предложил такую идею: разбить объекты игры на две группы, 1 — неподвижные объекты, их можно хранить в двумерном массиве, что позволит быстро искать пересечения. а танки, пули, бонусы хранить в виде списка прямоугольников (ну или в виде дерева) и обрабатывать их как сейчас. Должен получить хороший выигрыш по производительности. Идея мне понравилась, найти бы время реализовать её.
Я плохо себе представляю как это синхронизировать, если каждый клиент будет себе считать игру. Но как вариант можно сделать, чтобы один игрок выступал в роли «сервера», то есть игра обсчитывается у одного игрока, а данные для других пересылаются через реальный сервер. Но к сожалению это не из тех вещей которые бы я мог быстро провернуть. Возможно когда-нибудь будет так.
Я к сожалению не считал точное кол-во подключений. Но пара десятков пользователей в чате, 2-3 игры и сервер уже еле ворочается, а со временем node занимает 100% процессорного времени даже если нет ни одной активной игры. В общем стыд и срам.
Если не секрет что именно не удобно в google code? так же кликаете по папка и файлам и смотрите исходники. и github… он разве не только для Git? вообще я Mercurial использую в этом проекте.
так и есть, каждая «1» представляет собой 4 кусочка стены. такой точности достаточно чтобы нарисовать уровень. а в памяти кусочки хранятся по другому и отстреливаются по четверти.
О да! Я мечтаю переписать танчики на Erlang. Но дело не только в javascript. Сам код писался без прицела на производительность. Основной задачей до публикации было как можно скорее сделать что-то работающее.
«for (… in ...) должен приводить к деоптимизации всей функции» очень интересно понять, о чем вы говорите :) можете поделиться ссылками, где можно прочитать про внутренности v8?
В node, как я понял, все асинхронное, и мой код только «просит» отправить данные клиенту, и тут же продолжает выполнение. А отправка данных происходит уже позже.
Возможно как раз придется реализовывать эту идею, потому что я уперся в объем трафика.
Пересылка только начала движения и остановки, и вычисление текущего положения самим клиентом имеет смысл как оптимизация, когда пересылка текущих координат станет узким местом. Но пока я этого делать не стану, потому что тут будут проблемы рассинхронизации в случае тормозов на сервере. Я бы не назвал алгоритм исправления таких погрешностей простейшей задачкой.