Чи можу я використовувати функцію повзучості на свою користь? [зачинено]

Чи можу я використовувати функцію повзучості на свою користь?

Кожного разу, коли я прототипую гру, функції мимоволі додаються. Це відбувається або за збігом обставин, або легко додати на основі наявного контенту.

Якщо я знаю жанр гри, чи можу я просто почати створювати основні механізми та додавати функції, коли вони стануть очевидними?

Наприклад, якщо я хочу зробити 2d платформер протягом 6 місяців, чи можу я просто почати робити біг, стрибки, стрілянину тощо і додати основну механіку, коли я випадково їх знайду? Або це занадто ризиковано за часом інвестування без заздалегідь визначеного плану?

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

Підсумовуючи, чи є щось погано в тому, щоб створити гру, перш ніж я її розробив?

Це цікаве питання. Головним чином, тому, що відповідати на нього, виникають дилеми сірого відтінку проти чорно-білого.

чи є щось не так у створенні гри, перш ніж я її розробити?

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

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

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

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

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

Наприклад, якщо я хочу зробити 2d платформер протягом 6 місяців, чи можу я просто почати робити біг, стрибки, стрілянину тощо і додати основну механіку, коли я випадково їх знайду? Або це занадто ризиковано за часом інвестування без заздалегідь визначеного плану?

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

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

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

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

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

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

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

Це, в основному, почуття, висловлені в розмові під назвою Advanced Prototyping від Chris Hecker та Хаїма Гінгольда, яка включає багато прикладів їх роботи над Spore, де вони часто дивувались тому, що працювало, а що ні, не пішовши, як переробляти ціле системи на основі прототипу зворотного зв'язку.

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

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

Я б сказав так, іди. Але плануйте деякі загальні риси / класи достроково, щоб мати певну згуртованість між кожним новим компонентом.

Єдність відома своїм компонентним підходом до розвитку ігор, і дозволила б легко створити таку форму розвитку. Якщо ви не використовуєте Unity, ви можете повторити напівкомпонентний підхід. Мені незнайомі інші ігрові двигуни.

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

Візьмемо, наприклад, компонент "Стрибок". Дозвольте всій логіці працювати з класом перетворення об’єкта ігрового об'єкта, щоб зробити маніпулювання положенням. (Або у вашого двигуна вже буде подібний вбудований у класі.) Ви можете приєднати цей клас 'Jump' до будь-якого об’єкта, і клас буде оживляти позицію перетворення, коли спрацьовує дія (Jump.PerformJump () або будь-яке інше). Клас Jump не повинен нічого знати про свого власника (або, принаймні, мінімальної інформації).

Тепер ви можете весело створювати тону компонентів, потім приєднуючи їх до ігрових об’єктів, комбінуючи їх на одному об’єкті тощо. Наприклад: Run, Jump, Crouch, MovingTile, FireWeapon (вкажіть спрайт 'bullet' та поведінку, яку потрібно зробити родовий компонент) тощо.

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

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

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

Про відсутність початкового дизайну (просто ескіз чи ментальний образ): якщо у вас немає дизайну, у вас немає дизайну. Ви повинні зробити щось, щоб прийти з одним. Але поки ви почнете його будувати, намагайтеся його поважати, не приходьте з новим кожен раз.

Експериментування та отримання випадкових ознак можуть чи не бути шкідливими. Це може бути навіть корисним або неминучим. Наприклад: ви знаєте, що хочете підтримувати стрибки (багато 3D / 2D RPG не дозволяють стрибати). Звідки ти це знаєш? Тому що ви уявляли ігрову карту, яка потребує стрибків, щоб сортувати перешкоду? Тож реалізація стрибків досить хороша до тих пір, поки вона дозволяє гравцеві сортувати цю перешкоду чи вона повинна відповідати певним характеристикам, таким як максимальна досяжна висота, чи можна її підсилити предметами чи ігровими об'єктами на карті, фізика повинна включати прискорення або відскок ( коли Маріо стрибає в ворога, він знову отримує імпульс, щоб піднятись, і що дуже важливо для гри)?

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

Я розумію, що нормально переходити до коду без завершеного дизайну, якщо ви поважаєте те, що вже вирішено. Крім того, це може бути неминучим у деяких ситуаціях, оскільки ігрові всесвіти можуть будуватися з безлічі різних процесів мислення. Наприклад, карткова гра: я знаю, що я хочу, щоб картки мали атаку та захист, певну кількість карт у таблиці в даний момент часу і що гравець під час своєї черги може вибрати, з якою карткою атакувати, яку іншу карту. Для деяких це може виглядати вже як повноцінна конструкція, але тоді настає балансування гри, можливе лише за допомогою багатьох моделей. Після багатьох симуляцій я вирішую, що карта з Attack 10 перевантажена, я можу просто видалити її з гри, але мені це дуже подобається, тому я зроблю щось інше, Я створять нове правило, яке говорить, що якщо гравець атакує таку карту, він не може атакувати з іншою карткою під час цього повороту. Зараз у мене є нове правило, яке збагачує ігрову механіку, але застосувати її до однієї карти виглядає дивно (як брудне злом), я розумію, що це виглядає дивно, і тоді я вирішую створити новий набір карт, які мають велику кількість, але до них застосовується нове обмежувальне правило. Тепер у мене є складніший ігровий механік, побудований над більш простим оригінальним, на мою думку, я перетворив це на свою користь, щоб зробити кращу гру.

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

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

Коли хтось ще за це платить: поясніть, домовляйтеся.