Войти
Игровой ДизайнФорумОбщее

Ищу инструмент для ведения диздоков

Страницы: 1 2 3 Следующая »
#0
(Правка: 4:25) 4:12, 29 сен. 2019
В поисках инструмента для ведения дизайн-документов на начальной стадии разработки и удобному удаленному доступу к нему.
То, что я пишу и ищу — применимо для небольшой команды в несколько человек работающей удалённо. (Применения в больших командах в рамках этого топика на рассматривается, хоть и потенциально возможно).
Я считаю, что диздок должен писать и редактировать исключительно один человек (как правило, ведущий геймдизайнер). Другие члены команды должны иметь удобный доступ к документации и возможность обратной связи в виде заметок на полях/стикеров/закладок с общедоступным текстом, но при этом не иметь возможности непосредственного редактирования. Документацией занимается один человек. Точка.

Требования:
    1. Базовые возможности текстового офисного редактора: форматирование размера текста и шрифтов, якоря для ссылок, вставка графиков и медиа.
    2. Онлайн-доступность, настойка прав доступа.
    3. Возможность выдачи следующих прав доступа для участников: невозможность редактирования документа, но возможность вставки своих заметок (общедоступных), которые реализованы в виде разноцветных стикеров. Они не должны отвлекать от чтения документа. По умолчанию они свернуты, и открываются по нажатию.
    4. Автоматизированное оповещение участникам о внесенных изменениях. Дата, документ, разделы + текстовое послание редактора.
    5. Опционально: возможность работы с документами вне сети (offline). Загрузить документ, отредактировать.

Я вижу процесс начальной работы с документацией таким:
    1. И все начинается с идеи… а потом идея переноситься на бумагу.
    2. Человек, ответственный за ведения документации (далее: ГД) ведет подготовительные работы для записи документации, создает структуру дизайн документа.
    3. ГД создает основу дизайн-документа, кратко записывая все самое главное и создает дополнительные файлы документов для подробного описания отдельных механик, также игровые базы данных.
    4. ГД оповещает других членов команды, что готова первая версия дизкода, и можно приступать к обсуждениям.
    5. Члены команды пересматривают документ, оставляют свои заметки на полях.
    6. Некоторое время дается на то, чтобы все высказали свои мысли в текстовом виде. Также доступны комментарии к заметкам на полях.
    7. Проведения онлайн-конференцию, в котором все члены команды ведут обсуждение, приводят аргументы к своим мыслям, высказанных ранее в текстовом виде и добавляют новые.
    8. ГД вносит изменения в диздок.
    9. ГД оповещает о готовности повторного рассматривания.
    10. Члены команды пересматривают обновленные блоки документа или документ целиком. Оставляют свои заметки на полях.
    11. Ведется разработка, по ходу которой к диздоку оставляют заметки.
    12. Онлайн-конференция.
    13. ГД редактирует диздок.
    14. Всем оповещается о внесенных изменениях*.
    15. Повторить 10-14.

*процесс оповещения о внесенных изменениях должен быть автоматизирован. Но ГД оповещает дополнительно о важных изменениях, принципиально новых идеях, как в текстовом виде, как и при онлайн-собрании.

Заметки на полях можно также называть закладками (текстовыми, общедоступными). К этим заметкам тоже желательно должна быть возможность делать заметки (комментарии), но это не обязательно, так как можно просто добавить заметку рядом.

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

Но в первую очередь эта тема создана для поиска инструментов. Напишите, какие инструменты соответствуют моим требованиям, плюсы, минусы, обзоры и так далее.
Приветствуются ссылки на статьи, близкие по теме.
Копия_текста_темы

#1
6:05, 29 сен. 2019

Google Docs

#2
(Правка: 7:26) 6:20, 29 сен. 2019

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

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

И уж точно не нужны голосования. "Миллионы леммингов не могут ошибаться"? Гемдиз собирает информацию из выбранных им источников, а не от всех желающих высказаться.


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

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

#3
7:27, 29 сен. 2019

Базовый геймдизайн можно сделать в HackNPlan (часть Design),
а дальше - только доки :) или офис для асинхронного редактирования.

#4
9:09, 29 сен. 2019

AndrewRain
> 4. ГД оповещает других членов команды, что готова первая версия дизкода, и
> можно приступать к обсуждениям.
>     5. Члены команды пересматривают документ, оставляют свои заметки на полях.
>     6. Некоторое время дается на то, чтобы все высказали свои мысли в текстовом
> виде. Также доступны комментарии к заметкам на полях.
>     7. Проведения онлайн-конференцию, в котором все члены команды ведут
> обсуждение, приводят аргументы к своим мыслям, высказанных ранее в текстовом
> виде и добавляют новые.
>     8. ГД вносит изменения в диздок.
>     9. ГД оповещает о готовности повторного рассматривания.
>     10. Члены команды пересматривают обновленные блоки документа или документ
> целиком. Оставляют свои заметки на полях.
>     11. Ведется разработка, по ходу которой к диздоку оставляют заметки.
>     12. Онлайн-конференция.
>     13. ГД редактирует диздок.
>     14. Всем оповещается о внесенных изменениях*.
>     15. Повторить 10-14.

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

Google docs вполне пойдут по теме вопроса.

#5
10:12, 29 сен. 2019

https://www.atlassian.com/software/confluence

#6
(Правка: 11:13) 11:11, 29 сен. 2019

