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

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

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

Клиент

Разработку начал с поиска подходящего движка. Подходящего движка небыло, разработал свой.
Для исключения возни с преобразованием координат в изометрии ввел «сенсорную карту» — матрицу из прозрачных (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 лист для клиента и для сервера. В гуглодоках еще можно чатиться прямо во время правок документов. Оказалось весьма удобно. Один нюанс – иногда кто-нибудь брал и удалял посты других товарищей. Находишь баг по серверу, помнишь что он уже был – смотришь файлик с багами по серверу, а там твоей заметки уже и нет. После такого все свои посты стал дублировать в оффлайновый файлик.
После успешной модерации клиент выложили в рабочую группу, и откуда-то появился трафик. Появился случайно, но количество пользователей постоянно расло. Скорее всего, приходили по запросу «стратегия» или «экономическая стратегия» — таких приложений на тот момент было всего четыре, но точно не скажу.
Под тестинг завели отдельную базу, отдельный фреймворк и создали тестовую группу с тестовым же приложением. В клиенте я поставил переключение на тестовый режим посредством флага. Когда все новые правки проходили контроль качества, обновляли клиент в рабочей группе и заливали новый фреймворк в рабочую базу.

Монетизация

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

Резюме

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