а я и не говорю что это круто ;) я ж сказал я так делал раньше для простоты. щас все основные параметры считает сервер а неосновные типа столкновений и прочей лабуды клиент. короче так максимум можно представить флеш сервер ;) можно, но нежелательно.

пыталсо зайти и скачать да нет там файла... 404...
Да и мне надо именно сервер под AS3... :)

а как у вас был реалізован флэшсервер? серверов под АС3 не бывает.

сказал же только транзит через Socket Server

а причём тут транзит? извините но вы бред несёте :)

> Отсюда назвать сервером мы можем все что угодно - галереи, форумы, проигрыватели

Сервер - это то, что садится на порт и слушает его, открывая все входящие коннекты (TCP) или хватая приходящие пакеты (UDP)


> FLASH(клиент) < - > Socket Server < - > FLASH(сервер)

Не бери там больше. Плохая трава.
Ну и про "сокет-сервер" говорить надоело, тут уже была тема по этому поводу.


> ам так называемый флешь сервер обрабатывает объекты их координаты на столкновение, интелект ботов и прочую пургу

Простор для читера. Снифуем траф, а потом пишем своего клиента - вуаля.


> когда ты стрельнешь а клиент скажет что противника в этой точке давно нет, и он на самом деле уже дааалеко уехал.

Поэтому сначала запрос придет на сервер, и только когда сервер обработает запрос, только тогда можно рисовать анимацию выстрела.


> а неосновные типа столкновений и прочей лабуды клиент

коллизии - это неосновные? Идет игрок. Перед ним дом. Коллизия. У одного он будет обходить дом слева, у другова справа. Куда стрелять?


> причём тут транзит? извините но вы бред несёте

+1
Можно при его схеме дико извратиться (флешка посылает запросы на сервер вида "я тут", "я иду в точку", "я стреляю", а в ответ получает запросы всех остальных и в зависимости от этого рисует), но толку не будет.

И значит что выбрать?

LinuxVideo

короче по твоим постам понятно что ты вообще нифига не понял.. поясню 2 вещи:
1)FLASH(клиент) и FLASH(сервер) - это разные вещи! и один это то что у клиента а второй в виде EXE висит на серваке.
в общем ответ твой полный бред потому что я как раз этот бред делал для того чтобы как раз все вещи обрабатывал сервер а не пользователь.
в основном это было положение по координатам столкновение скорость и т.д.
2) клиент только получал эти данные и получал нужную анимацию.
но потом выяснилось что обрабатывать координаты нет смысла, КПД синхронизации на столько высоким получил что реальные координаты клиент обрабатывает сам. а если он будет читерить - это легко просекается.
3) я предложил идею для человека который я так понял не имеет опыта программирования серверов, и знает только AS3. вот я и дал ему идею где и что копать.
Сам то я уже давно серваки не пишу на AS3 это было давно и неправда.

DRAGOnoid, понимаете, тут такое дело. У вас спрашивают в 3й раз в этом топе. как вы писали сервера на АС3, и вообще как это выглядело. примерчик маленький, или что-то типа того.

дело в том, что присутсвующие сдесь, этого делать не умеют и хотят научится.

Может, мое решение достаточно узкоспециализированное, но оно имеет место в разработке нашего игрового портала. В частности, мультиплеерная игра в карты, причем игра может вестись за несколькими столами и даже на нескольких местах одного стола одним человеком (блекджек). Естественно, я говорю про игру, ведующуюся не в скачиваемом клиенте, а исключительно в HTTP-клиенте (зашел на игровой сайт, зарегился и играешь).

Я не пошел по пути создания соединения с сервером через сокеты, а выбрал периодические запросы к серверу (классический подход). Правда, на этом вся классика и заканчивается. Сервер у меня Apache Server - Apache Tomcat (платформа J2EE) и я использую технологию Continuations (Jetty + Comet), которая задерживает возвращение запроса клиенту и возвращает только при инициирования события (может, не до конца верно, но зато достаточно примитивное объяснение). К примеру, клиент выполнил действие, запрос ушел, обработался на сервере, вернулся (событие было), через доли секунды снова ушел на сервер, но теперь события нет и запрос не возвращается. Его может синициировать как действие самого клиента, так и любого другого игрока. Причем, при игре за разными столами может быть разграничение принадлежности столу и разноуровневые события - одни влияют только на обновления клиента игроков стола, а другие - глобальные - всех, играющих в данную игру.

Хотя Jetty+Comet ориентирована под Java, но для многих других языков и платформ есть аналоги. Судя по тому, что наибольшее количество инфы по ней на IBM-ских сайтах, похоже, что они "курируют" данную технологию. Там я встречал аналоги под PHP (Perl), C++.

Недостаток классического способа периодической отправки запросов в том, что надо делать паузу, иначе большое количество игроков могут повесить сервер, а пауза - это уже не полный реалтайм. Continations же позволяют выполняться запросам мгновенно, не надо инициировать паузу: ответ вернулся с сервера и тут же сформирован новый запрос, а вот сервер уже решает когда отсылать ответ (реакция на события).