Архив рубрики: Я стану РП

Мой путь к должности Руководитель Проектов: что учил, что читал, насколько оказалось полезным и как в последующем использовал.

Обнаружил для себя интересный блог

Обнаружил для себя интересный блог, по тематике управление проектами.

Вот он — https://psilonsk.livejournal.com/

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

Не хочется плагиатить, но хочется поделится материалом. С многим в этом блоге я согласен и считаю полезным, особенно мне приглянулись следующие материалы:

 

Трудности при разработке игр.

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

«Оставь надежду всяк сюда входящий» — создание игры чаще всего, это не «круто» или «весело», а это работа или даже «ТРУД», к которому надо себя заставлять:

  1. Учиться — а куда же без этого. Если вы рассчитываете все делать самостоятельно, то придется мнооого учиться. Даже если вас в команде 3-4 человека, то все равно придется совмещать те же 3-4 роли).
  2. Выделять время — за 2-3 часа в неделю на что-то типа тетриса вам потребуется года полтора, если опыта мало, или полгода если он уже есть (имеется ввиду создание не «работающего прототипа», а полный цикл).
  3. Искать команду — если и тетрис можно сделать самому, то для всего остального нужно разделение труда. Как только мы видим что новый проект своими силами мы реализуем за 6-7+ месяцев нужно искать команду, обычно проекты забрасываются на этом сроке из-за «усталости».

Проект разработки можно разделить на несколько этапов — они могут и будут чаще всего идти частично параллельно, но обычно следующий этап нельзя начинать пока не наберется «критическая масса» с предыдущего и крайне не рекомендуется держать активными больше 2-х этапов — если 3, то это уже увеличение объема работ, ну а 4 — уже не «процесс», а «каша» которой и управлять нельзя и результат будет непонятный:

  1. Идея — да все банально, без создания воздушного замка в голове все последующие действия будут напоминать подергивание под музыку — «вроде и не месте стоим, но и танцем это не назвать». Под идеей, нет не так под ИДЕЕЙ, понимается не мысли «сделать новый варик», или «сейчас по быстрому забацаю КС». Под идей понимается вполне конкретное ТЗ, в любом виде, но оно должно быть! с описанием игры, мира, игрового процесса, фич, дизайна игры, дизайна локаций, используемых технологий, ГДЕ и КТО как вы ожидаете в эту игру будет играть — это из обязательного.
  2. Создание элементов — сначала идет кропотливая работа по созданию различных объектов, физики, скриптов, рисуются текстуры и фоны.
  3. Создание прототипа из элементов — как только элементов хватает чтобы собрать 1 демо уровень, сразу это делаем и проверяем концепцию игры, геймплей и др составляющие, на этом этапе еще как то можно повлиять на результат без сильных задержек в сроках. Но стоит помнить что это самый затратный и сложный этап — как только он выходит на финишную прямую что-то поменять будет сложно без существенных дополнительных ресурсов.
  4. Тиражирование — тут начинаем творить, у нас уже есть необходимые объекты (персонажи, элементы локаций, элементы интерфейса и тд) со всеми его возможными действиями, есть большая часть объектов, текстуры уже «натянуты» на объекты, по большей части, начинаем все ЭТО компоновать в «Сцены» ну или уровни.
  5. Тестирование — перед выходом «в люди», нужно протестировать ВСЕ что только можно, любая мелочь, которую «добавили в последний момент» может сделать игру «непроходимой» или «проходимой слишком просто», как показывает практика — попытка «выстрелить» есть только 1 — НЕЛЬЗЯ выпускать сырой продукт для общего использования!
  6. Сопровождение — а куда без него). Получаем фидбак и делаем исправления.
  7. Модернизация — Тестировать больше нечего, ключевые ошибки выловили и подчистии — проект взлетел? Если да, то отлично — самое время для реализации всего что «хотелось, но не моглось», а именно , повторяем 4-5 этапы и делаем новый контент (DLS). Добавляем новые фички и логику.  Главное на этом этапе вовремя понять что «хватит доить золотую корову»), и приступать к новым свершениям. Ну а если проект не взлетел, то порадоваться полученному опыту и с новыми силами браться за новые проекты.

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

В следующей части переходим к пункту 1 — Учиться), а именно обзор того что нужно знать, хотя бы на базовом уровне!