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

[VovkaMorkovka]

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

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

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

[BlooDHounD]

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

[wvxvw]

ППКС.

[VovkaMorkovka]

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

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

[BlooDHounD]

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

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

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

[Freeeeeeeman]

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

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

[etc]

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

[VovkaMorkovka]

1. вопрос неясен


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


4. вы собираетесь и действия интерпретировать и выполнять их потом на клиенте? это шутка? зачем?


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


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

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

[wvxvw]

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

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

[VovkaMorkovka]

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

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

[Freeeeeeeman]

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

[VovkaMorkovka]

В том - то и дело, что нельзя давать игроку лазейку, поменять чего нибудь. Кто мешает взломать флешку и поменять вражеский скрипт на другой? А изменение в скрипт вносит сам скрипт, в этом - т ои прелесть пролога

[BlooDHounD]

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

[VovkaMorkovka]

3. срипт должен обрабатываться на серевере. на клиенте максимум подсветить синтаксис.

А можно немного подробнее аргументировать? Тут дело вот в чем: вы - же управляете персонажем в многопользовательской игрушке при помощи клавиш. А я хотел - бы управлять с помощью скрипта. Почему Вы пришли к выводу, что интерпретация скрипта на клиенте нежелательна? Дело в том, что я с такими вещами еще не сталкивался, могу чего - нибудь не видеть, это с одной стороны. А с другой, не факт, что параллельные действия зло всегда.

[BlooDHounD]

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

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