Pull to refresh

Онлайн игра: howto, или как я проспорил девушке программисту

Reading time 7 min
Views 5K
Не мало было историй о том, как небольшие группы разработчиков добивались успеха. И ещё больше о том, как эти разработки проваливались. Но здесь я хочу рассказать именно об эволюции процесса разработки онлайн игры, опираясь на свой опыт. Оговорюсь заранее: это первый мой опыт разработки массовой онлайн игры.
Всё началось весьма интригующе. Я имел неаккуратность поспорить со знакомой web-программисткой о том, кто быстрее и качественнее из нас сделает web-проект. Чтобы не сильно распыляться и не тратить много времени, решили, что нам будет дана всего одна неделя, а разрабатывать мы будем многопользовательскую игру!

По истечению этого срока проекты были сданы «оценочной комиссии», которой являлись наши общие друзья. И… Мой проект не выиграл. А самым обидным на тот момент казалось то, что, по условиям спора, я должен был выделить ещё одну неделю рабочего времени, чтобы помочь своей оппонентке в развитии её игры. Но спор есть спор!


Начало начал


Что у нас было на момент начала совместной разработки? Да почти ничего! Концепция в голове и немного исходного кода. Плюс к этому «команда», состоявшая из двух человек. Программированием занималась Марина. Я же занялся разработкой пользовательского интерфейса.

Моя неделя «рабства» прошла очень быстро и интересно. Были выправлены баги, а также реализовано несколько новых возможностей. На этом закончилась неделя, и я мог бы умыть руки, но… проект оказался действительно интересным, и мы решили продолжить его развитие.

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

1 неделя — концепт


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

Что представляла из себя концепция? Всего лишь набор фраз и предложений («мысли вслух»), в которых смысл могли увидеть только, наверное, мы. Но, не смотря на это, все основные моменты в ней были изложены, а потенциал развития проекта — заложен. На этом первая неделя подошла к концу.

2 неделя – начало работы, первые ошибки


Работать над проектом хотелось и работалось. Файлики с обновлениями часто перекидывались по мылу и аське. Старые версии кода и psd-шки с графикой удалялись и переписывались, будто потраченных на них вечеров и не было.

У каждого дома был настроен свой сервер, где и производилась работа. Почему был выбран такой принцип работы? Всё очень просто – сроки установили себе очень сжатые, а сделать хотелось очень много, поэтому решили не тратить время на бесполезную, как нам тогда казалось, настройку общего сервера и прочую синхронизацию работы. В голове сидело только одно: «осталось всего 3 недели… ещё и время тратить, когда его нет».
Но к концу недели мы взвыли и решили сделать всё так, как стоило бы сделать сразу.

3 неделя – subversion и рефакторинг


Установка subversion и хранение проекта в нём сильно облегчили нам жизнь. Теперь не приходилось тратить уйму времени на слияние наработанного. Всегда была возможность проверить последнюю версию проекта. И, что самое главное, оставалась возможность откатиться до ранней версии. Это тоже нам потом не раз «спасало жизнь». Оглядываясь назад, я недоумеваю, как мы могли вообще что-либо делать без системы управления версиями.

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

Позже от такого подхода отказались в пользу перетаскивания карты путём захвата мышкой (драг-н-дроп). При этом, проводить рефакторинг кода, отвечающего за эту функцию, мы поленились. Это привело к тому, что функциональность, предназначенная для одной задачи и хорошо выполнявшая свою роль, на другой задаче начала обрастать различными «допилами», а вместе с тем и ошибками. В образовавшейся каше для внесения элементарнейших изменений приходилось исправлять довольно много кода.
И после того, как практически полностью был переписан этот код, он стал на 70% меньше, при этом выполняя заметно больше задач.

4 неделя – первый взятый рубеж


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

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

5-7 недели – тудулисты и много работы


Собрав пожелания и отчёты об ошибках, мы занялись их сортировкой и расстановкой приоритетов. Всё это происходило в формате брейншторма, а все выводы записывались на стикеры. Весь этот процесс у нас занял все выходные. Результатом стала гора стикеров. Идеологи agile разработки говорят о том, что нужно взять доску, разделить её на области и повесить всё туда. Но этот вариант нас не устраивал – работали в разных частях города, и хотелось видеть завершенность задач в реальном времени.

Сначала обратились к специализированным онлайн сервисам, которые должны были помочь в совместной работе. Попробовав многие, убедились, что все они нам не подходят. Одни были перенасыщены функционалом, в других нам наоборот чего-то не хватало, третьи были платными.

