Вы на самом деле используете диаграммы для моделирования игр? [закрыто]

Я имею в виду в основном UML, но любой метод, который работает, жизнеспособен. Итак, вы действительно моделируете свои игры с помощью UML / других диаграмм или другими методами? У меня в университете был предмет о моделировании с использованием UML, и это казалось большим усилием, чем реальным преимуществом, но я понимаю, что это может быть только потому, что я никогда не создавал огромную сложную ИТ-систему. Так стоит ли и какие типы диаграмм / методов обычно являются * лучшими?

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

Изменить: я забыл одну важную вещь - вы создаете диаграммы до или после реализации материала? Я имею в виду следующее: когда кто-то проектирует и реализует что-то, что обычно передумывает, или возникает что-то неожиданное, и нужно вносить изменения, иногда серьезные, - и делать их в уже сложных диаграммах кажется таким же безнадежным, как и в самом коде.

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

Поэтому мои диаграммы большую часть времени находятся на очень высоком уровне и чувствуют себя как карты разума .

Чтобы добавить некоторые примеры, это на самом деле карта наследования классов (которая была вырезана) в моей игре, где Interactive Object является базовым типом.

Это диаграмма FSM ( конечного автомата ) для ловушек с шипами (эти удивительные ловушки, на которые вы наступаете, и шипы с дураками появляются с земли).

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

Когда я перехожу на более низкий уровень, это обычно потому, что мне нужно спланировать самые сложные аспекты моей архитектуры, и я обычно имею дело с UML. Я никогда не концентрируюсь на выводе абсолютно чистого и правильного UML. Я принял то, что мне больше всего понравилось в соглашении UML, и превратил его в приятный UML-шаблон mindmap-ish. Это просто и делает эту работу за меня, но я бы не стал заниматься этим в среде, где ожидается настоящий UML по понятным причинам.

Другая ситуация, когда мне приходится переходить на более низкий уровень, - это когда мне приходится описывать реальные алгоритмы. Я использую то, что я называю блок-схемами . Это формат, основанный на диаграммах, используемых при тестировании белого ящика .

Образец ловушки с шипами, который я нарисовал прямо сейчас, будет выглядеть так:

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

Это не связано с разработкой игр, у меня также есть хороший формат для описания экранов в многоэкранном приложении, функциональности, которую пользователь может запускать на каждом экране, и взаимосвязи между экранами. Я обычно создаю их перед началом фактической разработки, и они действуют как карта на протяжении всего процесса разработки. Если это для клиента, диаграмма экрана еще более полезна! Это помогает мне пройти весь проект от начала до начала и принять во внимание все функциональные возможности, которые ему понадобятся. Поэтому, это неоценимо для предоставления точной оценки стоимости и времени.

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

Я, конечно, делаю - как структурное, так и поведенческое - мое эмпирическое правило заключается в том, что я делаю диаграммы, когда стоимость создания диаграммы меньше, чем пытаться вспомнить, какого черта я думал месяц спустя - или когда мне нужно четко объяснить себя какой-то другой разработчик

Диаграммы классов, когда иерархия наследования становится достаточно сложной

Диаграммы объектов, когда такие вещи, как создание объектов, становятся чем-то граничащим с созданием монстра Франкенштейна из разнородных частей, что особенно полезно для пользователей вершин и пиксельных шейдеров кухонных раковин, чтобы убедиться, что все необходимые биты проталкиваются через канал

Диаграммы последовательности, когда детальные взаимодействия между набором объектов становятся сложными - это чрезвычайно полезно при моделировании сложных потоков рендеринга, где ранее вычисленная информация необходима в едва связанных расположениях вниз по течению

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

При навигации в новом городе, вы на самом деле останавливаетесь и смотрите на карту, а не просто продолжаете и следуете указателям? Вот что такое дизайн против кодирования. Когда вещи незнакомы, когда проблема сложна, когда вы чувствуете себя потерянным, именно тогда размышления о дизайне наиболее полезны, и лучше делать это раньше, чем позже. Гораздо проще изменить свой дизайн, прежде чем что-то реализовывать .

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

• Слишком много подключений к одному компоненту? У вас может быть объект бога, который трудно поддерживать
• Слишком много взаимосвязей? Может быть, модульность может быть улучшена, чтобы сделать архитектуру менее хрупкой
• Слишком много путей между двумя компонентами? Возможно, у вас есть тесная связь
• Для высокопроизводительных приложений, таких как игры, слишком много компонентов задействовано в горячем пути или внутреннем цикле? Это может повлиять на вашу производительность
• Однако в большинстве случаев диаграмма будет показывать несоответствия между задуманным вами дизайном и фактической реализацией.

