Конструктор браузерных онлайн-игр (5 стр)

Из обсуждения не стало ясно, конструктор будет ориентирован на визуальное создание "игры" или нужно будет писать код?

Визуальное. Писать код нужно будет только в тех случаях, когда без этого никак не обойтись, например в редакторе квестов. "При съедании предмета A вызвать босса B, при победе над ним персонажи 4 уровня получают дроп C, персонажи 5 уровня дроп D, персонажи 6 уровня и выше получают дроп E, вход в инстанс блокируется на F часов, показывается информационный диалог G и т.д.". Если всё это настраивать кнопочками и галочками, пользователь устанет быстрее, чем разберётся с языком описания квестов.

На какой геймплей ориентирован конструктор? Кем в игре руководит игрок, будет ли это один персонаж или несколько? Будет ли перемещение по локациям? Какие системы боев можно использовать? Какие социальные элементы можно использовать?

и когда релиз?

> На какой геймплей ориентирован конструктор?
Изначально - ролевые игры. Базовые действия для персонажа - перемещение по локациям, добыча ресурсов, крафт, бои. Мы сделаем некий начальный набор доступных настроек. Дальше - по запросу. К примеру, хотите вы ввести новую возможность: "задержка при перемещении персонажа в следующую локацию", либо "потеря выносливости при перемещении в следущую локацию". Вы создаёте заявку на доработку и мы её выполняем. Наиболее "заплюсованные" и наиболее простые в реализации заявки мы будем выполнять в первую очередь. Если какая-то сложная фича нужна только одной не сильно успешной игре, приоритет у неё будет низкий. Фичи конструктора не фиксированы, мы будем постоянно их наращивать.

> Кем в игре руководит игрок, будет ли это один персонаж или несколько?
Мы заложим возможность управления несколькими персонажами, но на будущее. Изначально - одним. Если много администраторов игр будут просить сделать управление несколькими персонажами, сделаем.

> Будет ли перемещение по локациям?
Да, причём в самой первой версии

> Какие системы боев можно использовать?
Будет конструктор системы боёв. В нём вы сможете выбрать правила очерёдности хода, набор допустимых ходов, правила обработки ударов. Будут выбираться параметры персонажа, влияющие на урон, на защиту, на другие параметры удара. Будут поддерживаться разные виды урона в соответствии с классикой RPG. Это одна из самых сложных в конфигурировании вещей.

> Какие социальные элементы можно использовать?
Поясните вопрос

aml
Когда пощупать можно будет?

Как-то немного информации собственно по технической части, а ведь это главное.

Мне интересна эта тема, и хотелось бы узнать поподробнее насчет клиент-серверного взаимодействия. Обычно в этом как раз и состоят ноу-хау онлайн игр - грамотно организовать взаимодействие игроков с сервером. Если движок предусматривает только пошаговую игру, то все понятно. Если подразумевается реалтайм, то надо подробнее описать, будет ли компенсация лага и movement prediction, на какой максимальной задержке можно будет играть? Что будет просчитываться на клиенте, что на сервере?

Но, судя по ответам aml на простые вопросы по клиентской части, он весьма далек от разработки игр. Хорошо если у него есть хорошая команда программистов, но слабо верится. Кстати, вопрос "что готово сейчас?" остался без ответа...

aml
> К примеру, хотите вы ввести новую возможность: "задержка при перемещении
> персонажа в следующую локацию"
Если для каждой такой хрени нужно ждать изменений в конструкторе, то нафиг он нужен?
В том что вы делаете, похоже, можно менять только цифры, в остальном все фиксированно=) Для школьников младших классов этого хватит) Но кто в это играть будет? Дошкольники?))

Вот такой к вам вопрос: вы хоть одну браузерную ММО сделали? До конца, чтоб деньги приносила.

Mr_Jack
>Расширяемость платформы

>В архитектуру MMO Constructor заложена возможность расширения любого из компонентов системы. Если вы обладаете возможностями реализовать сторонние
>расширения для Конструктора, мы будем рады сотрудничеству. Если вы можете разработать iPad-приложение для взаимодействия с вашей игрой, Jabber-бота,
>редактор локаций в виде десктопного 3D-приложения, онлайн-ресурс для анализа статистики по играм или любые другие возможности, мы можем обеспечить >поддержку ваших решений со стороны Конструктора на взаимовыгодных условиях. В случае создания приложений, полезных не только вам, но и другим
>пользователям, мы готовы настраивать отдельный биллинг для ваших приложений и зарабатывать вместе с вами. Всё обсуждаемо.
>Пишите на .

aml
Ну не знаю. Это психологически неприятно для автора - не иметь ПОЛНОГО права распоряжаться своей игрой. Можно установить срок ликвидации проекта. Например, автор может подать заявление о выводе игры. После этого заявления, допустим, пару месяцев, весь доход с игры будет идти вам. По истечении срока вы закрываете игру и даёте информацию игрокам о том, куда переехал сайт. Если автор хочет ликвидировать игру немедленно, пусть платит "компенсацию" в два среднемесячных дохода игры.

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

