Комментарии 61
должно работать в Chrome 14,15 и Firefox 7
Можно расширить с помощью web-socket-js, а поддержку canvas, через excanvas или flashcanvas.
Можно расширить с помощью web-socket-js, а поддержку canvas, через excanvas или flashcanvas.
Про web-socket-js лишнее (в socket.io он вроде)
а почему предложили именно эти, а не libCanvas и Easeljs, например?
Я не так выразился: для поддержки ie можно использовать excanvas, а для браузеров без поддержки canvas — flashcanvas. Последнее по-моему лучше решение.
Тоесть flashcanvas влюбом случае должен в итоге заменить бедный vmlный excanvas?
Должен. Мне казалась тут простая графика, как раз excanvas можно использовать, но оказывается и так работает как говно.
А для «старых не ie браузеров», если нет canvas лучше и предложить обновить.
А для «старых не ie браузеров», если нет canvas лучше и предложить обновить.
Спасибо за интересные ссылки, правда сейчас основная проблема — производительность, так что до поддержки браузеров дело может и не дойти.
поддержку canvas, через excanvas или flashcanvas.
Поддержка Canvas в IE через excanvas для таких проектов — это ересь. Если оно даже на Canvas в Хроме работает как говно, то уж в старых IE.
Аааа, танчики! Это нереально круто. Просто охренительно круто. Уж простите меня за мой детский восторг.
Я в своё время познакомился с игрой Танки Онлайн (легко гуглится), очень понравилось простейшее управление и запуск прямо в браузере. В детстве я очень любил танчики на Денди (да что там, и сейчас играю, поставив эмулятор, два года назад даже джойстик для этого купил). Недавно возникла идея создать подобную Танкам Онлайн игру, но используя концепцию оригинальных дендиевских танчиков. Тут тебе и команда на команду, и бонусы, появляющиеся периодически, и какая-нибудь прокачка. It's gonna be legen...dary.
Сколько куриц было поджарено и звездочек съедено…
Тоже самое на erlang тянуло бы сотни игр без проблем на том же железе… :)
не в языке дело, как бы, а в алгоритмах :) и что-то мне подсказывает, что правильный код должен тянуть тысячи игр одновременно, сравните, блин, текущее железо и то, на котором танчики были оригинально :)
О да! Я мечтаю переписать танчики на Erlang. Но дело не только в javascript. Сам код писался без прицела на производительность. Основной задачей до публикации было как можно скорее сделать что-то работающее.
Проблема не в технологии. Node.JS прекрасно справляется с тысячами подключений и распараллеливается на несколько ядер процессора.
Насколько помню, классические танки для описания карты использовали именно двумерный массив. Остальные объекты (танки, пули) хранились отдельно и были ограничения на количество пуль и противников (чисто технические, связанные с малым объёмом памяти и тем что проц имел частоту менее 2 МГц). А просчёт столкновений с пулями считался и вовсе как-то хитро (точно не по пересечениям прямоугольников).
Придирка: в оригинальных танчиках каждый кирпичный «блок» представлял из себя квадрат не 2х2, а 4х4, поэтому за один выстрел (обычным снарядом, не прокачанным) снималась не половина блока, а только четверть.
Но почему не github? Я поясню мысль — все остальное просто не удобно для того, чтобы ознакомиться с кодом «по-шустрому». Google code это вообще позор джунглям какой-то.
Если не секрет что именно не удобно в google code? так же кликаете по папка и файлам и смотрите исходники. и github… он разве не только для Git? вообще я Mercurial использую в этом проекте.
Абсолютно всё. Нет социальности, — форков, реквестов, сети…
Я свои проекты давно мигрировал на GitHub, знаю, о чём говорю.
Вам поможет hg-git.github.com/
Я свои проекты давно мигрировал на GitHub, знаю, о чём говорю.
Вам поможет hg-git.github.com/
Mercurial сильно не повезло именно с хостингами, которые его поддерживают. Но это тема другой дискуссии.
Пробежаться в googlecode по проекту очень долго…
Их дерево пока разворачивается, потом файлы открываются в другой странице, а в Github все ajax анимация и гораздо быстрее.
+ Граммотно расположенные элементы навигации (сверху) посмотрев файл можно вернуться сразу в корень проекта
+ Локальный быстрый поиск по всем файлам
+ Network view :) мое любимое
+ Удобное расположение форка
и много мелочей
! И самый главный плюс :) Github человекоориентирован это значит заведя один аккаунт на себя можно форкать сколько угодно проектов к себе. Можете рассматривать это как workspace
Типа о классный проект танчики, положу как я его к себе (один клик) уже лежит, надо бы для себя баги пофиксить, раз и пофиксил (+ удаленно они уже сохранились), один клик и уже поделился с другими.
Их дерево пока разворачивается, потом файлы открываются в другой странице, а в Github все ajax анимация и гораздо быстрее.
+ Граммотно расположенные элементы навигации (сверху) посмотрев файл можно вернуться сразу в корень проекта
+ Локальный быстрый поиск по всем файлам
+ Network view :) мое любимое
+ Удобное расположение форка
и много мелочей
! И самый главный плюс :) Github человекоориентирован это значит заведя один аккаунт на себя можно форкать сколько угодно проектов к себе. Можете рассматривать это как workspace
Типа о классный проект танчики, положу как я его к себе (один клик) уже лежит, надо бы для себя баги пофиксить, раз и пофиксил (+ удаленно они уже сохранились), один клик и уже поделился с другими.
Чем вам не угодило вот это «ознакомление по-шустрому»?
Эх, таничики.
Сколько времени было просижено за дэнди.
Хабраэффект все же положил, не дает поиграть.
Пойду нагуглю и все таки поиграю.
Сколько времени было просижено за дэнди.
Хабраэффект все же положил, не дает поиграть.
Пойду нагуглю и все таки поиграю.
навскидку www.g0l.ru/emu/3 :-) тока JRE нуна
блин, хочется попробовать, да лежит капитально :-(
Если у вас таки дойдут руки до оптимизации поиска пересечений, стукните мне в скайп panki.ru, пара отличных решений именно для такой игры у меня есть.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Всеми руками поддерживаю.
Я не совсем разделю ваш оптимизм пожалуй. Это будет совсем другая игра. И я не уверен, что гейм дизайн тех самых танчиков успешно впишется в вариант с мультиплеером.
Хотя хотелось бы, да. Я даже пару танчиков уже успел написать, но вот про мультиплеер не думал пока.
Хотя хотелось бы, да. Я даже пару танчиков уже успел написать, но вот про мультиплеер не думал пока.
это отличная идея :)
Ну зачем вы на гуглкод выкладываете, есть же гитхаб!
Вот вам летающие «танчики» на тех же технологиях — rawkets.com
>Расчёт передвижения танков, полёта пуль, обработка столкновений и вообще всё, что относится к логике игры — происходит на сервере, так как негоже доверять такие вещи клиенту
А если (почти) все переложить это на клиентов, а на сервер отправлять контрольные точки, например на клиенте пуля долетела до танка — отправляется одно событие на сервер, а сервер только проверяет возможно ли такое событие и применяет его. Тут опять же свои сложности, синхронизация клиентов с сервером (т.к. время у всех разное), накопление событий будет происходить не только на сервере, но и на клиенте.
А если (почти) все переложить это на клиентов, а на сервер отправлять контрольные точки, например на клиенте пуля долетела до танка — отправляется одно событие на сервер, а сервер только проверяет возможно ли такое событие и применяет его. Тут опять же свои сложности, синхронизация клиентов с сервером (т.к. время у всех разное), накопление событий будет происходить не только на сервере, но и на клиенте.
Я плохо себе представляю как это синхронизировать, если каждый клиент будет себе считать игру. Но как вариант можно сделать, чтобы один игрок выступал в роли «сервера», то есть игра обсчитывается у одного игрока, а данные для других пересылаются через реальный сервер. Но к сожалению это не из тех вещей которые бы я мог быстро провернуть. Возможно когда-нибудь будет так.
Кто-то под ником aim в чате игры предложил такую идею: разбить объекты игры на две группы, 1 — неподвижные объекты, их можно хранить в двумерном массиве, что позволит быстро искать пересечения. а танки, пули, бонусы хранить в виде списка прямоугольников (ну или в виде дерева) и обрабатывать их как сейчас. Должен получить хороший выигрыш по производительности. Идея мне понравилась, найти бы время реализовать её.
На самом деле дерево — штука не особо удобная. Я бы таки сделал трехмерный массив. Точнее, двухмерный, где каждая клетка поля — объект, который хранит информацию о своем содержимом. Насколько я помню, движение возможно с шагом в пол квадрата размера танка, а кирпичи уничтожаются в блоках еще вдвое меньше. То есть, реальный размер поля — 104×104. По сути, в игре нужно 3 слоя: для танков, для снарядов (отдельный слой, потому что снаряды ботов проходят через других ботов насквозь), для объектов карты (лес, лед, вода) и бонусов. Поскольку два объекта каждого из этих типов в одном месте быть не могут. Некоторые объекты могут занимать несколько клеток, например кирпич и танк — это объекты 4×4, а снаряд — 2×2.
Тогда для сдвига объекта придется проверять коллизии 8 клеток массива в трех измерениях при движении танка, поскольку он не может двигаться меньше чем на 2 шага, и всего 2 клеток для снаряда. Если на карте 2 игрока и 6 ботов — это максимум 20 движущихся объектов (у игроков может быть 2 снаряда).
При том клиенту вовсе не обязательно отрисовывать движение так же, как на сервере. На сервере можно считать гораздо грубее. То есть мы при игровом тике сдвигаем все движущиеся объекты, при этом проверяя, что находится на пути. Для объектов разного типа можно использовать разные генераторы тиков или пропускать их.
Слать изменения надо немедленно, не дожидаясь пока спросит клиент. Иначе зачем вообще сокеты?
При этом следует слать только информацию о изменении намерений. Если это выстрел — то надо слать информацию о его начале, а в конце — результат попадания. Если движение — о начале и остановке. А уж текущее положение клиент пусть сам вычисляет, задачка простейшая.
Тогда для сдвига объекта придется проверять коллизии 8 клеток массива в трех измерениях при движении танка, поскольку он не может двигаться меньше чем на 2 шага, и всего 2 клеток для снаряда. Если на карте 2 игрока и 6 ботов — это максимум 20 движущихся объектов (у игроков может быть 2 снаряда).
При том клиенту вовсе не обязательно отрисовывать движение так же, как на сервере. На сервере можно считать гораздо грубее. То есть мы при игровом тике сдвигаем все движущиеся объекты, при этом проверяя, что находится на пути. Для объектов разного типа можно использовать разные генераторы тиков или пропускать их.
Слать изменения надо немедленно, не дожидаясь пока спросит клиент. Иначе зачем вообще сокеты?
При этом следует слать только информацию о изменении намерений. Если это выстрел — то надо слать информацию о его начале, а в конце — результат попадания. Если движение — о начале и остановке. А уж текущее положение клиент пусть сам вычисляет, задачка простейшая.
Слать изменения немедленно очень накладно, за один игровой шаг может измениться с десяток свойств, придется рассылать изменение каждого свойства по отдельности. Слать изменения пакетами должно быть быстрее. Сокеты нужны потому что: 1) — это одно постоянное подключение. 2) клиент не дергает каждый раз сервер, если есть что послать клиенту, сервер каждые несколько миллисекунд сам отправляет данные.
Пересылка только начала движения и остановки, и вычисление текущего положения самим клиентом имеет смысл как оптимизация, когда пересылка текущих координат станет узким местом. Но пока я этого делать не стану, потому что тут будут проблемы рассинхронизации в случае тормозов на сервере. Я бы не назвал алгоритм исправления таких погрешностей простейшей задачкой.
Пересылка только начала движения и остановки, и вычисление текущего положения самим клиентом имеет смысл как оптимизация, когда пересылка текущих координат станет узким местом. Но пока я этого делать не стану, потому что тут будут проблемы рассинхронизации в случае тормозов на сервере. Я бы не назвал алгоритм исправления таких погрешностей простейшей задачкой.
То, что каждый шаг шлется пакетом — понятно. Но для этого вовсе не обязательно ждать запроса клиента.
А это смотря как делать. С node.js не работал, но там должен быть механизм, позволяющий вызывать шаги с фиксированным интервалом, независимо от времени, потраченного на каждый шаг. Надеюсь, там не тупо остановка треда на N мсек? Тогда главное — чтобы задержка сети была не более ≈300-400 мсек. В таком случае особых сложностей с рассинхронизацией быть не должно. Разве что разрушаемое окружение немного добавляет проблем — его следует обрабатывать только по команде сервера.
А это смотря как делать. С node.js не работал, но там должен быть механизм, позволяющий вызывать шаги с фиксированным интервалом, независимо от времени, потраченного на каждый шаг. Надеюсь, там не тупо остановка треда на N мсек? Тогда главное — чтобы задержка сети была не более ≈300-400 мсек. В таком случае особых сложностей с рассинхронизацией быть не должно. Разве что разрушаемое окружение немного добавляет проблем — его следует обрабатывать только по команде сервера.
Виноват, в статье смешал два понятия клиента. В общем, на сервере есть объект user. Этот объект каждые 50мс проверяет, если ли что отправить браузеру и отправляет данные, если они есть. То есть клиен-браузер не дергает сервер, а объект user на сервере, как клиент лога событий, запрашивает изменения у этого самого лога.
В node, как я понял, все асинхронное, и мой код только «просит» отправить данные клиенту, и тут же продолжает выполнение. А отправка данных происходит уже позже.
Возможно как раз придется реализовывать эту идею, потому что я уперся в объем трафика.
В node, как я понял, все асинхронное, и мой код только «просит» отправить данные клиенту, и тут же продолжает выполнение. А отправка данных происходит уже позже.
Возможно как раз придется реализовывать эту идею, потому что я уперся в объем трафика.
TItemListБоже, какой ужас! Я снова вижу Делфи на своём любимом JS. Зачем вы так издеваетесь над языком? =(
Заметьте сколько энтузиазма! (((:
Эту энергию да в правильное русло.
Желаю удачи с проектом!
Эту энергию да в правильное русло.
Желаю удачи с проектом!
недавно закончил писать игру, почти тот же принцип и те же технологии, ремэйк старого Xonix. Наступал та не же грабли что и Вы. Пытался найти инфу, но чего-то вменяемого не нагуглил. Есть статья типа этой netlib.narod.ru/library/book0077/ch05_01.htm, но тут все таки больше для «общего развития», нежели разбор и оптимизация существующих реальных игр и проблем возникающих в их реализации.
Будет интересно почитать, чем закончились ваши оптимизации, постарайтесь хотя бы кратко записывать и не верные шаги тоже.
Побольше технической инфы и может даже кусков кода, для решения той или иной проблемы в статьях думаю не помешает.
Будет интересно почитать, чем закончились ваши оптимизации, постарайтесь хотя бы кратко записывать и не верные шаги тоже.
Побольше технической инфы и может даже кусков кода, для решения той или иной проблемы в статьях думаю не помешает.
Первая мысль для предоления подобного рода тормозов — заиспользовать структуру R-tree (напр. реализацию github.com/imbcmdth/RTree).
Мне кажется вы слишком сильно усложнили задачу, вполне можно было работать с двумерной картой, элементы которой являются типом ячейки поля (0-пусто, 1 — стена, 2 — вода, 3 — что-то еще). В добавок достаточно от трасировать пулю по прямой а не искать какие-то супер сложные алгоритмы столкновений. Таким образом задача будет состоять только в том, чтобы найти кратчайший путь, по которому должен будет ехать бот от спауна до твоей базы (он в конце концов будет просто закэширован, обновлять его придется только в случае разрушения приграды), и на каждом его шаге пытаться оттрасировать пулю в 4 стороны, что в худшем случае равно периметру поля… Не нужны тут ни какие 3х мерные массивы, достаточно просто определять поведения по типу препятствия и объекту, который совершает действие.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Танчики на node.js