Кроме того, диаграммы отлично подходят для передачи и документирования вашего дизайна, как нетехническим людям, так и людям, которые являются новичками в вашем проекте - и помните, что через 6 месяцев вы тоже практически новичок в проекте!

То, как вы используете UML, должно основываться на этих соображениях. Диаграмма для себя? Используйте любые обозначения, которые вам наиболее удобны. Сотрудничаете с другими разработчиками? Попробуйте включить детали вызовов API, типы сообщений, направления зависимостей. Обсуждать архитектуру? Черных ящиков и простых подключений хватит. В любом случае , никто не использует полный набор функций UML , и он очень полезен как набор стандартизированных обозначений, которые понимают многие, в то время как мои рисунки на салфетках могут быть непонятны для вас, и наоборот.

Что касается меня, я все время использую диаграммы - простые блокнотные рисунки для личных проектов, простые UML-диаграммы в работе. Эта UML-диаграмма - это то, что я считаю слишком сложной, и которую я никогда не буду делать, потому что стоимость ее создания и обслуживания превышает ее выгоду, но, конечно, YMMV.

Я бы сказал, что есть два типа диаграмм. Формальные диаграммы и каракули.

Что касается формальных диаграмм, я делаю их, когда работаю с другими программистами, но я редко делаю это, когда я программирую один.

Однако это не значит, что я сижу и пишу все, что приходит на ум. На мой взгляд, самое важное при программировании (или вообще что-то в жизни) - это думать сначала, а делать потом .

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

Не беспокойтесь, если вы слишком долго думаете. Я думаю, что хороший баланс достигается, когда вы посвящаете 90% своего времени мышлению и 10% кодированию. Я встречал несколько «старших» программистов, которые живут тем, что «у нас нет времени думать, просто делать». Но даже если они называют свой код «выполнено» раньше, чем те, кто действительно уделяет время тому, чтобы подумать о том, что они делают, они (или оставшиеся после этого несчастливые души) тратят бесчисленные часы на исправление и исправление того, что должно было быть правильно построено. с самого начала.

Лучше всего то, что мышление свободно! вам не нужно сидеть за компьютером, чтобы думать. Вы можете думать о коде, пока вы едите, ездите на работу, тренируетесь ... На самом деле, лучшие идеи приходят, когда вы меньше всего их ожидаете, поэтому всегда держите ваш разум открытым и начинайте кодировать только тогда, когда вы действительно знаете, что вам нужно. собираешься кодировать.

Вот статья, с которой я согласен.

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

Есть три основных преимущества использования вольных / рукописных диаграмм по сравнению с предварительно упакованными инструментами:

1. Вы не обязаны соблюдать тип диаграммы, поддерживаемый любым выбранным вами инструментом. Иногда mapminds будет работать, иногда что-то более похожее на UML будет хорошо, в то время как в других случаях будет работать логическая диаграмма. В других случаях работает полностью настраиваемая диаграмма, и ни один инструмент не может дать вам всю гибкость диаграмм вольного стиля (попробуйте пробить дыру в бумаге и продолжайте на обратной стороне бумаги в вашей любимой упаковке и посмотрите, что получится)

2. На самом деле вы будете тратить больше времени на создание диаграмм, чем на использование инструмента. Независимо от инструмента, перо и бумага всегда быстрее при построении диаграмм, чем при работе с клавиатурой и перемещении по меню, чтобы найти нужные вам элементы.

3. Вам не нужен компьютер, чтобы писать от руки. Большую часть времени я делаю сложные проекты, я делаю их в библиотеке, кафе или даже в самолете. Кроме того, хорошие идеи всегда появляются в самый неподходящий момент, поэтому всегда имейте при себе что-то, на чем можно писать, и что-то, на чем можно писать.

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

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

Йорис Дорманс и Эрнест Адамс обсудили систему игрового дизайна / построения баланса в игре Machination . (Вот видео с оплаченным хранилищем GDC Vault из GDC EU 2012; примеры из GDC 2013 в вики Dormans.) Вместо того, чтобы перефразировать, вот как вики описывает систему:

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

Ной Фальштейн выступил с докладом под названием «Чародейское искусство диаграмм зависимостей головоломки» (платное видео GDC Vault ). Я не могу найти ни одной неоплачиваемой ссылки здесь, но разные люди обсуждали или размещали свои заметки в Интернете.

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

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

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Я также могу указать вам на мою собственную работу по этому вопросу, в большей степени основанную на экономике цикла игры, использующую абстрактные ресурсы для отслеживания таких вещей, как возможности, удача или подготовка:

http://www.stephanebura.com/diagrams/

Если вы находите этот подход полезным, вам следует взглянуть на Machination Joris Dormans, инструмент для создания таких диаграмм и запуска их моделирования:

http://www.jorisdormans.nl/machinations/

Весь его процесс объясняется в его книге:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/