Який тип документа для ігрового дизайну? [зачинено]

Який тип підтримки / формату ви використовуєте для зберігання та розповсюдження проектної документації на ігри? Вікі? Файли з документами? Файли в сховищі? Спільна папка? Google Doc?

Вкажіть, будь ласка, плюси та мінуси для кожного з них.

Я використовую Google Документи, тому що мені дуже потрібен текстовий редактор, який є в Інтернеті. Я можу відносно легко співпрацювати з людьми в Інтернеті, і я знаю, що моя інформація там захищена, якщо мій комп'ютер виходить з ладу.

Ще один варіант, на який варто звернути увагу - це використання Dropbox . Занесіть документ Word туди, і у вас моментально з’явиться середовище спільної роботи з контролем версій.

Wiki

Плюси:

• Остання версія, доступна завжди через Інтернет, з поза сайту тощо.
• Досить простий у використанні (якщо ви позбавитесь від тих, хто має коричневе кодування для форматування, як MediaWiki, тобто)
• Автоматична індексація, пошук, проста категоризація
• Легко приписувати зміни людям та притягувати їх до відповідальності за зміни
• Підтримує зв'язок і дозволяє легко та ефективно розбирати деталі
• Можна посилатися на сторінки вікі безпосередньо з внутрішніх звітів про помилки та іншої кореспонденції, що робить перевірку помилки дуже простою
• Історія версій та контроль версій, як правило, вбудовані

Мінуси:

• Іноді TOO легко змінювати (* див. Нижче) і вимагає дисципліни
• Сторінки можуть вийти з синхронізації, коли їх редагують поодиноко (наприклад, часто немає глобального пошуку та заміни)
• Сторінки осиротіли або витіснилися з них і пізніше залишаться потенційними мінними полями для кодерів. ( "Що ви маєте на увазі, що ми вже цього не реалізуємо? Це все ще є у вікі дизайну!" )
• Синтаксис може бути трохи езотеричним, якщо ви не отримаєте потрібний пакет
• Доводиться влаштовувати хостинг або приймати те, що доступне в Інтернеті безкоштовно
• Немає чіткого маршруту через документ - як ви читаєте це "все"?
• Важко друкувати. Чи можете ви роздрукувати все це одним кліком? Чи можете ви легко роздрукувати все, що стосується однієї функції, щоб взяти її на зустріч? Чи можете ви легко помітити цифрову версію без затемнення основного документа?

(* Ми використовували вікі для одного проекту, і дизайнери завжди спокушалися зайти і «покращити» його частини, навіть за функціями, які були підписані та надіслані для кодування. Потім, коли QA перейшла до тестування функції, вона це було б кошмаром, тому що часто дизайн підказує щось інше, ніж те, що було насправді закодовано, і знадобиться неабияка неприємна робота, щоб дізнатися, що сталося спочатку, зміна дизайну чи коду.)

Текстові файли

У своєму поточному проекті я використовую прості текстові файли в папці "Документи" проекту, що зберігаються в сховищі поруч з кодом.

Плюси:

• Документація зберігається близько до фактичної роботи, тому її легко знайти.
• Просте форматування означає, що документацію легко та швидко вести.
• Простий формат також означає, що існує невеликий ризик втрати документації через збої на сервері, пошкодження файлів тощо.
• Абсолютно мінімальний час налаштування робить це чудовим початком для окремих розробників або крихітних (2-3 особи) команд.
• Використання контролю версій означає, що зміни відслідковуються, і часто можна пов'язати зміни в документації безпосередньо зі зміною коду.
• Так само легко працювати з текстом, тому пошук, редагування тощо можна часто виконувати за допомогою інструментів командного рядка.

Мінуси:

• Більше пари користувачів і документ легко вийшли б із синхронізації.
• Ніяких посилань, тому ви або використовуєте один гротескно великий документ або кілька менших, але від’єднаних документів.
• Обмежені параметри форматування та публікації (хоча конверсію, наприклад, через Markdown, зробити досить просто).
• Так само легко працювати з текстом, тому часто єдиним способом пошуку, розширеного редагування тощо є використання інструментів командного рядка.

Ви не хочете покладатися на будь-яку командну роботу, але потужність текстових файлів у репо-репортажі, що дозволяють вам отримати право на роботу, не повинна недооцінюватись для одного розробника. В даний час я використовую один документ як своєрідний огляд / головний планувальник, який містить загальний дизайн, другий документ, який виконує роль ToDo-списку конкретних речей, які потрібні грі, третій документ як вільний трекер помилок та допоміжні документи для детальніше розробити "функцію x" за потребою.

Не використовуйте формат / редактор документа, який не підходить для користувачів (наприклад, MS Word, Open Office Writer). Лише одна людина може редагувати документ, і навіть за допомогою керування джерелами надто просто почати працювати над застарілою версією, а заощаджуючи, що ви в основному знищуєте все, що зробили інші користувачі за останній раз, коли користувач оновив свою версію документа.

Спільні папки - це найгірше рішення і абсолютно не потребують будь-якого виду активів, над якими слід працювати спільно. Ви ніколи не можете бути впевнені, що хтось ще працює над цим файлом зараз, або зробить це протягом наступних кількох хвилин. Ви також не маєте відстеження змін і не зможете повернутись до попередньої версії у випадку катастрофи (людська помилка, людська дурість або людська зневага).

Переважно використовувати Wiki, але зручну для користувачів та WYSIWYG. Я особисто клянусь Confluence , який також використовується у більших ігрових студіях для розробників і становить лише 10 доларів для 10 користувачів та необмеженого числа глядачів.

Більшість інших вікі (MediaWiki, TikiWiki та ін.) Мають меншу сторону в тому, що у них крута крива навчання або навіть практично непридатні для нетехнічного персоналу. Не те, що вони не могли цього навчитися, але вони (по праву) не приймають використання документальної системи, яка в основному вимагає написання коду, як HTML. Це мій вихованець: Вікі, які кажуть, що вони WYSIWYG, але все, що вони роблять, - це вставити синтаксис у текст, який ви пишете. Це не WYSIWYG!

Настановою щодо використання вікі є розміщення кожного заголовка на окремій сторінці, щоб ви могли розрізати документ на багато керованих частин. Confluence пропонує функції, за допомогою яких потім можна об’єднати всі ці підсторінки назад на одному веб-сайті чи документі, які, наприклад, можна експортувати в PDF.

Я думаю, що одна примітка - хороший варіант. Це щось на зразок Wiki, але з великою підтримкою редагування багатого тексту. Окрім стандартного настільного клієнта, який постачається разом із Office, існує веб-версія з пакетом Office Live . Чесно кажучи, я вважаю, що веб-версія, яка є безкоштовною, повинна бути достатньою для більшості потреб, і в поєднанні зі Skydrive у вас є досить гарна система для співпраці над живим документом.

Для одного з моїх проектів з відкритим кодом ми використовували (задихаючись) SharePoint для зберігання документів та носіїв інформації. Керування користувачами та дозволами є досить простим, і він підтримує повну історію версій. Ми працювали на сайті SharePoint вже близько чотирьох років, тому в даний час можуть бути найкращі варіанти. Тим НЕ менше, вона була розроблена дуже добре для нас. Він розміщений третьою стороною (приблизно 20 доларів на місяць), тому після початкового налаштування з нашого боку практично не було обслуговування. Окрім підтримки бібліотек документів і зображень, у SharePoint є підтримка Wiki, хоча я не впевнений, наскільки добре вона протидіє більш популярним двигунам Wiki.