Могу ли я использовать функцию Creep в свою пользу? [закрыто]

Могу ли я использовать функцию Creep в свою пользу?

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

Если я знаю жанр игры, могу ли я просто начать создавать базовую механику и добавлять новые функции по мере их появления?

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

Моя логика заключается в том, что дизайн будет более выгодным. Выбор дизайна будет легче строиться вокруг того, что легко сделать (в зависимости от времени).

Подводя итог, можно сказать , что что-то не так с созданием игры до ее создания?

Это интересный вопрос. Главным образом потому, что ответ на него поднимает оттенки серого по сравнению с черно-белой дилеммой.

Что-то не так с созданием игры до того, как я ее создаю?

Если вы считаете этот вопрос типом «да» или «нет», ответ может быть только один: да, есть. Если ответ может быть более нюансированным, то он меняется. Причина: вы никогда не должны создавать игру до некоторого проектирования. Но вы уверены, что можете сохранить части дизайна на потом.

Это означает, что я не думаю, что вы должны рассматривать проблему под рукой, как что-то или нет. Скорее, это то, что вы должны думать о градусах. Ползучая черта, возможно, самый второй корень всего зла в том, что касается разработки игр (первое, как Дональд Кнут изобрел нас, это то, что «преждевременная оптимизация - это корень всего зла»). ). Однако, по моему опыту, не думать о каких-либо основных особенностях, то есть не иметь хотя бы базового дизайна, в котором вы хотите использовать свою базовую механику, тоже не очень хорошая идея.

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

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

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

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

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

Не потому, что вы знаете, что игра будет 2D-платформой, бег, прыжки или стрельба не могут варьироваться в зависимости от дизайна игры. Может ли ваш игрок бегать по стенам? Может ли ваш игрок парить в воздухе при прыжках? Даже, может ли ваш игрок стрелять во время бега? Ваш игрок стреляет только в линейном направлении или через параболу? Эти решения могут сильно зависеть от игровых особенностей.

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

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

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

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

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

Это в основном чувство, выраженное в докладе под названием Advanced Prototyping Крисом Хеккером и Хаимом Гингольдом , которое включает в себя множество примеров из их работы над Spore, где они часто удивлялись тому, что работало, а что - нет, вплоть до редизайна целого. системы на основе обратной связи с прототипом.

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

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

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

Unity известна своим компонентным подходом к разработке игр, и она позволит легко использовать эту форму разработки. Если вы не используете Unity, вы можете повторить полукомпонентный подход. Я не знаком с другими игровыми движками.

Все игровые объекты Unity имеют компонент преобразования. Здесь указывается положение, вращение и масштаб объекта. Поэтому создайте общий класс 'transform' для хранения этих значений, а также, возможно, ссылки на реальный игровой объект.

Возьмите, например, компонент «Прыжок». Пусть вся логика будет работать с классом преобразования игрового объекта для манипулирования позицией. (Или ваш движок уже будет иметь подобный встроенный класс.) Вы можете присоединить этот класс 'Jump' к любому объекту, и этот класс будет анимировать позицию преобразования при запуске действия (Jump.PerformJump () или что-то еще). Класс Jump не должен ничего знать о своем владельце (или, по крайней мере, минимальной информации).

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

Сделайте каждый компонент как можно более универсальным, чтобы можно было использовать его несколько раз. Для FireWeapon вы можете указать спрайт пули, скорость, урон и т. Д. Можно попытаться нормализовать эти атрибуты, чтобы скорость и урон задавались в диапазоне от 0 до 1. Затем масштабируйте их до максимальных значений игры. Таким образом, вы беспокоитесь только об относительных различиях между оружием. Кроме того, он адаптируется к глобальным настройкам, таким как сложность, где большая сложность имеет больший максимальный урон и т. Д.

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

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

Об отсутствии первоначального дизайна (просто эскиз или мысленный образ): если у вас нет дизайна, у вас нет дизайна. Вы должны сделать что-то, чтобы прийти с одним. Но пока вы начинаете его строить, старайтесь уважать его, не приходите с новым каждый раз.

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

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

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

Теперь одна вещь о последнем примере, в предложенном примере карточной игры, новые карты могут привести к новым активам (увеличение стоимости, увеличение времени). Но я думаю, что это хороший пример того, как возможности, которые вы видите, только когда кодирование оказывает хорошее влияние на ваши дизайнерские решения.

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

Когда кто-то еще платит за все это: объясните, договоритесь.