Планирование игр и разработка программного обеспечения? Я чувствую, что UML не удобен


21

В моем университете они всегда подчеркивают и рекламируют UML-дизайн и другие вещи, в которых я чувствую, что это не будет хорошо работать с дизайном игровой структуры. Теперь я просто хочу получить профессиональный совет, как начать разработку игры? История в том, что у меня есть некоторый навык в программировании, и я сделал много второстепенных игр, таких как работа над 2D-платформером. Проблемы, с которыми я сталкиваюсь в своей программе, это плохое качество дизайна. После некоторого кодирования вещи начинают ломаться из-за плохого планирования (когда я добавляю новую функцию, это заставляет меня перекодировать всю программу). Тем не менее, планировать все без единого недостатка дизайна слишком идеально. Поэтому, какой совет, как мне планировать свою игру? Как я должен поместить это в видимые картины, чтобы я и мои друзья могли просматривать проекты?

Я планировал начать писать игру со своим другом. Это будет моя первая командная работа, поэтому любые профессиональные советы будут приятны. Есть ли другие альтернативы, кроме UML?

Другой вопрос, как обычно выглядит «прототипирование»?


26
UML это фигня. Это плохо продуманная парадигма, заставляющая бизнесменов чувствовать, что они что-то производят и понимают, а на самом деле создают только бесполезные ограничения.
о0 '.

Хотя я определенно считаю, что UML имеет место в программном обеспечении для бизнеса, он не предназначен для разработки чего-то слишком интерактивного. Попытайтесь найти некоторые документы по дизайну игр для существующих игр, чтобы увидеть, как они справляются с формальными вещами, что-то вроде этого: delta3d.org/filemgmt_data/files/… также постарайтесь не забывать делать много прототипов и не бояться «выбрасывать» вещи (здесь выбрасывать означает полку в вашей системе контроля версий, а не активное ее использование).
Рой Т.

4
Я использую xmind для планирования всего. Я бы не стал использовать такие технические вещи, как UML, если бы меня не заставили. Важно визуализировать вещи, прежде чем перейти к технической. Картография разума - твой друг. Вы можете использовать его для планирования технических вещей тоже.
Он Шиминг

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

Ответы:


18

Я просто хочу получить профессиональный совет о том, как начать разработку игры?

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

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

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

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

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

Похоже, вы смешиваете 2 задачи: дизайн игры и дизайн кода.

Я предлагаю сначала написать базовый игровой дизайн, указав необходимые вам функции, графику и звуки, которые вам нужны, как выиграть и проиграть игру и т. Д. Посмотрите «проектные документы», если вам нужна помощь.

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

Кроме того, попробуйте поработать над небольшими, менее амбициозными проектами. Это позволит вам привыкнуть к написанию хорошего, работающего кода без необходимости тщательного планирования или переписывания.


Я думаю, я перепутал это. Я думаю, что могу сказать, что у меня действительно есть некоторые грубые идеи игровой системы. Тем не менее, я хотел бы знать, как я могу эффективно решить мою проблему разработки «кода»? Или, другими словами, эффективно перевести мою игровую структуру в код? Я обычно вынужден выбирать между продолжительным обобщением кода или быстрым конкретным кодированием. Обычно первый
выводил

2
Похоже, вы все еще неопытны с программным моделированием (моделирование - это процесс перевода абстрактного дизайна в конкретную реализацию). Я боюсь, что это будет только лучше с опытом. Хороший способ проверить, добились ли вы прогресса, - это время от времени просматривать ваш 6-месячный код. Если вы не найдете ничего, что написали бы по-другому (или просто лучше), если переписали эту вещь, то вы, вероятно, не улучшились за это время.
TravisG

Согласитесь с heishe - опыт - единственное реальное решение здесь, в сочетании с обучением, чтобы учесть опыт. Попытайтесь прочитать и понять основные понятия, такие как инкапсуляция и абстракция, более сложные, такие как Закон Деметры и Принцип Единой Ответственности, и понять Шаблоны проектирования достаточно хорошо, чтобы понять, где некоторые из них могут вам помочь. Эти знания в сочетании с практикой дают вам инструменты для воплощения идей в рабочий код.
Kylotan

