Как создавалась одна социальная игра

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


ТЗ или какой-то детальной проработки небыло, передали на тексте видение проекта и несколько скетчей. Изометрия, парк, аттракционы, дорожки, декоративные объекты, посетители и персонал. Аттракционы раз в энное количество времени приносят баблосы, иногда ломаются.
Графику рисовал дизайнер, объекты и анимацию создавал в трехмерке, сервером должен был заниматься серверник.

Клиент

Разработку начал с поиска подходящего движка. Подходящего движка небыло, разработал свой.
Для исключения возни с преобразованием координат в изометрии ввел «сенсорную карту» — матрицу из прозрачных (alpha = 0) квадратиков нужного размера, повернутую на 45 градусов и сплюснутую по вертикали. Т.к. после поворота часть тайлов оказывалась вне карты, делал проверку и убирал ненужные.
Каждый сенсорный тайл содержал ряд важной информации: свободен\занят, свои координаты в матрице, ссылку на установленный на нем объект.
Местоположение курсора определял просто:
pt = new Point(stage.mouseX, stage.mouseY);			
var objects:Array = getObjectsUnderPoint(pt); 

Дальше перебирал массив objects, находил сенсорный тайл и работал уже с ним.
Данный метод использовал еще в двух проектах, он себя вполне хорошо зарекомендовал.

При работе над движком были следующие геморрои:
  • Постройка и уничтожение дорог. Дороги должны автоматически формировать перекрестки и стыки, а при уничтожении адекватно разводиться.
    Жалею, что до передачи проекта не успел сделать постройку дорог по протяженности(из точки А в точку Б), а не по тайлам. Каждый день были новые задачи и твики.
  • Отрисовка узких объектов по z. Движок хорошо отрисовывал и обновлял квадратные и приближенные к ним объекты, но при использовании длинных и узких объектов начинались трудности – более низкие объекты начинали перекрывать их.

Первый месяц ушел на разработку полноценного standalone клиента, еще два – на отладку взаимодействия с сервером и дальнейшее развитие клиента (у заказчика начались трудности с финансированием, и работа не велась уже fulltime).

Сервер


Сервер: PHP+mySQL
Сервер проект менеджер вынес на виртуальный хостинг spaceweb.ru
Все бы хорошо, но появились следующие проблемы:
  1. Надежность таких серверов – ни разу не три девятки. Время от времени пинги на сервер не проходили.
  2. Из-за того, что проектированием базы изначально никто не занимался, при полтора тысячах юзеров база мгновенно разраслась до 60 мб с тенденцией лавинообразного роста, и работать с ней стало уже несколько проблематично. При этом был еще один факап, когда при каком-то эскуэльном запросе база закрылась и не отвечала, и пришлось возиться с такой вот немаленькой базой.
Дальше уже провели человеческую оптимизацию, и стало значильно лучше, но все равно с серверами надо решать по-другому.

Схема сетевого взаимодействия выглядела так:
  1. Обращение к флэшварс, грузим переданные контактом данные
  2. Если приложение установлено, френды расшарены – первый запрос к серверу, грузим стартовую xml. Загружаем все объекты, параметры и т.п.
  3. По запросу раз в установленное время клиент обращался на сервер за обновлением данных. Можно было использовать стартовую xml, но она в размерах весьма здоровая была, часто грузить – нагружать сервер, использовали лайт вариант.

Сервернику изначально дал задание сделать следующую систему:
При обращении проверяем дату последнего обновления. Если пришла пора обновиться – для всех объектов, для кого это необходимо, рассчитывается текущее состояние, и сохраняется в базе.
Серверник сделал по-другому: расчет велся «на лету», по обращению, и передавался результат.
В результате месяц ковырялись с этой системой, она давала сбои и расчитывала данные весьма коряво, причем отладить было весьма непросто. Несколько раз при обновлении клиента в рабочей группе уже приходилось мне залезать в ПХП код и разбираться, что там и как, и почему деньги не копятся, либо копятся, но не те.

Потом сделали так, как это задумывалось изначально, и к серверу вопросов стало намного меньше.
Для шифрования использовали md5 с запрятанным ключом.
Примерный формат передаваемых данных:
адрес_сервера.ru\?айдишник=айди&действие=текущее_действие&объект=айди_объекта&…

Для идентификации в базе айдишники использовались контактовские.

Организация


Изначально проект вели в Мантисе, но он оказался достаточно глюкавым, потому перешли на формат Google Docs. Проект-менеджер расшарил участникам ряд файлов – параметры, баглист&todo лист для клиента и для сервера. В гуглодоках еще можно чатиться прямо во время правок документов. Оказалось весьма удобно. Один нюанс – иногда кто-нибудь брал и удалял посты других товарищей. Находишь баг по серверу, помнишь что он уже был – смотришь файлик с багами по серверу, а там твоей заметки уже и нет. После такого все свои посты стал дублировать в оффлайновый файлик.
После успешной модерации клиент выложили в рабочую группу, и откуда-то появился трафик. Появился случайно, но количество пользователей постоянно расло. Скорее всего, приходили по запросу «стратегия» или «экономическая стратегия» — таких приложений на тот момент было всего четыре, но точно не скажу.
Под тестинг завели отдельную базу, отдельный фреймворк и создали тестовую группу с тестовым же приложением. В клиенте я поставил переключение на тестовый режим посредством флага. Когда все новые правки проходили контроль качества, обновляли клиент в рабочей группе и заливали новый фреймворк в рабочую базу.

