|
|
|||||
а я и не говорю что это круто я ж сказал я так делал раньше для простоты. щас все основные параметры считает сервер а неосновные типа столкновений и прочей лабуды клиент. короче так максимум можно представить флеш сервер можно, но нежелательно.
__________________
Black DRAGON хочет кушать Т_Т |
|
|||||
Цитата:
Да и мне надо именно сервер под AS3... |
|
|||||
стервочка (я мужик)
|
а как у вас был реалізован флэшсервер?
Цитата:
|
|
|||||
Цитата:
__________________
Black DRAGON хочет кушать Т_Т |
|
|||||
стервочка (я мужик)
|
а причём тут транзит? извините но вы бред несёте
|
|
|||||
Banned
[+4 11.12.07]
[+4 18.03.08] Регистрация: Oct 2007
Сообщений: 269
|
> Отсюда назвать сервером мы можем все что угодно - галереи, форумы, проигрыватели
Сервер - это то, что садится на порт и слушает его, открывая все входящие коннекты (TCP) или хватая приходящие пакеты (UDP) > FLASH(клиент) < - > Socket Server < - > FLASH(сервер) Не бери там больше. Плохая трава. Ну и про "сокет-сервер" говорить надоело, тут уже была тема по этому поводу. > ам так называемый флешь сервер обрабатывает объекты их координаты на столкновение, интелект ботов и прочую пургу Простор для читера. Снифуем траф, а потом пишем своего клиента - вуаля. > когда ты стрельнешь а клиент скажет что противника в этой точке давно нет, и он на самом деле уже дааалеко уехал. Поэтому сначала запрос придет на сервер, и только когда сервер обработает запрос, только тогда можно рисовать анимацию выстрела. > а неосновные типа столкновений и прочей лабуды клиент коллизии - это неосновные? Идет игрок. Перед ним дом. Коллизия. У одного он будет обходить дом слева, у другова справа. Куда стрелять? > причём тут транзит? извините но вы бред несёте +1 Можно при его схеме дико извратиться (флешка посылает запросы на сервер вида "я тут", "я иду в точку", "я стреляю", а в ответ получает запросы всех остальных и в зависимости от этого рисует), но толку не будет. |
|
|||||
LinuxVideo
короче по твоим постам понятно что ты вообще нифига не понял.. поясню 2 вещи: 1)FLASH(клиент) и FLASH(сервер) - это разные вещи! и один это то что у клиента а второй в виде EXE висит на серваке. в общем ответ твой полный бред потому что я как раз этот бред делал для того чтобы как раз все вещи обрабатывал сервер а не пользователь. в основном это было положение по координатам столкновение скорость и т.д. 2) клиент только получал эти данные и получал нужную анимацию. но потом выяснилось что обрабатывать координаты нет смысла, КПД синхронизации на столько высоким получил что реальные координаты клиент обрабатывает сам. а если он будет читерить - это легко просекается. 3) я предложил идею для человека который я так понял не имеет опыта программирования серверов, и знает только AS3. вот я и дал ему идею где и что копать. Сам то я уже давно серваки не пишу на AS3 это было давно и неправда.
__________________
Black DRAGON хочет кушать Т_Т |
|
|||||
стервочка (я мужик)
|
DRAGOnoid, понимаете, тут такое дело. У вас спрашивают в 3й раз в этом топе. как вы писали сервера на АС3, и вообще как это выглядело. примерчик маленький, или что-то типа того.
дело в том, что присутсвующие сдесь, этого делать не умеют и хотят научится. |
|
|||||
[+4 27.04.08]
Регистрация: Oct 2006
Сообщений: 22
|
Может, мое решение достаточно узкоспециализированное, но оно имеет место в разработке нашего игрового портала. В частности, мультиплеерная игра в карты, причем игра может вестись за несколькими столами и даже на нескольких местах одного стола одним человеком (блекджек). Естественно, я говорю про игру, ведующуюся не в скачиваемом клиенте, а исключительно в HTTP-клиенте (зашел на игровой сайт, зарегился и играешь).
Я не пошел по пути создания соединения с сервером через сокеты, а выбрал периодические запросы к серверу (классический подход). Правда, на этом вся классика и заканчивается. Сервер у меня Apache Server - Apache Tomcat (платформа J2EE) и я использую технологию Continuations (Jetty + Comet), которая задерживает возвращение запроса клиенту и возвращает только при инициирования события (может, не до конца верно, но зато достаточно примитивное объяснение). К примеру, клиент выполнил действие, запрос ушел, обработался на сервере, вернулся (событие было), через доли секунды снова ушел на сервер, но теперь события нет и запрос не возвращается. Его может синициировать как действие самого клиента, так и любого другого игрока. Причем, при игре за разными столами может быть разграничение принадлежности столу и разноуровневые события - одни влияют только на обновления клиента игроков стола, а другие - глобальные - всех, играющих в данную игру. Хотя Jetty+Comet ориентирована под Java, но для многих других языков и платформ есть аналоги. Судя по тому, что наибольшее количество инфы по ней на IBM-ских сайтах, похоже, что они "курируют" данную технологию. Там я встречал аналоги под PHP (Perl), C++. Недостаток классического способа периодической отправки запросов в том, что надо делать паузу, иначе большое количество игроков могут повесить сервер, а пауза - это уже не полный реалтайм. Continations же позволяют выполняться запросам мгновенно, не надо инициировать паузу: ответ вернулся с сервера и тут же сформирован новый запрос, а вот сервер уже решает когда отсылать ответ (реакция на события). |
Часовой пояс GMT +4, время: 04:44. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|