Growing Crystals vol 3. проектирование веб-клиента, сервера и структуры данных
Следите за разработкой браузерной игры Growing Crystals, подключайтесь к обсуждению.
Вся история разработки тут! Очень нужны толковые советы и идеи от игроков со стажем, программистов JavaScript и PHP!
Сегодня третий день разработки игры Growing Crystals. После относительно успешной первой попытки разработки графики приступаем решению комплекса задач: клиенту, структуре данных, проектированию клиент-серверной связи. И прежде чем продолжить, подниму сугубо теоретическую тему “Методология ведения проекта для индиразработчика”.
Возник вопрос, а по какой методологии ведут проект инди-разработчики? И вообще существует ли какая-нибудь методология для индиразработчиков? Или главный принцип индиразработки — “дейлай!”?
Ведь можно применить и Agile и вспомнить полезные советы Getting Real, но что лучше подходит в данном случае?
Я пришел к тому, что в данном проекте невозможно применить одну из нескольких методик, так как большинство из них требуют наличия команды и хотя бы базового разграничения ролей. В реальности, сейчас мной используются только “Игра в планирование”, “Стандарты кодирования” из XP, оценка меры продвижения к большой цели и затраты ресурсов и скорость из Scrum, и, обязательно будут частые небольшие релизы спустя неделю после начала работ. Сейчас главным путеводителем являются индикаторы готовности проекта, которые я привожу каждый день, исходя из них и набросков приведенных в первом дне строю план работы. В процессе разработки, и, надеюсь, увеличению численности команды, методолгия будет дополнена и изменена. Буду признателен за советы в комментариях.
Проектирование веб-клиента
Начнём с выбора технологии реализации веб-клиента. Поскольку мы хотим добиться максимального охвата аудитории, веб-клиент должен быть написан на JavaScript строго без использования Flash. Игра жанра стратегия, следовательно необходимости в суперкрасочных 3D эффектах реализуемых с помощью WebGL или Canvas нет.
Хотя я и не исключаю возможность перехода проекта на технологию HTML5+Canvas в последствии. Пока будем держать во внимании преимущества и недостатки технологии.
Преимущества Canvas
- Позволит реализовать красочные игровые эффекты (Имеет аппаратное ускорение и позволяет манипулировать каждым пикселом);
- Возможно найти библиотеку или фреймворк, которая сократит время разработки.
Недостатки Canvas
- Нагружает процессор и оперативную память и нет уверенности в надёжной работе на мобильных устройствах;
- Необходимо самому обрабатывать события с объектами, что существенно может затянуть выпуск первой версии игры;
- Плохая производительность при большом разрешении.
Итого: Построение и отображение интерфейса пользователя реализуем классическими средствами HTML и CSS, логику веб-клиента реализуем средствами JavaScript. Но держим Canvas в уме.
Приведу простой пример на Canvas: если вы видите вращающийся кубик, значит у вас нет проблем с поддержкой Canvas!
00 FPS, 00 Faces
Технология клиента определена. Попытаемся описать принципы обмена данными с сервером. Рассмотрим простую игровую ситуацию.
- Пользователь авторизовался в игре
- Пользователь открыл игровое поле и наблюдает за ним не предпринимая никаких действий
- В игре произошло событие не зависящее от пользователя, например, на него напал другой пользователь
- Пользователь сделал ход
Поскольку технология реализации клиента на JavaScript подразумевает асинхронный обмен данными с сервером, то необходима реализация синхронизации действий пользователя с текущим игровым состоянием. Например, в рассмотренной игровой ситуации событие нападения на пользователя произошло на сервере, клиенту об этом ничего не известно, и для того, чтобы клиент об этом узнал, ему необходимо обратиться к серверу, без этого, пользователь делая ход не учитывает реальное игровое состояние. Например, у него выбили все кристаллы, а он делает ход в котором строит из кристаллов сейф, но вместо построенного сейфа, ему приходит сообщение о нехватке ресурсов, что конечно, вызовет раздражение. Для обеспечения качественного игрового процесса, необходимо найти оптимальную частоту обновления информации на клиенте, при этом не перегружая линию связи, сервер и клиент, а также разработать ёмкую систему сообщений о состоянии сервера. Это и станет нашей задачей в последующие дни.
Проектирование структуры данных
Начнём с того, что для разработки и отладки механики игры у нас нет необходимости сложного программирования для поддержки 1000 человек он-лайн, которые располагаются на карте Земли. Для простоты реализации все объекты будем располагать на игровой сетке, которую нарисовали во второй день проекта. И сделаем себе жизнь еще проще, сказав что только один объект может занимать клетку игрового поля. Это несколько отдаляет нас от Crystal Rain, основанной на GPS координатах, но даёт нам несколько существенных упрощений в модели: координаты объекта могут быть только целые а игровой мир можно представить в виде матрицы.
Целочисленные координаты объекта допускают, следующие удобные представления:
В виде матрицы
[ [0, p, 0, 0], [0, 0, c, s], [0, 0, c, 0], [0, 0, 0, 0] ]; //p - player //c - crystal //s - safe
В виде списка целых координат
[p[1,0], c[2,1], c[2,2], s[3,1]]; //p - player //c - crystal //s - safe
x2 Игровая ситуация описанная матрицей или списком целых координат с началом отсчёта в NW
К сожалению, следующая игровая ситуация не может быть представлена в виде матрицы 4×4, хотя и допускает представление списком дробных координат. Очевидно, что существует большое количество способов представлений, которые мы не рассмотрели и не рассмотрим. Для разработки игры оптимальными являются списки и матрицы.
В виде списка дробных координат
[p[2.7,0.9], c[3.6,1.6], c[2.85,2.3], s[3.1,1.9]]; //p - player //c - crystal //s - safe
x2 Игровая ситуация описанная и списком дробных координат с началом отсчёта в NW
Помимо удобного представления, целочисленные координаты существенно упрощают алгоритмы поиска кротчайшего пути с обходом препятствий и дают много других преимуществ в реализации.
Для того, чтобы можно было проверить и отладить баланс игры нужно принять несколько допущений из разряда пальцем в небо, которые, в процессе разработки, мы можем, конечно же, уточнить. Одно из них: количество игроков всего и количество активных игроков. Так как мы планируем многопользовательскую игру, которая в последствии может стать голбальным проектом, то нужно опробовать игровой процесс не менее чем на 1000 пользователях, из которых не менее 100 активных. Допущение принято умозрительно, наверняка существуют документы регламентирующие сколько должно быть привлечено пользователей для бета-тестирования. Другое допущение: представим что активному пользователю для того, чтобы играть нужно не менее 400 клеток игрового поля, а не активному 40. Получается, что при равномерном распределении нам нужно игровое поле размером 400*100 + 40*900 = 76 000 клеток игрового поля. Т.е., если поле квадратное, то его размер составит примерно 275 на 275 (75625 клеток всё игровое поле). Для хранения игрового поля размером 75625 клеток в матричном представлении, даже если одна клетка будет занимать 4 байт, что очень маловероятно, нам потребуется 295 Kb. В нашем случае при работе с СУБД типа MySQL или PostgreSQL лучше всего использовать представление [Объект, координата X, координата Y]. Храня игровую карту таким образом, мы в один запрос сможем получить список объектов находящихся в необходимом отдалении. Например, нам нужно вывести на экран, все объекты находящиеся в квадрате 20 клеток от игрока с координатами [x1, y1]. Условия запроса будут выглядеть следующим образом:
WHERE X<x1+20 AND X>x1-20 AND Y<y1+20 AND Y>y1-20
Такой формат хранения информации об игровом поле в СУБД допускает преобразование в матричное представление на уровне сервера, если оно нам понадобится для анализа.
Следующую запись, скорее всего, стоит ожидать только через день, поскольку необходимо уделить достаточное количество времени для изучения JavaScript, AJAX, JSON, JQuery, выбрать технологию реализации серверной части и начать программирование сервера и СУБД. Также, как и было обещано выше, получить основу клиент-серверного протокола.
Сводка
Начало: 25 апреля 2014 года.
Команда: 1 человек.
Израсходовано: 18 чч.
Средняя производительность: 18/3 = 6 чч/день
Описание игрового процесса
Расчет баланса
Игровая графика
Веб-клиент
Игровой сервер
ИТОГО
Даже не верится что 0 строчек кода это 10% от общей реализации проекта.
Продолжение: Growing Crystals vol 4. картинка на клиенте и запросы к серверу