Какой физический движок выбрать?
 

Привет всем!
Я начал задумываться над созданием многопользовательской игрушки "битва роботов" Идея банальна: передавать на сервер только итоговые положения робота игрока, а расчетом физики заниматься на клиенте.
Кроме того, возможно будет реализован простой язык для управления роботом. Т.е. игрок не будет управлять роботом на прямую, а будет писать для него прогу. Т.е. аналог известной игры "Колобот".
Исходя из этого возникает вопрос: какой физический движок лучше избрать для этого?

Критерии отбора в порядке убывания сложности:
1) скорость работы
2) Расширяемость
3) Максимальное разделение логики и интерфейса(поменяли мувиклипы - получили другую игрушку)
4) Потянет - ли виртуальная машина AS 3.0 выполнение простого интерпретируемого языка, если да, то какой тип синтаксиса лучше для этого выбрать? Лично меня больше привлекает ПроЛог, но может кто - нибудь подскажет более приемлемый вариант

p.s. Гуглом пользоваться умею, но речь идет не о том какие движки и ЯП есть в природе, а о их сравнительной характеристике.

игра не будт иметь право на жизнь, если рассчётами занимается клиент.

ППКС.

А если так: Клиент занимается только интерпретацией программы, которая говорит какое в данный момент угловое и линейное ускорение, а текущее положение и скорости угловая и линейная передаются с сервера и клиент никак не может их поменять?
Т.е. что б не изменил пользователь на клиенте, где он находится и куда стреляет всеравно останется на серваке. Можно хоть победу на клиенте себе нарисовать, но для всех остальных чел проиграет.
Короче идея в том, чтобы вместо человека роботом управляла программа, а остальным занимается сервер как и в других онлайн играх

а сколько я понимаю вы собираетесь физику рассчитывать, так вот вы на столкновениях обретёте такие погрешности, что продолжать играть просто не будет иметь смысла :)

1. вопрос неясен
2. зависит от направления расширения
3. я пока что ниодного движка не видел где была бы разделена логика на 100%. вечно помесь какая-то.
4. вы собираетесь и действия интерпретировать и выполнять их потом на клиенте? это шутка? зачем?

по поваду всего поста в целом. зачем вам выбирать готовый движок, если вы везде хвастаетесь, что у вас математический профиль. напишите свой, который будет соответсвовать всем вашим требованиям. не забудте что на сервере вам его придётся повторить. причём там картинки не будет :) только чёрная консоль дебага ...

Лично я для своей игры, она у меня не многопользовательская, выбрал движок Box 2d, портированый на флэш, всё довольно просто, к тому-же легко расширяется, правда насчет производительности она довольно требовательна.
зы: Колобот РУЛЕZZzz...!

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

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

Имеется ввиду, что движок должен как можно менее загружать процессор при некотором минимальном уровне "реалистичности".

Смысл такой: есть простой интерпретируемый язык, например нечто похожее на Пролог. Игрок вместо того, чтобы управлять своим роботом напрямую пишет для него программу которая выполняется на клиенте и на каждый тик передает результаты своей работы серверу, а именно это угловое и линейные ускорения + команды о выстреле.

Зачем - же мне создавать свой движок если можно взять что - нибудь готовое? Я ж этим буду(если буду) заниматься в свободное от работы время, один. И мне хотелось - бы чтобы моя игра заработала в этом тысячелетии:) Тут с реализацией интерпретатора пролога на AS 3.0 замахаешся, а если еще движок свой писать... Я понимаю, что господам - создателям многопользовательских игр некоторые мои утверждения могут показаться абсурдными, но ведь на то и форум чтоб опытом обмениваться, разве не так? В любом случае я рад любой конструктивной критике.
Резюмируя могу сказать, что да, наверное действительно физику нужно считать на сервере. Но в таком случае какова сама идея игры подобной колоботу только многопользовательской и с интерпретатором на клиенте, а не на сервере?

Ну, тут сразу возникает несколько вопросов.
- насколько автономно будут действовать персонажи? Т.е. участие игрока потребуется раз в минуту/час/день/неотрывно?
- если неотрывно, то флеш - неудачно выбранная технология (тяжело будет реализовать постоянное устойчивое соединение с сервером). Луче уж взять движек анриала =)
- если раз в день - то не интересно (Сфера)...
- что из себя будет представлять игровой мир, сколько полигонов/объектов нужно будет одновременно обрабатывать на клиенте?

Рассчеты в любом случае на сервере. Все, что игрок может сделать на клиенте - составить запрос. Не уверен, что для этого вообще нужно делать аналог Пролога на АС. Достаточно просто отсылать текст/ХМЛ и уметь интерпретировать полученные результаты.

Ну смысл, думаю, такой: Два режима: игра онлайн и с ботами(ну как в коунтерстрайке или в квейке) Раунд составляет до десяти минут. Т.е. пишешь программу, тестируешь ее при игре с ботами а уж потом соревнуешся с другими игроками. Весь смысл в сильном соревновательном моменте. Т.е. кто напишет прогу, которая лучше всех управляет ботом. Т.е. ты в раунд вошел и сидишь - смотришь на то, как воюет твой бот. Можешь увидеть недостатки своей программы. Игровой мир пока плоский состоит из поверхности с однородной плотностью и непроходимых участков в виде простых геометрических фигур. У управляющей программы есть следующие возможности: радар, который определяет угол нахождения бота/препятствия, его тип и расстояние до препятствия, увеличение/уменьшение углового и линейного ускорения, выстрел в направлении движения(т.е. куда смотрит "нос", туда и стреляем) Кроме того есть возможность записать в базу и удалить из нее предикат, кто знает пролог поймет о чем я, таким образом можно менять алгоритм в ходе выполнения программы.

Сначала, я думаю, все имеет смысл сделать оффлайн, а уже потом мультипользоватлеьскую версию