К тому же, пункт "Не навреди" породит МАССУ конфликтных ситуаций. Ведь не существует способа объективно оценить качество геймплея. Допустим, у меня есть популярная игра. Но мне она не нравится из-за своей казуальности, я решил сделать её чуток глубже, хардкорнее. Как результат - некоторое снижение числа игроков. И меня за это отстранят от управления игрой?

aml, пара вопросов:
1. на чем будет написан сервер игры? (c, java, php)
2. на чем будет написан клиент игры? (js, flash\flex, чудо-юдо)
3. возможно ли самому изменять\добавлять сложный функционал к игре? т.е. не квесты скриптами оборачивать, а например создать свою систему боя или добавить возможность "грабить корованы"?

TurboMaX
Mr_Jack
Сроки выхода мы заранее анонсировать не будем, чтобы потом не краснеть из-за задержек. Тем более, что понятие выхода весьма расплывчатое. Когда мы откроем регистрацию для всех, сначала будет только базовый функционал. Кто-то подождёт ещё год до того, как число возможностей будет гораздо больше, кто-то начнёт сразу пользоваться конструктором. Разумеется, самые часто используемые игровые решения будут реализовываться самыми первыми.

h-bar
Slam
О технических подробностях мы расскажем на одной из конференций по построению высоконагруженных систем, когда собственно выдержим оные нагрузки.

Slam
Сложный функционал к игре будет делаться только нашими программистами по запросам пользователей.

гидрализг
> Ну не знаю. Это психологически неприятно для автора - не иметь ПОЛНОГО права распоряжаться своей игрой. Можно установить срок ликвидации проекта. Например, автор может подать заявление о выводе игры. После этого заявления, допустим, пару месяцев, весь доход с игры будет идти вам. По истечении срока вы закрываете игру и даёте информацию игрокам о том, куда переехал сайт. Если автор хочет ликвидировать игру немедленно, пусть платит "компенсацию" в два среднемесячных дохода игры.
Нет, нас это не устраивает. У автора останется право забрать все свои картинки и тексты и запретить нам пользоваться ими. Если же при этом мы сочтём игру перспективной, то перерисуем и перепишем весь авторский контент и продолжим работу игры уже без этого администратора. Базу пользователей мы не дадим никуда переманивать - это точно.

> К тому же, пункт "Не навреди" породит МАССУ конфликтных ситуаций. Ведь не существует способа объективно оценить качество геймплея. Допустим, у меня есть популярная игра. Но мне она не нравится из-за своей казуальности, я решил сделать её чуток глубже, хардкорнее. Как результат - некоторое снижение числа игроков. И меня за это отстранят от управления игрой?
В сомнительных ситуациях всегда можно пообщаться с администратором игры и уточнить, что и зачем он делает. Дать совет, в конце концов. Все эти пункты правил - это для исключительных ситуаций, когда администратор, к примеру, в 10 раз снижает или повышает все цены, рушит экономику, доход игры с треском падает, либо вдруг ни с того, ни с сего начинает хамить всем пользователям, разгонять их и т.д. Мы тогда попросим объяснений, и если их не последует, а игра перспективная, тогда мы воспользуемся своим правом сменить администратора. Хочу повторить, это исключительные ситуации.

aml
> h-bar
> Slam
> О технических подробностях мы расскажем на одной из конференций по построению
> высоконагруженных систем, когда собственно выдержим оные нагрузки.

Эээ.... про "технические подробности" пока никто не спрашивал. То, о чем спрашивали я и Slam - базовая информация, без которой не будет даже разговора о сотрудничестве. Видимо, вопрос о том, что готово сейчас отпадает сам собой. Ясно, что не готово ничего и нет даже плана разработки, раз не можете даже ответить, на чем будет написан сервер и клиент.

Серверная часть развёрнута на облаке scalaxy: кластер бэкендов на stackless + кластер cassandra. Клиентская - javascript + extjs. Полностью реализована вся системная инфраструктура и начата разработка прикладных модулей - на данном этапе они разрабатываются очень быстро. Первыми выпущенными модулями стали компоненты социальной части игр - регистрация, аутентификация, форум, новости. Реализована система натягивания дизайна на титульную страницу игры, игровой интерфейс и интерфейс социальной части. Следующие модули - вход в игру, и формирования игрового интерфейса. Потом система асинхронной доставки потоков данных в клиентский интерфейс. Затем чат с поддержкой каналов и групп. Потом простой модуль локаций (без конструктора). На этом моменте можно будет выпустить аукцион заявок и пригласить первых тестеров не из числа сотрудников.  Дальше уже работать по заявкам. Сразу после открытия регистрации сделать играбельную версию игры ещё будет невозможно, однако начать работу над игрой уже можно будет. Продумывать мир, создавать локации и постепенно подключать очередные модули.