Чи використовуєте ви насправді схеми для моделювання ігор? [зачинено]

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

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

Редагувати: я забув одну важливу річ - чи створюєте ви діаграми до або після впровадження матеріалів? Що я маю на увазі - коли хтось розробляє та впроваджує щось, про що зазвичай змінюється думка, або виникає щось несподіване, і потрібно вносити зміни, іноді основні - і робити їх у вже складних діаграмах здається настільки ж безнадійним, як і в самому коді.

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

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

Щоб навести кілька прикладів, це насправді карта успадкування класів (та, яка була вирізана) в моїй грі, де Interactive Object є базовим типом.

Це діаграма FSM ( машина з кінцевим станом ) для пастки шипів (ті дивовижні пастки, на які ви наступаєте, і шипи, що виникають з-під землі, з’являються із землі).

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

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

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

Зразок для шипової пастки, який я намалював зараз, виглядатиме так:

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

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

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

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

Діаграми класів, коли ієрархія спадкування стає досить складною

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

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

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

Навігаючись у новому місті, ви насправді зупиняєтесь і дивитесь на карту, а не просто продовжуєте та слідуєте за знаками? Ось що стосується дизайну проти кодування. Коли речі незнайомі, коли проблема складна, коли ти відчуваєш себе втраченим, саме тоді думка про дизайн є найбільш корисною, і краще це робити раніше, ніж пізніше. Набагато простіше змінити дизайн, перш ніж щось реалізувати .

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

• Забагато підключень до одного компонента? У вас може бути об’єкт бога, який важко підтримувати
• Занадто багато взаємозв'язків? Можливо, модульність можна вдосконалити, щоб зробити архітектуру менш тендітною
• Забагато шляхів між двома компонентами? Можливо, у вас щільна муфта
• Для високопродуктивних додатків, таких як ігри, чи занадто багато компонентів, задіяних у гарячому контурі чи внутрішньому циклі? Це може вплинути на вашу ефективність
• Однак більшу частину часу діаграма показуватиме невідповідність між задуманим вами дизайном та фактичною реалізацією

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

Як ви користуєтесь UML, слід випливати з цих міркувань. Діаграмування заради себе? Використовуйте будь-які позначення, які вам найбільше подобаються. Співпраця з іншими розробниками? Спробуйте включити деталі викликів API, типи повідомлень, напрямки залежностей. Обговорюють архітектуру? Чорних коробок і простих підключень буде достатньо. Ні в якому разі ніхто не використовує повний набір функцій UML , плюс це дуже корисно як набір стандартизованих позначень, які розуміють багато людей - тоді як мої серветки з серветками можуть бути незрозумілі для вас і навпаки.

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

Я б сказав, що є два типи діаграм. Офіційні діаграми та писанки.

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

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

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

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

Найкраще, що мислення - вільне! не потрібно сидіти за комп’ютером, щоб думати. Ви можете думати про код, коли ви їсте, їздили на маршруті, вправлялися ... Насправді найкращі ідеї приходять тоді, коли ви їх найменше очікуєте, тому постійно тримайте розум відкритим і почніть кодувати лише тоді, коли ви дійсно знаєте, що ви збираюся кодувати.

Ось пов’язана стаття, з якою я погоджуюся.

Редагувати : Що стосується фактичного формату та типу діаграм, то я рекомендую вам перейти у вільний стиль, а власне рукописний текст замість використання попередньо упакованих інструментів. Пам’ятайте, що справа полягає у тому, щоб допомогти вам у вашому розумовому процесі, тому сміливо малюйте все, що завгодно. Семантика - це все, що вам подобається, і вони можуть бути різними між діаграмами і навіть між різними частинами діаграми.

Існує три основні переваги щодо діаграм вільного стилю / рукописних тексту над пакетами:

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

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

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

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

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

Джоріс Dormans і Ернест Адамс обговорили підступи дизайну ігрового балансу системи / діаграми. (Ось відеозапис про GDC Vault від GDC EU 2012; зразки з GDC 2013 на вікі Dormans.) Замість того , щоб намагатися парафраз, ось як вікі описує систему:

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

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

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

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

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

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

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

Якщо ви вважаєте цей підхід корисним, вам слід ознайомитись з машинами Джорріса Дорманса, інструментом для створення таких діаграм та проведення їх моделювання:

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

Весь його процес пояснений у його книзі:

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