В моем университете они всегда подчеркивают и рекламируют UML-дизайн и другие вещи, в которых я чувствую, что это не будет хорошо работать с дизайном игровой структуры. Теперь я просто хочу получить профессиональный совет, как начать разработку игры? История в том, что у меня есть некоторый навык в программировании, и я сделал много второстепенных игр, таких как работа над 2D-платформером. Проблемы, с которыми я сталкиваюсь в своей программе, это плохое качество дизайна. После некоторого кодирования вещи начинают ломаться из-за плохого планирования (когда я добавляю новую функцию, это заставляет меня перекодировать всю программу). Тем не менее, планировать все без единого недостатка дизайна слишком идеально. Поэтому, какой совет, как мне планировать свою игру? Как я должен поместить это в видимые картины, чтобы я и мои друзья могли просматривать проекты?
Я планировал начать писать игру со своим другом. Это будет моя первая командная работа, поэтому любые профессиональные советы будут приятны. Есть ли другие альтернативы, кроме UML?
Другой вопрос, как обычно выглядит «прототипирование»?
источник
Ответы:
Дизайн игры - это спецификация игрового процесса, активов, систем подсчета очков и т. Д., Которые не зависят от программного обеспечения. Таким образом, UML - неподходящий инструмент для этой задачи.
Когда речь заходит о разработке кода для реализации этих систем, UML является хорошим инструментом для решения этой задачи, если ваша команда знает об этом и придерживается более распространенных типов диаграмм. Обычно, пытаясь спроектировать функцию, вы будете знать, нужно ли вам использовать описание или диаграмму. Если вам действительно нужно использовать диаграмму, UML предлагает вам стандартный способ ее рисования, что очень хорошо.
Это, как правило, проблема в способе программирования, а не в том, как вы планируете. Хорошее программное обеспечение обычно легко расширять и использовать повторно. Если вы будете придерживаться хороших методов программирования, эта проблема уменьшится. Но лучшее планирование также поможет, и вам не нужны сложные диаграммы для этого. Просто наличие списка функций будет означать, что когда вы кодируете одну вещь, вы имеете в виду другие функции и можете рассматривать их как код.
Похоже, вы смешиваете 2 задачи: дизайн игры и дизайн кода.
Я предлагаю сначала написать базовый игровой дизайн, указав необходимые вам функции, графику и звуки, которые вам нужны, как выиграть и проиграть игру и т. Д. Посмотрите «проектные документы», если вам нужна помощь.
Оттуда у вас будет представление о функциях, которые вам нужно кодировать. Вы можете посмотреть на каждую функцию по очереди и попытаться подумать о том, как их реализовать. Диаграммы могут помочь показать отношения между различными классами и объектами в вашей игре, но умение знать, какие объекты должны существовать, - это то, что вы должны изучить на практике и / или в дальнейшем чтении.
Кроме того, попробуйте поработать над небольшими, менее амбициозными проектами. Это позволит вам привыкнуть к написанию хорошего, работающего кода без необходимости тщательного планирования или переписывания.
источник
Непонимание чего-либо облегчает отклонение. UML - это инженерный инструмент, используемый для структурированного обмена идеями. Игра - это система, которая может быть спроектирована как любая другая. Во всяком случае, сложность и динамичность игры делают визуальное представление ее частей и их взаимодействия бесценным.
Диаграммы UML представляют собой различные представления модели обсуждаемой системы. Я начинаю с вариантов использования для человека, сидящего перед моей программой и запускающего ее. В случае с игрой есть два типа пользователей: дизайнеры и игроки. Я пишу сценарий использования каждой из вещей, которые я вижу, что они делают. Затем я делаю несколько карт CRC, чтобы выяснить, какие услуги мне нужно предоставить. Затем я делаю диаграмму классов для интерфейсов, которые будут предоставлять эти услуги и их отношения. Это основано на картах CRC. Далее идут динамические диаграммы для таких событий, как инициализация, которые требуют планирования и оркестровки. Затем более подробные статические диаграммы, показывающие классы, реализующие интерфейсы.
Все это время я пишу код, создаю прототипы и развиваю его в направлении предоставления услуг для поддержки выполнения требований моей игры. Ничего не создается, что не поддерживает пользователя в сценариях использования. Я пишу некоторые бесполезные элементы диаграммы, но между кодированием интерфейса и диаграммой я пишу очень мало бесполезного кода. Диаграммы дают мне уверенность в том, что я понимаю, как класс, который я пишу, вписывается во всю систему.
Суть, которую я пытаюсь подчеркнуть, заключается в том, что тривиальная программа может быть написана без планов, но игра совсем не тривиальна. Некоторое время назад, когда ООП было новым, было много экспериментов, и некоторые передовые практики вышли на первый план. Сообщество разработчиков программного обеспечения согласилось с тем, что нам нужен язык для написания и анализа проектов программного обеспечения. UML - это язык, который мы разработали. Мы все это знаем и понимаем, поэтому, если вы хотите использовать решения своих проблем других людей (книги, онлайн-обсуждения, статьи, каталоги шаблонов и т. Д.), А не изобретать велосипед, вы должны научиться читать стандартные обозначения. В качестве бонуса, когда вы заставляете себя думать о своей системе на другом языке, вы узнаете неожиданные вещи.
Существует много разных методологий, но все они определяют проблему и систематически описывают одно решение. Это инженерия. UML огромен и сложен, но ни одна модель не использует каждую конструкцию. Это как швейцарский армейский нож. Вы должны узнать это и выяснить, как использовать его для поддержки вашего процесса разработки. Важно не то, какой процесс или методология, а то, что у вас есть. Иначе ты утонешь в сложности.
источник
Я также работаю над некоторыми независимыми игровыми проектами с другом (команда из 2 человек). Как человек, похожий на вашу, я могу предложить несколько интересных моментов, которые я нашел полезными.
Надеюсь, вы нашли там хотя бы одну полезную информацию, и удачи!
источник
Я думаю, что есть некоторые ценные выводы из UML, которые вы не можете отрицать. с другой стороны, имейте в виду, что UML был создан для бизнес-процессов , вы знаете, для моделирования систем, в которых много людей взаимодействуют с ним, все с разными желаниями, потребностями и желаниями. UML старается сделать так, чтобы вы ничего не пропустили и не были перегружены деталями.
UML - это «стандартный способ визуализации архитектуры системы»
UML описывает
Но если вы делаете простую игру, вам действительно нужно смоделировать все это?
Насколько это помогает?
Моделирование некоторых других вещей очень полезно. Например, если вы делаете небольшую MMO, вам определенно нужны хорошо разработанные схемы базы данных.
Таким образом, хотя UML отлично работает (знайте, что вы делаете, запишите требования и нарисуйте схемы блок-схем там, где это необходимо), и элементы этого очень полезны, но я склонен считать, что весь процесс UML немного квадратного колышка вокруг отверстия для игр.
источник
UML - это не единственное, это набор вещей, которые некоторые из них ценят не так сильно, как другие. Сценарии использования старого стиля (по крайней мере, то, что мы называем вариантами использования), в которых говорится
может быть весьма полезным. хотя то, что вы найдете для «Использовать случаи», если вы делаете поиск в Интернете (фотографии) больше для общего программного обеспечения.
Я также хотел бы отдать должное диаграмме классов. это показывает, что вы можете показать взаимосвязь между всеми вашими объектами и что вы знаете макет вашей архитектуры.
все сводится к тому, что ваш набор функций должен быть спланирован и заблокирован как int (арендованный в настройке потребности / желания) перед моделированием, и даже начнется построение диаграмм. все они должны быть в вашем Brief / Treatment / Script (иногда упоминаются как подача, документ с описанием функций и рассказ). затем оттуда вы будете делать свои технические документы, в которых есть ваши модели и диаграммы.
Есть компании, которые используют UML, но обычно это компании, у которых есть отдельные команды разработки и внедрения. компании, которые создадут всю свою документацию, а затем передадут ее команде обезьян для создания прототипа / alpha. Говорят, что если вы сможете точно смоделировать свою игру, вы сможете дать ее совершенно другой команде и заставить ее программировать, хотя это скорее несбыточная мечта, чем точность.
источник
Они будут учить вас UML в вашем университете, чтобы помочь вам донести ваши идеи до остальной части вашей команды и показать лекторам, что вы хорошо разбираетесь в основных принципах разработки программного обеспечения.
Как и любое обсуждение языка, инструментов или дизайна - обычно все сводится к тому, как ВЫ его используете. Выберите лучший инструмент / язык / дизайн для работы и подкрепите свой выбор убедительным обоснованием. Я признаю, что UML не настолько гибок для производства игр, хотя я могу сказать, что мы эффективно использовали его для моделирования функций движка, таких как сетевые коммуникации и синхронизация, параллельное управление задачами и варианты использования. Нет ничего хуже, чем объяснять одно и то же 5 разным членам команды 10 раз, потому что они этого не понимают. Вот документация, читай.
В зависимости от того, насколько надежны ваши проекты и насколько дисциплинирована ваша команда, может оказаться весьма продуктивным иметь возможность моделировать свои собственные конструкции на основе тех, которые еще даже не были начаты, и при этом точно знать, как они будут работать благодаря документация.
Несмотря на это, вы, вероятно, услышите (и сурово поймете), что это ЖИВЫЕ ДОКУМЕНТЫ, и если они не будут регулярно пересматриваться и обновляться, они быстро устареют и станут бесполезными.
источник