В конце концов, мы отказались от сервисов в пользу googledocs. Настроив подсветку нужных столбцов, мы получили очень удобный todo-list.

Вот тут как раз и закипела основная работа. Задачи активно закрывались. Теперь мы видели прогресс, появился азарт. И от этого скорость разработки заметно повысилась.

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

Правильным бы было разбить задачу на подзадачи. Например, такие: «Сверстать таблицу в рейтинге», «Стилизовать кнопки в настройках», «Сверстать инвентарь в инфе игрока» и т.д. А специфика игрового интерфейса вообще не позволила бы никогда отправить первоначальную задачу в список выполненных (новые диалоговые окна появлялись с завидной регулярностью).

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

Месяц прошел не зря — было доработано очень многое. Тестирование прошло уже с заметно бОльшим успехом.

8 неделя – принцип Паретто, много результатов


Думаю, не стоит рассказывать про правило 80/20, о котором вы наверняка уже слышали. Расскажу лишь о том, как мы столкнулись с этой проблемой, и как боролись с неугодными 20% результата.

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

Чат. Здесь всё просто. Было решено разделить работу на два этапа – 80/20. Первоначально был сделан обычный чат, куда можно было отправлять сообщения. Просто и быстро: 40 строк серверного кода и десяток клиентского. Такие вещи, как приватные и личные сообщения, бан и т.п. были отложены на потом.

Игровой ландшафт. Долго мы тянули с этой задачей. Ой как нам не хотелось за неё браться! Думали, что это бесполезная функция. Но нас переубедили и, скрепя сердце, мы сели и сделали это… за несколько часов. Вот тут мы поняли, что сильно ошибались — эффект был выше всех наших ожиданий. Можете сами сравнить, как это ущербно выглядело «до», и насколько стало приятнее глазу «после».

Оповещения. Сколько мы не думали, так и не смогли придумать, как сделать это на скорую руку. Попробуй, пройдись по всему коду и перепроверь, любое ли действие игрока сообщает ему о том, что он сделал. Тут, конечно же, мы сами были виноваты в том, что не делали это по мере написания кода. Но ничего не оставалось, кроме как отложить эту задачу в долгий ящик.

Итогом недели стало то, что у нас были выполнены полезные 80%, а остальные 20% оказались отложены на потом.

9 неделя – принцип Паретто, мало результатов


Начало недели было сложным. У нас «висели» задачи, входившие в 20% результатов. Но что поделать… И тут мы сделали неожиданные, но при этом очень приятное открытие. Оказывается, задачи у нас были поделены поровну между двумя разработчиками, при этом не пересекаясь. Это давало возможность без отвлечения друг друга от работы завершить реализацию задач.

Этот опыт мы тоже учли. В дальнейшем мы поступали следующим образом: реализовывали задачи относившиеся к 80% результата, при этом пытаясь захватить по максимум пересекающегося функционала. А в дальнейшем устраивали «скучные» недели, когда каждый, не отвлекая партнера, завершал начатые задачи.

10-13 недели – очень много противных жуков



Настало время подготавливать проект к релизу. Гора сложно находимых и редко проявлявшихся ошибок, мелкие недочеты в первоначальной концепции. В общем, вместо четырёх планируемых на подготовку дней, мы увязли по уши на три недели. Было переписано много кода, который остался ещё с первых недель работы и постоянно докручивался «костылями». Именно на этом этапе мы проклинали то, что рефакторинг практически не производился.

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

Выводы:


1) Если проект будет содержать больше ста строк кода – имейте сформулированную концепцию. Если больше 1000 строк кода – имейте записанную концепцию.
2) Не бойтесь изменять концепцию, но не злоупотребляйте этим. Оставляя всё как есть, вы рискуете «не попасть в струю». В противном случае, вы никогда не закончите свой проект.
3) Не ленитесь использовать системы контроля версий, даже если вы думаете, что проект уложится в 100 строк кода.
4) Не бойтесь проводить рефакторинг, даже если вам кажется, что продукт завтра будет закончен и не потребует поддержки.
5) Разбивайте большие задачи на более мелкие, осязаемые. Они интереснее и продуктивнее выполняются.
6) Не забывайте писать регрессионные тесты.
7) Не спорьте с девушками даже насчет программирования. Тем более, если вам кажется, что программисты из них плохие :)

Сервер временно лег, не были готовы к такому.
Вернули к жизни.

И напоследок, наш программист, за работой :)
Tags:
Hubs:
+155
Comments 210
Comments Comments 210

Articles