Монетизация


Проект менеджер разработал следующую систему монетизации: все апгрейды, все персонажи, дополнительные земли (достигаются постройкой моста) за монеты, покупаемые за голоса. Имхо, слишком жестко, и людям стоило бы дать возможность фармить и монетки, но… что-ж, хозяин-барин.
Одно скажу: люди реально платят деньги!

Резюме

Лично я получил хороший опыт.
Сейчас я заканчиваю свой инди-проект, и если будет время, до конца лета выпущу собственное «социальное» приложение под контакт.
  • +9

Комментарии (18)

0
Спасибо, интересная и местами весьма поучительная информация. Всё-таки как же все по разному организуют процесс.
Имхо, проект рановато зарелизили, надо было ещё немного допилить, хотя-бы минимальный тьютор сделать на старте (для этого жанра это критично, особенно учитывая то как с этим делом обстоит у конкурентов от крупных компаний в том же ВК) и сделать нормальный современный интерфейс добавления приложения/приглашения друзей + продумать получше социальность и всякие вирусные фишки. хотя это конечно всё вопросы к менеджеру. судя по описанию, самым слабым звеном в команде был именно он, ну и тот кто писал сервер тоже молодец конечно)
0
Выложили рано, ага.
Сервер был еще крайне сырой, в клиенте баги были, некоторые основные элементы не подключены. В результате с неделю висел сплэш-баннер «Скоро открытие», и потом еще недели три доводили до уровня клиент и сервер. Так же из-за спешки некоторые элементы делались схематично — вроде интерфейса перехода в парк к френдам. Но похоже что нужен был какой-то видимый результат работы, потому выпускали так.

Кстати, добавление приложения и френдов через контейнер был реализован, но потом от него отказались: там надо было повозиться с установкой прелоадера (иначе использовался стандартный контактовский), и по коду некоторые правки, а бюджет уже заканчивался. Потому менеджер принял решение откатиться на предыдущую версию и допиливать оставшиеся пункты фичелиста.
0
ага, ясно.
насчет состояния на момент релиза, по своему опыту (тоже делал соц.игру на заказ), да и не только, убедился, что самый главный импульс для будущего роста игры происходит именно в первую пару недель (хотя наверное сейчас уже речь идет о днях). И главное, что уже должно быть — простота понимания (те кто играет в соц. игры думать не хотят совсем) и вирусные фичи — то, что стимулирует игроков приглашать друзей и возвращаться в игру. Из остального много что можно допиливать уже потом — уровни, технические фичи, интерфейс, ассортимент товаров и даже монетизацию (при условии что она продумана заранее конечно).
0
По поводу приглашения игроков и вирусных фишек — вообще отдельная песня. Кстати, через некоторое время после релиза правилами контакта был установлен запрет на поощрение игроков за приглашение.

Механизм оставили, а информацию об этом скрыли :)
0
хотя конечно нужно добавить, что очень многое зависит и от того как игра будет поддерживаться и развиваться потом. в этом наверное одно из главных отличий социалок от казуалок — очень важна последующая поддержка. в моём случае владельцы очень быстро забросили и перестали развивать игру, отвечать на пожелания юзеров по той же причине — не хотели дальше финансировать её. и отдача после этого резко пошла на убыль.
+1
Плюсанул, за инфу и за фразу «Сейчас в игре появилось много программных ошибок, за которые я уже не отвечаю», суть этого я понял зайдя в приложение:)
Я думаю опыт получил колоссальный, как работы с ВК API так и с серверными программистами.
0
Очень интересно, помнится я раньше писал на PHP+MySQL, даже пытались сделать браузерку, вот только тогда я очень не любил флеш(от тормозов в частности) и когда к нам присоединился флеш программер, который начал все делать под себя, в общем он переделал тайловую карту во флеш, до этого я ее сделал на JS+AJAX, над которой долго ломал голову, причем использовал хранение карты, не в мускуле, а в тексте, чтоб снять нагрузку на базу(в будущем). Короче что-то мы там не поделили, я отошел от дел(на мне был серв) и новый программер пропал, а так как все было на энтузиазме…
Сейчас я уже сам учу флеш и жалею что раньше не начал учить)
Наверное в будущем, попробую связать флеш с пхп и сделать что ни будь похожее.
Вот вопрос, на сколько прибыльно делать такие онлайн игры в том же контакте?
Будет интересно узнать на сколько рентабельно.
0
Как правило еще стартовые затраты нужны хорошие: на разработку, на рекламу, на поддержку. Фактически, до старта необходимо оплачивать работу трех-четырех специалистов в течение нескольких месяцев
Рисков уйма — от социальных и до технологических.

Кто все эти трудности пройдет, получит шанс отбить свои вложения. Подчеркиваю: шанс.
Но люди платят. Просмотром, голосами. И чем больше людей, тем больше прибыль.
0
Платят :) прибыль прямо-пропорциональна количеству активных юзеров.
Причем пока установок всего около 7к это очь мало с 100к откроется более интересная картина:) если осталась возможность следить за приложением то последите будете обалдевать.
0
к сожалению, давно от статистики отрубили :)
0
Спасибо за статью! Про процесс разработки всегда интересно почитать, в если еще и про социалку, то тем более.

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