Планування ігор та дизайн програмного забезпечення? Я вважаю, що UML - це не зручно

У моєму університеті вони завжди підкреслюють та наполягають на дизайні та інших предметах UML, і я вважаю, що це не буде добре працювати з дизайном структури ігор. Тепер я просто хочу професійну пораду щодо того, як мені почати розробляти ігри? Історія полягає в тому, що я маю певні навички програмування і зробив багато незначних ігор, таких як набуття якогось 2D-платформера, якийсь працював. Проблеми, які я знаходжу щодо своєї програми, - це неякісний дизайн. Після кодування на деякий час все починає руйнуватися через погане планування (Коли я додаю нову функцію, це, як правило, змушує мене перекодувати всю програму). Однак планувати все без єдиного дизайнерського недоліку - це занадто ідеально. Тому будь-яка порада, як мені планувати свою гру? Як я повинен розміщувати його на видимих ​​картинках, щоб я та мої друзі могли переглянути дизайн?

Я планував розпочати кодування гри зі своїм другом. Це буде моєю першою командною роботою, тому будь-які професійні поради будуть задоволенням. Чи є інші альтернативи, крім UML?

Інше питання - як зазвичай виглядає "прототипування"?

Я просто хочу професійну пораду щодо того, як мені почати розробляти ігри?

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

Що стосується розробки коду для реалізації цих систем, UML є хорошим інструментом для виконання завдання, надаючи команді це знати і дотримуйтесь більш поширених типів діаграм. Зазвичай, намагаючись розробити функцію, ви дізнаєтесь, чи потрібно використовувати опис або діаграму. Якщо вам потрібно використовувати діаграму, UML дає вам стандартний спосіб її малювання, що добре.

Після кодування на деякий час все починає руйнуватися через погане планування (Коли я додаю нову функцію, це, як правило, змушує мене перекодувати всю програму).

Це, як правило, проблема в тому, як ви програмуєте, а не в тому, як ви плануєте. Гарне програмне забезпечення, як правило, легко розширити і використовувати повторно. Якщо ви будете дотримуватися належної практики програмування, ця проблема зменшиться. Але також допоможе краще планування, і для цього вам не потрібні складні схеми. Якщо мати список функцій, це означає, що коли ви кодуєте одне, ви маєте на увазі інші функції та можете розглядати їх як кодування.

Тому будь-яка порада, як мені планувати свою гру? Як я повинен розміщувати його на видимих ​​картинках, щоб я та мої друзі могли переглянути дизайн?

Здається, ви змішуєте тут дві проблеми, дизайн гри та дизайн коду.

Я пропоную спершу виписати базовий дизайн гри, вказавши необхідні функції, графіку та звуки, які вам потрібні, як гра виграна та програна тощо. Знайдіть «конструкторські документи», якщо вам потрібна допомога там.

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

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

Якщо щось не зрозуміти, це легко звільнити. UML - це інженерний інструмент, який використовується для структурованого спілкування ваших ідей. Гра - це система, яку можна сконструювати як будь-яку іншу. У будь-якому разі, складність і динамізм гри робить візуальне зображення її частин та їх взаємодій неоціненними.

Діаграми UML - це різні погляди моделі обговорюваної системи. Я починаю з випадків використання для людини, яка сідає перед моєю програмою і починає її. У випадку з грою є два види користувачів: дизайнери та гравці. Я пишу випадок використання для кожної речі, яку я бачу, як вони роблять. Потім я роблю кілька карток CRC, щоб зрозуміти, які послуги мені потрібно надати. Тоді я складаю діаграму класів для інтерфейсів, які забезпечуватимуть ці послуги та їх взаємозв'язки. Це засновано на картах CRC. Далі йдуть динамічні діаграми для таких подій, як ініціалізація, які потребують планування та впорядкування. Потім більш детальні статичні діаграми, що показують класи, що реалізують інтерфейси.

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

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

Існує багато різних методологій, але всі вони визначають проблему і систематично описують одне рішення. Це інженерія. UML є величезним і складним, але жодна модель не використовує кожну конструкцію. Це як ніж швейцарський армійський ніж. Ви повинні ознайомитись з цим і розібратися, як його використовувати для підтримки вашого інженерного процесу. Важливо не те, який процес чи методологію, а в тому, що у вас є. Інакше ви втонетеся в складності.

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

1. Якщо ваші ідеї грубі, спробуйте впроваджувати їх по черзі у надзвичайно крихітних проектах по прототипуванню. Наприклад, я зараз роблю гру в 2D платформу, і правильний стрибок гравця вкрай важливий для мене. Отже, я створив новий проект, в якому відбуваються лише 2 речі: а) малювання гравця на екрані; б) виявлення вводу та перемальовування стрибка [персонаж не може навіть рухатися ліворуч або праворуч]
2. Деякі люди можуть нахмуритися на цю пораду, але подумайте над тим, щоб написати посібник з ігор (щоб пояснити поняття, елементи управління, цілі). Це може зробити для вас дві речі - створити дуже потрібний документ, а також окреслити підсистеми вашої гри та будь-які необхідні деталі для гравця. Якщо ви знаєте заздалегідь, що повинен знати гравець, то ви знаєте заздалегідь, що вам потрібно зробити.
3. Напишіть код достатньо невеликими (також модульованими ) шматками, які факторними елементами можна або переміщати, або краще організовувати, не відчуваючи, що ви намагаєтесь вийняти з тарілки макарони всі шматочки середнього розміру спагетті.

Сподіваємось, ви знайшли там хоча б одну корисну інформацію та удачі!

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

UML - це "стандартний спосіб візуалізації архітектури системи"

UML описує

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

Але якщо ви робите просту гру, чи справді вам потрібно все це моделювати?

• Актори: Гравець.

Наскільки це допомагає?

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

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

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

• ім'я
• вимоги
• передумови
• тригери
• дії
• чергування дій
• винятки

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

Я б також поставив деяку кредитну схему класу. це показує, що ви здатні показати взаємозв'язок між усіма вашими об'єктами, і що ви знаєте компонування вашої архітектури.

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

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

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

Як і будь-яка дискусія щодо мови, інструментів чи дизайну - зазвичай зводиться до того, як ВИ використовуєте. Оберіть найкращий інструмент / мову / дизайн для роботи та підкріпіть свій вибір із твердим обгрунтуванням. Я визнаю, UML не настільки гнучка для виробництва ігор, хоча можу сказати, що ми ефективно використовували її для моделювання функцій двигуна, таких як мережеві комунікації та таймінг, паралельне управління завданнями та випадки використання. Немає нічого гіршого, ніж пояснити одне і те ж саме 5 різним членам команди 10 різних часів, тому що вони не дуже розуміють це. Ось документація, читайте її.

Залежно від того, наскільки міцні ви дизайни та наскільки дисциплінована ваша команда, може бути досить продуктивним вміти моделювати власні конструкції навколо тих, які ще не були розпочаті, та ще точно знати, як вони працюватимуть завдяки документація.

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