AndrewRain
> 1. Базовые возможности текстового офисного редактора: форматирование размера
> текста и шрифтов, якоря для ссылок, вставка графиков и медиа.
слишком перегруженный функционал ... какбе иногда нужен но не всегда и не всем

AndrewRain
> Я вижу процесс начальной работы с документацией таким:
...
Чувак, откуда в тебе столько бюрократии ?
Может просто делать игру ... А?

AndrewRain
> То, что я пишу и ищу — применимо для небольшой команды в несколько человек
> работающей удалённо.
ИМХО небольшой команде нужно работать, а не херней страдать с форматированием документов.

Реально я вижу смысл только в запрете нестандартного/неугодного софта и белом списке софта который рекомендован, пусть все присылают свои работы/отчеты либо в шареный гугл докс либо в *.тхт,  если там картинки или порнуха паковать в 7zip(можно запаролить), и там можно екзешник сделать для распаковки чтобы юзернейм мог распаковать даже если на машине нет 7z архиватора.


ИМХО

P.S.А еще есть вариант создать свой закрытый форум и выгружать всё туда и там же это обсуждать

#7
(Правка: 11:31) 11:30, 29 сен. 2019

endeavour_pr
> слишком перегруженный функционал ... какбе иногда нужен но не всегда и не всем
Поддерживаю.
Диздок - внутренний документ. Его прочитают 10-20 человек, в лучшем случае, а скорее 5-6.
Не надо тратить лишних сил на его оформление. Достаточно набить руку, чтобы написание как таковое времени не занимало сверх того, что нужно для выработки содержимого.

При изменениях полезно помнить, что читать будут те же люди, что читали не измененный вариант и упростить им работу, не заставлять читать полностью, выискивая отличия.

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

#8
19:57, 29 сен. 2019

AndrewRain

С тем, что я увидел (м.б. кроме "Онлайн-конференция") справится обычный (почти любой классический) task/issue tracker.

#9
22:49, 29 сен. 2019

AndrewRain
> В поисках инструмента для ведения дизайн-документов на начальной стадии
> разработки и удобному удаленному доступу к нему
Лично я в последнее время использую Google docs для документов, Sheets для таблиц. Они отвечают всем заявленным требованиям, за исключением стикеров (вместо них использую комментарии) и пункта №4. На почту приходят оповещения о комментировании, насчет остального не знаю - не было необходимости в подобном. Также использую draw.io для майндмапов, balsamiq.com для мокапов интерфейсов и иногда miro.com для прототипирования интерфейсов. Таск-трекеры - Trello и Pivotal. Знаю, что многие компании используют для диздоков вики движки, confluence и т.д. На Confluence многие ругаются из-за сложности в освоении.
Еще мне советовали https://www.notion.so/ - рабочее пространство, в котором есть возможность вести документацию, есть таск-трекер и т.д. Пока не пробовал.

AndrewRain
> Я считаю, что диздок должен писать и редактировать исключительно один человек
> (как правило, ведущий геймдизайнер).
Очень сильно зависит от величины проекта. Зачастую над проектом работает несколько геймдизов.

Zab
> Диздок - внутренний документ. Его прочитают 10-20 человек, в лучшем случае, а
> скорее 5-6.
> Не надо тратить лишних сил на его оформление.
Спорное утверждение. Документ должен быть оформлен так, чтобы текст был максимально читабельным, а информация в нем была максимально структурированной. Зачастую приходится описывать довольно сложные механики, и если плохо оформлять документы, то коллеги Вас проклянут.

#10
(Правка: 23:12) 23:08, 29 сен. 2019

Indoril
> Спорное утверждение. Документ должен быть оформлен так, чтобы текст был
> максимально читабельным, а информация в нем была максимально структурированной.
Читать любой документ это боль.Быстрее спросить в чатике.
Это же не  разные кампании или отделы одной корпорации в которой тысяча человек.
если что-нибудь чтобы не потерялось типа схемы управления то его  можно в фотошопе нафигачить и расшарить, тамже и текст зафигачить и ссылки тудаже )))
Открываешь фотошоп и видишь вот там схема управления, вон там еще какая-то херня, вон там ссылка на текстовик и так далее

лайвхак типа

#11
23:50, 29 сен. 2019

endeavour_pr
> Читать любой документ это боль.Быстрее спросить в чатике.
Документация нужна как раз для того, чтобы по прочтению возникало как можно меньше вопросов. :) Если их слишком много - значит, геймдизу еще есть, к чему стремиться.

#12
23:56, 29 сен. 2019

Конфлюенс приятный, сам пользуюсь как набором документов в стиле вики.

#13
5:21, 30 сен. 2019

Indoril
> Спорное утверждение. Документ должен быть оформлен так, чтобы текст был
> максимально читабельным, а информация в нем была максимально структурированной.
> Зачастую приходится описывать довольно сложные механики, и если плохо оформлять
> документы, то коллеги Вас проклянут.
А кто спорит то? Писать документы так, чтобы их читать можно было - уметь надо. Не быстро этому учатся даже те, кто вообще способен научиться. Но хорошо писать - не значит писать медленно. И вовсе не обязательно использовать дорогие в реализации приемы оформления.
Думаю, не место тут излагать типовые приемы, тема о другом. Да и разные они, не всем подойдут мои, а какими-то наверное я и не владею, нет пределов развитию.

#14
11:37, 30 сен. 2019

AndrewRain
  Ручки и бумага

Страницы: 1 2 3 Следующая »
Игровой ДизайнФорумОбщее