Теоретические основы по алгоритму реализации пошагового боя
|
|
aaa_kkk_82 | Дата: Четверг, 29 Августа 2013, 07:25 | Сообщение # 1 |
был не раз
Сейчас нет на сайте
| Здравствуйте! Такая ситуация: Начался бой, в котором игроки по очереди делают ход. На ход игрока выделяется время t. Как правильно реализовывать такие бои? Нужна теория. Как отслеживать, сделал ли игрок ход или нет?
Первое что пришло в голову - это создавать запись в БД. Затем игрок, который ожидает ход противника, каждые 3 секунды делает запрос к записи в БД с целью узнать, сделан был ход или нет. Теоретически такое будет работать. Но допустим проводится одновременно сотня боев. А это означает как минимум 100 запросов в секунду. Думаю тут будут большие проблемы.
Как делать правильно?
P.S. Программирую в PHP, JS
|
|
| |
Vinchensoo | Дата: Четверг, 29 Августа 2013, 07:34 | Сообщение # 2 |
Злобный социопат с комплексом Бога
Сейчас нет на сайте
| Использовать сокеты и не мучать попу
|
|
| |
aaa_kkk_82 | Дата: Четверг, 29 Августа 2013, 07:49 | Сообщение # 3 |
был не раз
Сейчас нет на сайте
| Сокеты в маленьких web проектах - это не выход!
|
|
| |
AGENTX001 | Дата: Четверг, 29 Августа 2013, 10:58 | Сообщение # 4 |
почётный гцупер
Сейчас нет на сайте
| http://gcup.ru/forum/51-30024-493622-16-1360000602 Немного теории для начала. Знаешь js? Node тебе в руки и пиши нормальный сервер, хоть асинхронные запросы, хоть сокеты.
|
|
| |
Vinchensoo | Дата: Четверг, 29 Августа 2013, 12:35 | Сообщение # 5 |
Злобный социопат с комплексом Бога
Сейчас нет на сайте
| Проблемы 2: 1. Синхронизация. Рассчет времени опроса(3 сек) производится на клиенте, а время передачи данных от клиента к серверу- не постоянное, может прыгать и сильно. Отсюда ситуация "игрок А сходил в последний момент, а игроку Б уже сказали, что он победил". 2. Постоянная нагрузка на сервер, ибо 100 запросов в секунду при 300 онлайне в среднем идут впустую. Я не так давно где-то встречал реализацию расширения http протокола, чтобы можно было кидаться данными с сервера на клиент, но не помню, где видел и найти снова не могу.
Самым правильным решением являются сокеты, можно, конечно, попробовать ajax или еще чего, но это все равно лишняя пустая работа. Используйте веб-сокеты, благо уже доступны в js.
Сам занимаюсь чем-то подобным с технической точки зрения, пока ничего лучше сокетов не придумал. Придумаете- пишите)
Цитата (AGENTX001) Немного теории для начала. Знаешь js? Node тебе в руки и пиши нормальный сервер, хоть асинхронные запросы, хоть сокеты. Человек хочет пхп, очень разумно пихать в него nodeJS.
|
|
| |
AGENTX001 | Дата: Четверг, 29 Августа 2013, 18:16 | Сообщение # 6 |
почётный гцупер
Сейчас нет на сайте
| // Человек хочет пхп, очень разумно пихать в него nodeJS. // P.S. Программирую в PHP, JS Он не говорил, что хочет php. А сокеты, да и вообще скрипты исполняемые сколь-нибудь долгое время в php сущий ад.
|
|
| |
Vinchensoo | Дата: Четверг, 29 Августа 2013, 18:20 | Сообщение # 7 |
Злобный социопат с комплексом Бога
Сейчас нет на сайте
| AGENTX001, он и не хочет сокеты. Придумай алгоритм по http. Судя по формулировке вроде очевидно, что речь идет о php + js(client side)
|
|
| |
AGENTX001 | Дата: Пятница, 30 Августа 2013, 09:31 | Сообщение # 8 |
почётный гцупер
Сейчас нет на сайте
| Цитата (aaa_kkk_82) А это означает как минимум 100 запросов в секунду. Думаю тут будут большие проблемы. Нет, 100 запросов в секунду не критично.
Vinchensoo, ну тогда зачем извращаться... AJAX и постоянный сейв в БД.
|
|
| |
Vinchensoo | Дата: Пятница, 30 Августа 2013, 12:27 | Сообщение # 9 |
Злобный социопат с комплексом Бога
Сейчас нет на сайте
| Цитата (AGENTX001) Нет, 100 запросов в секунду не критично. 100 запросов с одних боев. Это уже ппц. Надо использовать нормальные технологии, а не лепить костыли. Потом еще чат добавится и еще какие-нить действия, и будут все 300.
Ajax как вариант, но все равно, проблему номер раз не решает.
|
|
| |