Вопрос: Рустор ставить не хочу, можно ли поиграться где-то в онлайне?
Ответ: (спасибо за вопрос, теперь я научился компилировать из юнити вэб- и РС-версии). Вэбка размещена, например, здесь: https://eltare.itch.io/the-boss
Ну и вопрос, на который нужен прямо развернутый ответ: Было бы здорово, если бы вы опубликовали статью про формирование дизайн-документа. Понимаю, таких статей полно, но каждый по-своему заполняет дизайн-документ, поэтому хотелось бы увидеть, как вы это сделали.
Отвечаю: во-первых, спасибо за вопрос.
Во вторых, абсолютно согласен, что каждый заполняет дизайн-документ по-своему (скажу больше - я сам экспериментировал, пробовал разное в разных проектах)
В третьих: дисклаймер: ниже ОЧЕНЬ много текста. Скорее всего, бесполезного для продвинутых участников проектной деятельности. Ниже - мой опыт, местами ошибочный, местами может быть даже забавный, но какой уж есть. Поэтому не обессудьте.
Что такое дизайн-документ? Это текст, описывающий все (или большую часть) элементов игры (сюжет, описание геймплея, противников, союзников и т.д. и т.п.), а также её компонентов, таких как графика, возможно музыка, звуки, интерфейс, состав команды (разработчиков) и прочее и прочее и прочее. По сути - это "техническо-организационный проект исполнения игры". Я работаю в электроэнергетике и регулярно сталкиваюсь с проектами электроснабжения - вижу такие параллели (с той лишь разницей, что обычно проектируют одни, а строят другие, а в случае с диздоком, кто его делает, то и игру создает).
Здесь мог бы быть коротенький реферат страниц на 404 про диздок, но думаю, он вообще никому не интересен, но может быть, кому-то будет интересен мой личный опыт.
С дизайн-документом я познакомился во время работы на браузеркой (давно умершей) Ravensteel. Наш тимлид (ну... группы из 2-3 человек) длительное время пытался "выжать" из меня этот самый диздок и я, если честно, не сильно понимал его необходимость. В итоге я делал диздок, по нему мы работали (по крайней мере, некоторое время). Этот диздок был, скажем так, "классический" на основании "шаблонного" диздока. Наш диздок постоянно дополнялся, менялся, ну это, скажем так, классика и ничего интересного в этой части я не расскажу.
Важно понимать, зачем нужен диздок.Ответ простой - Это время затратный документ, который нужен Вам для того, чтобы сэкономить по итогу намного больше времени, чем Вы на него потратите.
Вот смотрите - Вам всё равно продумывать игру. Вам все равно продумывать геймплей, графику и так далее и так далее. Но если вы займетесь этим заранее, Вам не придется потом много переделывать ("много" выделено специально - переделывать всё равно, скорее всего, придется). Но если у Вас на руках готовый диздок (проект), Вы сможете его поступательно реализовать, а где или когда необходимо - отходить от проекта (это тоже нормальная практика, важно лишь понимать, что отходя от проекта-диздока, вы получаете лучший результат, но об этом позже).
И да, Вам не нужен (скорее всего) диздок, если Вы делаете простенькую игру - флаппи бирд там (её, вроде, за 3 дня автор сделал), или дино или тетрис, например. Сделать диздок можно, но не уверен, что он даст Вам какие-то существенные преимущества в разработке. А вот для более серьезной игры - здесь без него, уверен, не обойтись.
Немного интереснее, как я работал над своей первой самостоятельной игрой. Разобью разработку на этапы:
Этап 1: Концепт (разработка идеи игры)
Начал разработку даже не с диздока, а скорее с разработки идеи. Вроде, я писал, что первую игру сделал под впечатлением другой игры, но захотел сделать другое. То есть, у меня было примерное представление игрового процесса и я начал накидывать идеи, чем можно будет заниматься в моей будущей игре.
Здесь мне очень помогла программка для мобильного "Xmind". Вот как это выглядит (скрины с моего мобильника)
Вот то же самое, просто часть ближе (верхняя правая часть):
Чем этот инструмент (Хmind) удобен?
он самостоятельно строит схему. Вы добавляете элемент, программа сама его размещает, сдвигая элементы так, чтобы было удобно читать и использовать;
он мобильный. Есть идея - достали смартфон, запустили, записали и теперь уже не забудете;
он достаточно прост в освоении;
сама по себе система "ветвей" достаточно проста для понимания. Ну а если что-то не так, ветки можно и закрыть и "перевесить" на другие "ветки";
он бесплатный и в свободном доступе.
Собственно, идея моего первого соло-проекта была описана здесь, в Хmind. Понятно, что это ещё не диздок, но это уже едва ли не половина и это точно хороший задел: Я понимаю, что я хочу получить в игре, я понимаю, какие элементы будут доступны игроку, какие параметры, описаны определенные взаимодействия и так далее. То есть, уже есть игровые сущности, игровая механика, некоторое представление о том, как это будет выглядеть и кое что ещё.
Это всё было сделано ещё до того, как я начал изучать джаву (при том, что реализовал это потом на Си-шарп).
Этап 2: Создание диздока
Следующий этап был, можно сказать, забавным, я подумал, а чего бы не попробовать реализовать это в экселе. Звучит правда забавно, но эксель я на тот момент знал намного лучше, чем все эти джавы и шарпы (а ещё разные юнити эти, о которых вообще в то время не подозревал...), точнее, в экселе я хоть что-то знал, а в джавах и шарпах - вообще небельмеса...
Короче, я начал переносить информацию из Xmind в эксель. На каждый основной элемент игры создавал вкладку и расписывал этот элемент. Местами просто текстом, местами - таблицы, местами - формулы. В общем, к финалу выглядит всё так (выбрана одна страница):
По итогам, это и стало диздоком моего первого соло-проекта. Это реально - диздок, только не в... Как мне кажется, необычном, формате.
Ещё один важный момент - диздок в экселе отличался от того, что я "накидал" в Xmind. То есть, уже на стадии подготовки пошли изменения. И...
Этап 3: Разработка (реализуем и меняем диздок)
И даже больше - при создании игры я кое что менял, в том числе, некоторые механики. Не стесняйтесь менять свои планы! Конечно, не надо кардинальных изменений (планировал игру про "грабить корованы", а потом переключился на "блэк-джек с девицами", а оттуда - на "DOOM homemadeedition". Ну это, уверен, и так всем ясно-понятно. Изменения диздока нужны и важны, так как:
- Вы не сможете предусмотреть всего. Очень многое придется обдумывать и дописывать позже;
- по мере создания игры у Вас могут появиться замечательные идеи, которые явно лучше для игры, чем то, что планировалось изначально;
- некоторые планы могут оказаться просто нереализуемы на том уровне знаний и умений, на котором Вы сейчас находитесь (и иногда лучше "отступить", чем неделями, без особого результата, "штурмовать" какую-то проблему). Например, у меня была мысль, что игрок "кидает" пару кубиков, они катятся (в 3D), на них выпадает результат, движок игры его "считывает" и дает игровой эффект. Вроде, для юнити - это не сложная задача, но я потыкался, помыкался и плюнул на эту идею, сразу выводя на экран 2D кубики с выпавшим в рандоме результатом. Да, можно было разобраться и сделать, но я бы потратил на это минимум пару недель (я так думаю), а вариант с 2D реализовывался проще и я быстро получил результат.
Кстати, очень важно постоянно хоть по чуть-чуть продвигаться вперед (по крайней мере, для меня). Если застопориться, не видеть изменений (результат своей работы), можно "перегореть" и забросить идею. В том числе и поэтому, я не зацикливался на решении каких-то отдельных задач - потыркался, не получилось одним способом, попробовал второй, третий. Например, когда я реализовывал локализацию, я попробовал пару бесплатных ассетов (надстроек), но "не пошло" (один вариант был, на мой взгляд, не удобен, с работой второго я не смог "с ходу" разобраться, в итоге я нашел код локализации, использующий .csv файл, разобрался с ним, немного переписал под себя и реализовал именно через таблицу .csv - решение с возможностью очень простой и доступной локализации, хоть это и не понадобилось ;) ).
Ещё один момент работы с этим "экселевским" диздоком. В таблице сверху наверняка заметили раскраску - красное, желтое, зеленое. Это всего-навсего способ отметить что и как:
Текст без выделения: не реализовано.
Красный шрифт: идея не предполагалась к реализации в первой версии игры. То есть, это идеи для продолжения.
Желтый фон - реализовано.
Зеленый фон вкладки - тема реализована в объеме, который я считаю достаточным.
Желтый фон вкладки - реализация темы в процессе (частично "да", "нет").
В общем, такой примитивный способ цветового кодирования информации. Вот ещё один пример, в котором тоже есть, что рассказать:
Здесь я прикидывал, как будет выглядеть игра (внешний вид интерфейса), какие "окна" будут, а заодно здесь же - примитивный "кан-бан" (это тоже классный инструмент, о нем - позже).
К слову, ещё один пример того, что изменилось (но не изменилось в диздоке). Изначально я делал 4 основных игровых экрана, плюс на каждом экране делал 2-3 вкладки по теме выбранного экрана. Но быстро понял, что это плохая идея (заставлять игрока кликать более 1 раза, чтобы попасть на нужный ему экран) и вместо 4 основных экранов сделал 10. Но без дополнительных кликов. Примерно вот так получилось:
Короче, тема интерфейса - вообще отдельная тема и это не ко мне, я тут вообще не спец, я лишь знаю, что пользователю должно быть комфортно и интуитивно понятно, но... Не моя тема, короче, и здесь путных идей я не дам.
Ну так вот, теперь к обещанному "кан-бану". Инструмент родом из Японии, очень простой и прямо очень удобный (на мой взгляд). Я за него активно взялся при разработке второй игры, но потом понял, что он у меня уже был реализован в экселе (см. бело-желтую картинку выше).
Что такое "кан-бан", "канбан" или "кан бан доска". По сути - это список дел с отражением текущего состояния каждого дела (от "надо бы сделать" до "сделано"). В самом примитивном виде - это разделенная на участки доска, на которые крепятся бумаги с задачами (хоть булавками, хоть магнитами, хоть стикерами, хоть пишутся фломастерами - не принципиально). По мере реализации задач, они перемещаются на другие участки доски (состояния).
Каждая задача может иметь несколько состояний. В первом проекте у меня было три состояния задачи:
надо сделать (слева под надписью на зеленом фоне "Что ещё необходимо сделать")
что делается (справа под надписью "РЕАЛИЗОВАНО", но БЕЗ желтого фона)
сделано (справа под надписью "РЕАЛИЗОВАНО", выделено желтым фоном)
Чем это хорошо? Понятно, чем заниматься. Я брал себе задачу-две (просто перенес их в "РЕАЛИЗОВАНО" без выделения цветом) и спокойно их делал. Реализовал - покрасил в желтый цвет, осознал, какой я молодец (сумел сложить 2 и 2, а по итогам получить 4!) и взял следующую задачу. Это снова мотивирует продолжать работу (видишь результат и чувствуешь, что двигаешься в разработке).
Вот, так реализовал первую игру.
Второй проект реализовал чуть иначе. У меня уже были проработаны правила игры - изначально я раздумывал выпустить настольную версию игры, а когда думал, чего мы мне закодить ещё, наткнулся на готовые правила и подумал, что можно ведь сделать и игру на смартфоне. То есть, у меня уже был почти готов диздок (в формате гигл-документа, то есть, обычный текстовый файл с описанием игровой механики и игровых событий, уже даже протестированный на "живых людях" ;) ). Вот и весь диздок, почти по-классике.
Но в этот раз я уже искал подходящий и удобный инструмент типа "ту ду лист" (список дел). Остановился на канбане. Нашел несколько сайтов, где эта механика реализована (причем я не видел смысла покупать ресурс, и искал бесплатный вариант, который меня устроит функционалом). Нашел не сразу (начал работать на одном "бесплатном" ресурсе, который через 2 недели начал требовать с меня денег), перешел на другой и вот на нем остановился.
Это Битрикс 1С, условно-бесплатная среда для ведения проектов, контроля поручений и т.д. Условно-бесплатная она, если у Вас команда не более 12 человек (что в 12 раз больше, чем мне было нужно), ну и плюс платные версии открывают дополнительный функционал, который лично мне был не то, чтобы нужен. В системе несколько инструментов (причем одно и то же можно реализовать разными инструментами или одни и те же задачи разрабатывать под разными "углами" (например, завязывать их по срокам и т.д.).
Вот такая вот картинка получилась (на сейчас):
Процесс добавления задачи в этом канбане - очень простой: клик на "+" в элементе, появляется окно, в нем набрал (описал) задачу, нажал enter - готово. Чтобы перенести в другую колонку - зацепил мышкой белое окошко (или как Вы сами настроете) и перетащил куда надо. Всё очень просто и легко.
Канбан здесь настраивается, я сделал пять элементов процесса, но можно и больше (например, если в команде больше одного разработчика, полезно сделать элемент "проверено/принято тимлидом". Но мне было достаточно 5 элементов:
Идеи. здесь было то, что я не собирался реализовывать. То есть, здесь было то, что можно было бы не делать. Но часть этих идей я всё же реализовал;
В планах: то, что точно надо реализовать, но когда нибудь сильно потом (отложенные задачи);
Запланировано: то, что стоит в ближайшей очереди на реализацию;
Сделаю на неделе: задачи непосредственно в работе. Зачастую я брал их в "запланированном", реализовывал (в тот же день) и переносил в "Выполнено" (снова в тот же день). Но иногда тема "затягивалась", хоть и редко на закрытие задачи уходило более 2-3 дней. И да, в работе обычно было 1-3 задачи.
Выполнено: собственно, задачи, которые я реализовал.
Ещё из важного - задача это некая часть игры (кода), которая требует, грубо говоря, не менее часа на реализацию. Не стоит ставить задачу на "каждый чих" и "каждую сточку", хотя иногда у меня и такое было - к примеру, самая верхняя задача "Подсказка "Конец игры"?" подразумевала достаточно простую подзадачу на 2-3 минуты. Создавать такие задачи на канбане - излишне, для таких мелких и повторяющихся задач прекрасно подойдут списки и или таблицы (тот же эксель).
Этап 4: Тестирование (к диздоку уже не относится)
Теперь о тестировании. Когда игра уже близка к завершению, понятно, автор сам должен наиграться в неё настолько, чтобы она ему опостылела ;) Ну и заодно - выявить баги. Здесь у меня было два инструмента: скрины игры (с ошибками, багами, идеями) и списки.
Со скриншотами, думаю, всё предельно просто и понятно. В свободное время достал телефон и поиграл - потестировал. Увидел баг или необходимость улучшения, сделал скриншот, если баг или идея не очевидны, тут же открыл скриншот в редакторе и либо выделил "фломастером" и/или дописал какой-то текст. Потом вернулся, например, домой, сел за ПК и поочередно открывая на мобильнике скриншоты, ищешь в коде баги, убираешь их (создаешь новые баги) и так далее. Закрыл ошибку - удалил скриншот - забыл. Все просто.
По спискам - вот пример (скриншот с телефона) таких мини-задач, которые я себе накидал под реализацию по итогам очередного тестирования ("галки" стоят у реализованных задачек, в данном случае - везде). Но это уже не перечень багов (хотя баги есть), а идеи/задачи под реализацию.
Ну и ещё один вариант списков - банальней некуда. Пишем (шариковой/гелевой ручкой или карандашом, да хоть пальцем) на бумаге. Иногда этот вариант удобней и быстрей.
Ну, вот, в принципе, и всё!
Если вы смогли дочитать до финала - поставьте себе галочку напротив ачивки "Победитель длинностов" ;)
Очень надеюсь, хоть что-то из всей этой графомании хоть кому-то будет полезной!