2

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

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

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

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

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


2

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

  1. Если ваши идеи грубы, попробуйте реализовать их по одному в супер крошечных проектах прототипирования. Например, сейчас я делаю 2D-игру на платформе, и для меня очень важно правильно прыгнуть. Итак, я создал новый проект, в котором происходят только 2 вещи: а) рисование игрока на экране и б) обнаружение ввода и перерисовка прыжка [персонаж не может даже двигаться влево или вправо]
  2. Некоторые люди могут не одобрить этот совет, но сначала подумайте о написании руководства по игре (для объяснения концепций, элементов управления, целей). Это может сделать 2 вещи для вас - создать очень необходимый документ, а также обрисовать подсистемы вашей игры и любые необходимые детали для игрока. Если вы заранее знаете, что игрок должен знать, тогда вы заранее знаете, что нужно делать.
  3. Пишите код достаточно маленькими (то есть модульными ) частями, чтобы разложенные кусочки можно было перемещать или лучше организовывать, не чувствуя, что вы пытаетесь удалить все кусочки спагетти среднего размера из тарелки макарон.

Надеюсь, вы нашли там хотя бы одну полезную информацию, и удачи!


1

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

UML - это «стандартный способ визуализации архитектуры системы»

UML описывает

  • деятельность
  • актеры
  • деловые процессы
  • схемы базы данных
  • (логические) компоненты
  • утверждения языка программирования
  • повторно используемые программные компоненты

Но если вы делаете простую игру, вам действительно нужно смоделировать все это?

  • Актеры: игрок.

Насколько это помогает?

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

Таким образом, хотя UML отлично работает (знайте, что вы делаете, запишите требования и нарисуйте схемы блок-схем там, где это необходимо), и элементы этого очень полезны, но я склонен считать, что весь процесс UML немного квадратного колышка вокруг отверстия для игр.


1
Актеры: дизайнеры, художники, сетевые игроки, (если вам повезет) финансовые спонсоры, люди. Общение между дизайнерами, разработчиками, клиентами, конечными пользователями и программистами в лучшем случае ужасно в каждой отрасли индустрии программного обеспечения, которую я видел. UML - это инструмент, который дает заинтересованному лицу общий язык для обсуждения проекта. В мире разработки существует определенная степень враждебности по отношению к таким вещам, как документация (программисты) и контроль исходного кода / совместная работа (дизайнеры), которые действительно снижают качество конечного проекта. Большинство из этих вещей построены командами, поэтому мы должны поделиться.
Синтия V

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

Как насчет редакторов уровней / ресурсов и движков? Это был тот случай использования, о котором я говорил.
Синтия V

0

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

  • название
  • требования
  • предпосылки
  • триггеры
  • действия
  • альтернативные действия
  • исключения

может быть весьма полезным. хотя то, что вы найдете для «Использовать случаи», если вы делаете поиск в Интернете (фотографии) больше для общего программного обеспечения.

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

все сводится к тому, что ваш набор функций должен быть спланирован и заблокирован как int (арендованный в настройке потребности / желания) перед моделированием, и даже начнется построение диаграмм. все они должны быть в вашем Brief / Treatment / Script (иногда упоминаются как подача, документ с описанием функций и рассказ). затем оттуда вы будете делать свои технические документы, в которых есть ваши модели и диаграммы.

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


0

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

Как и любое обсуждение языка, инструментов или дизайна - обычно все сводится к тому, как ВЫ его используете. Выберите лучший инструмент / язык / дизайн для работы и подкрепите свой выбор убедительным обоснованием. Я признаю, что UML не настолько гибок для производства игр, хотя я могу сказать, что мы эффективно использовали его для моделирования функций движка, таких как сетевые коммуникации и синхронизация, параллельное управление задачами и варианты использования. Нет ничего хуже, чем объяснять одно и то же 5 разным членам команды 10 раз, потому что они этого не понимают. Вот документация, читай.

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

Несмотря на это, вы, вероятно, услышите (и сурово поймете), что это ЖИВЫЕ ДОКУМЕНТЫ, и если они не будут регулярно пересматриваться и обновляться, они быстро устареют и станут бесполезными.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.