Было много историй о том, как небольшие команды разработчиков добивались успеха.
И еще больше о том, как эти разработки провалились.
Но здесь я хочу поговорить конкретно об эволюции процесса разработки онлайн-игр, исходя из моего опыта.
Заранее оговорюсь: это мой первый опыт разработки массовой онлайн-игры.
Все началось очень интригующе.
У меня хватило смелости поспорить с другом веб-программистом о том, кто из нас сделает веб-проект быстрее и лучше.
Чтобы не распыляться и не тратить много времени, мы решили, что нам дадут всего одну неделю, и мы займемся разработкой многопользовательской игры! По истечении этого срока проекты были переданы «оценочной комиссии», которая была нашими общими друзьями.
И.
Мой проект не победил.
И самым обидным на тот момент казалось то, что по условиям спора мне пришлось выделить еще неделю рабочего времени, чтобы помочь сопернице развить свою игру.
Но спор есть спор!
Начало времени
Что мы имели, когда начали совместную разработку? Почти ничего! Концепция в уме и некоторый исходный код. Плюс была «команда», состоящая из двух человек.Марина отвечала за программирование.
Я начал разработку пользовательского интерфейса.
Моя неделя «рабства» прошла очень быстро и интересно.
Исправлены ошибки и реализовано несколько новых функций.
На этом неделя закончилась, и я мог бы умыть руки, но.
проект оказался действительно интересным, и мы решили продолжить его развитие.
Основной целью было как можно быстрее сделать первую рабочую версию.
Сроки снова были выбраны строго: 1 месяц.
И это с учетом того, что мы играли в игру только в свободное от работы время, находясь в разных частях города и общаясь только по аське и скайпу.
1 неделя - концепция
Для начала решено было изложить всю концепцию на бумаге.Именно это уберегло нас от больших ошибок в будущем.
Какова была концепция? Просто набор фраз и предложений («мысли вслух»), в которых только, наверное, мы могли увидеть смысл.
Но, несмотря на это, в нем были изложены все основные моменты и заложен потенциал развития проекта.
На этом заканчивается первая неделя.
Неделя 2 – начало работы, первые ошибки
Я хотел работать над проектом и работал.Файлы с обновлениями часто выкладывались по мылу и аське.
Старые версии кода и PSD-файлы с графикой были удалены и переписаны так, будто вечеров, проведенных за ними, и не было.
В каждом доме был установлен свой сервер, на котором и велась работа.
Почему был выбран именно такой принцип работы? Все очень просто — мы поставили перед собой очень сжатые сроки, а сделать хотелось очень много, поэтому решили не тратить время на то, что нам казалось бесполезным на тот момент — настройку общего сервера и прочую синхронизацию работы.
В голове было только одно: «осталось всего 3 недели.
и пора тратить время, когда его нет».
Но к концу недели мы взвыли и решили сразу сделать всё так, как надо было.
Неделя 3 – Subversion и рефакторинг
Установка Subversion и сохранение в ней проекта значительно облегчили нам жизнь.Теперь нам не пришлось тратить много времени на объединение накопленного.
Всегда можно было проверить последнюю версию проекта.
И, что самое главное, можно было откатиться на более раннюю версию.
Это тоже не раз «спасало нам жизнь».
Оглядываясь назад, я задаюсь вопросом, как мы вообще могли что-то сделать без контроля версий.
Также одним из волевых решений был провести рефакторинг несмотря на то, что времени оставалось всё меньше и меньше.
Например, в начале игровая карта управлялась с помощью навигационных стрелок (дискретно), а участки игрового мира отображались кусками с большими шагами.
Позже от этого подхода отказались в пользу перетаскивания карты путем захвата ее мышкой (drag-n-drop).
При этом нам поленилось провести рефакторинг кода, отвечающего за эту функцию.
Это привело к тому, что функционал, предназначенный для одной задачи и хорошо выполняющий свою роль, начал обрастать различными «надстройками» и одновременно ошибками в другой задаче.
В результате чего пришлось исправлять довольно много кода, чтобы внести самые базовые изменения.
А после того, как этот код был почти полностью переписан, он стал на 70% меньше, при этом выполняя значительно больше задач.
Неделя 4 – достигнут первый рубеж
За оставшуюся неделю до дедлайна мы выполнили почти всё, что хотели.Что-то мы не успели сделать, где-то сделали слишком много.
Но, несмотря на то, что решения о реализации того или иного функционала принимались на интуитивном уровне, выбор почти всегда оказывался правильным.
Наши первые тестеры оценили внесенные изменения.
Закрытое тестирование показало, что не все сделано идеально и что онлайн-игра более сырая, чем готова к показу людям.
Интерфейс практически отсутствовал; управлять игровым процессом было крайне сложно и неинтуитивно.
Но при этом был большой потенциал для развития, а геймплей нашим тестерам понравился.
Поэтому было решено не останавливаться на достигнутом.
5-7 недель – тудулисты и много работы
Собрав запросы и отчеты об ошибках, мы начали их сортировать и расставлять приоритеты.Все это происходило в формате мозгового штурма, а все выводы записывались на стикерах.
Весь этот процесс занял у нас все выходные.
В результате получилась гора наклеек.
Идеологи гибкой разработки говорят, что нужно взять доску, разделить ее на области и все туда повесить.
Но нас этот вариант не устраивал — мы работали в разных частях города и хотели видеть выполнение заданий в реальном времени.
Сначала мы обратились к специализированным онлайн-сервисам, которые должны были помочь в совместной работе.
Перепробовав многие, мы убедились, что все они нам не подходят. Некоторые были перенасыщены функционалом, в других, наоборот, нам чего-то не хватало, а третьи были платными.
В итоге мы отказались от сервисов в пользу googledocs. Настроив подсветку нужных столбцов, мы получили очень удобный todo-лист. Вот тут-то и закипела основная работа.
Задачи активно закрывались.
Сейчас мы видим прогресс, есть волнение.
И благодаря этому скорость разработки заметно возросла.
На этом этапе мы столкнулись с одной идеологической ошибкой: мы сформулировали несколько больших, неконкретных задач.
Один из них имел следующую формулировку: «Перевернуть все диалоговые окна».
Сейчас такая постановка задачи кажется нам дикой и даже не выглядит задачей, но тогда все было иначе.
Из-за такой расплывчатой формулировки задачу не закрывали полтора месяца.
Правильно было бы разбить задачу на подзадачи.
Например, такие как: «Создать таблицу в рейтинге», «Стилизовать кнопки в настройках», «Создать инвентарь в информации об игроке» и т. д. А специфика игрового интерфейса никогда не позволит выполнить исходную задачу.
отправляться в список завершенных (новые диалоговые окна появлялись с завидной регулярностью).
Также благодаря легкой руке тестировщиков мы получили множество новых запросов на реализацию того или иного функционала.
Я вспомнил самое начало работы и то, что не зря у нас была единая концепция, изложенная на бумаге.
Было решено отказаться от каких-либо сильных отклонений от концепции.
Следуя этому простому правилу, мы дали себе возможность уложиться в установленные сроки и не потеряли целостность игрового процесса.
Месяц прошел не зря – многое было доработано.
Тестирование уже прошло с заметно большим успехом.
Неделя 8 – Принцип Парето, много результатов
Я не думаю, что об этом стоит говорить правило 80/20 , о котором вы, наверное, уже слышали.Я просто расскажу, как мы столкнулись с этой проблемой и как справились с нежелательными 20% результата.
На этом этапе тестеры потребовали от нас чата, разнообразия игровых ландшафтов и уведомления о начале и окончании всех игровых действий.
Чат. Здесь все просто.
Было решено разделить работу на два этапа – 80/20. Изначально был сделан обычный чат, куда можно было отправлять сообщения.
Просто и быстро: 40 строк серверного кода и десяток клиентского кода.
Такие вещи, как личные и личные сообщения, баны и т. д. были отложены на потом.
Игровой пейзаж.
Мы надолго отложили эту задачу.
Ох, как нам не хотелось за это браться! Они считали это бесполезной функцией.
Но мы были убеждены и, нехотя, сели и сделали это.
за несколько часов.
Тут мы поняли, что сильно ошибались – эффект превзошёл все наши ожидания.
Вы можете сами сравнить, насколько поврежденным оно выглядело «до» и насколько приятнее глазу стало «после».
Оповещения.
Сколько бы мы ни думали, мы не могли придумать, как это сделать быстро.
Попробуйте, просмотрите весь код и дважды проверьте, что любое действие, предпринимаемое игроком, сообщает ему, что он сделал.
Тут, конечно, мы сами были виноваты, что не сделали этого при написании кода.
Но ничего не оставалось, как отложить эту задачу на второй план.
Итог недели таков: полезные 80% мы выполнили, а оставшиеся 20% отложили на потом.
Неделя 9 – Принцип Парето, мало результатов
Начало недели было трудным.У нас были задачи, которые вошли в 20% результатов.
Но что поделать.
И тут мы сделали неожиданное, но в то же время очень приятное открытие.
Получается, что наши задачи были разделены поровну между двумя разработчиками, не пересекаясь.
Это позволило завершить выполнение задач, не отвлекая друг друга от работы.
Мы также учли этот опыт. В дальнейшем мы поступили следующим образом: реализовали задачи, связанные с 80% результата, стараясь при этом захватить как можно больше пересекающегося функционала.
А позже устраивали «скучные» недели, когда каждый, не отвлекая партнера, выполнял начатые дела.
10-13 недель – много неприятных ошибок.
Пришло время подготовить проект к релизу.
Гора труднонаходимых и редко появляющихся ошибок, мелких недочетов исходной концепции.
В общем, вместо запланированных на подготовку четырех дней мы застряли по уши на три недели.
Было переписано много кода, который остался с первых недель работы и постоянно дорабатывался «костылями».
Именно на этом этапе мы проклинали то, что рефакторинг почти не проводился.
В свою очередь, ошибки регрессии позволили нам понять, что написание автоматизированных тестов значительно облегчает жизнь.
Но это следующий шаг.
Выводы:
1) Если проект будет содержать более ста строк кода, иметь сформулированную концепцию.Если количество строк кода превышает 1000, запишите концепцию.
2) Не бойтесь менять концепцию, но не злоупотребляйте ею.
Оставив все как есть, вы рискуете «не попасть в поток».
В противном случае вы никогда не закончите свой проект. 3) Не ленитесь использовать системы контроля версий, даже если считаете, что проект уместится в 100 строк кода.
4) Не бойтесь рефакторить, даже если вам кажется, что продукт будет готов завтра и поддержки не потребует. 5) Разбивайте большие задачи на более мелкие и ощутимые.
Они интереснее и продуктивнее.
6) Не забывайте писать регрессионные тесты.
7) Не спорьте с девушками даже по поводу программирования.
Особенно, если вы думаете, что они плохие программисты :) Сервер временно отключился, мы не были к этому готовы.
И наконец наш программист за работой :) 
Теги: #разработка интернет-проектов #разработка игр #игры #онлайн-игры #эволюция #девушки в этом #диспут #разработка сайтов
-
Рок-Музыка Внутри
19 Oct, 24 -
Xfce 4.10
19 Oct, 24 -
Тестирование Мобильного Клиента Vzochat
19 Oct, 24 -
Экзоскелет В Массы
19 Oct, 24 -
Службы Восстановления Windows Azure
19 Oct, 24 -
10 Хитростей Лучших Фрилансеров
19 Oct, 24
