Treasure Gobblin'

Элементы управления: Движение: клавиши со стрелками, Бег: пробел (если у вас достаточно выносливости), Пауза: выход ** К сожалению, есть ошибка с FMOD Audio в WebGL, поэтому регулировка громкости не будет работать в веб-версии ** Блог разработчиков Treasure Gobblin' Обзор игры и мотивация разработки

Treasure Gobblin' — это бесконечная аркадная игра, разработанная тремя людьми. Я (Кайл Уэлфэр) занимался программированием на Unity/C#, искусством занимался Скотт Уэлфэр, а музыку — Брэндин Кэмпбелл.

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

На создание этой игры нас вдохновила в первую очередь образовательная цель. Он не разрабатывался с намерением когда-либо опубликовать его, но служил двойной цели: позволить нам освоить множество новых навыков, связанных с разработкой игр, и действовать как завершенный проект для наших соответствующих портфолио. Сохраняя масштаб небольшим, мы знали, что это достижимо и позволит нам отшлифовать его до уровня, который нас устроит. Для нашей первоначальной идеи мы просмотрели некоторые прошлые темы геймджемов Ludum Dare (популярное ежегодное соревнование геймджемов) и выбрали две темы в качестве основы для нашей игры: «Башня» и «Вся игра на одном экране».< /p>

По мере развития идеи мы остановились на такой смене ролей, когда персонаж игрока — «плохой парень».', а враги - типичные 'герои' , которыми обычно управляет игрок. Если вы когда-либо играли в Diablo, этот сценарий выбивания золота из гоблина может быть вам знаком!

Интересные места программирования и точки обучения

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

Первой из этих возможностей было использование системы объединения объектов для различных повторно используемых активов в игре. Для тех, кто не знаком с объединением объектов в контексте разработки игр, это процесс повторного использования игровых объектов посредством активации/деактивации. Постоянное создание и уничтожение объектов сказывается на производительности в течение длительных игровых сессий. Благодаря объединению объектов нам всегда нужно создавать максимальное количество объектов, которые будут отображаться на экране в любой момент времени. Реально для этой игры требования к производительности очень низкие, и если игрок не использует Windows 98, он, скорее всего, не столкнется с каким-либо замедлением. Тем не менее, это был отличный шанс получить такпопрактиковаться в реализации этой концепции. Некоторые примеры того, где эта техника может быть очень полезной, — это снаряды в пуленепробиваемой игре или волны врагов в защите башни.

В нашей игре и враги, и монеты, которые они сбросили, объединяются для повторного использования. Я использовал систему объединения объектов, показанную в этом видео от One Wheel Studio, модифицированную для моих нужд. Используя Dictionary для хранения GameObjects со строковыми ключами, я смог создать динамическую систему объединения объектов, которая может учитывать любые объекты, которые я могу объединить. Размер пула также является динамическим и будет увеличиваться по мере необходимости, когда на экране одновременно требуется больше игровых объектов. Он использует очередь, систему «первым пришел — первым вышел» для управления активацией и деактивацией игровых объектов. Это также дает возможность выполнить некоторый код как при активации, так и при деактивации объединенного объекта, например создание золотой монеты после смерти врага.

Одной из тем, на изучение и изучение которой я потратил много времени, была концепция тайминга в Unity. Treasure Gobblin' в значительной степени полагается на постоянное время почти для всех аспектов игрового процесса, от лазерных выстрелов до появления врагов и регенерации выносливости. Существует множество способов реализации синхронизированных событий в Unity, и я сосредоточился на трех наиболее распространенных методах: сопрограммах, обратном отсчете с использованием Update() и Invoke(). Я использовал смесь этих методов, чтобы создать игровой цикл Treasure Gobblin', чтобы попрактиковаться в каждом из них. В коммерческом продукте это wВероятно, было бы разумно придерживаться единого метода для всех рассчитанных по времени событий в игре. В большинстве документов Unity рекомендуется использовать сопрограммы, однако многие разработчики игр предупреждают об опасностях использования сопрограмм, главным образом из-за нестабильности и сложности кода. Используя ручные счетчики с плавающей запятой в Update(), код будет гораздо менее подвержен ошибкам, но ваши таймеры станут зависимыми от кадров. В такой игре замедление работы пользователей маловероятно, поэтому для моей игры это, вероятно, лучший метод.

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

Это лишь некоторые из областей, в которых я использовал этот небольшой игровой проект, чтобы учиться и экспериментировать, чтобы в конечном итоге стать лучшим профессионалом.грамматик.

Возможные будущие изменения и прогресс

По мере разработки Treasure Gobblin' я все больше и больше чувствовал, что чего-то не хватает. Каждый раз, когда я получал работающую функцию и тестировал ее, я чувствовал, что надвигается проблема: игра была не очень веселой. Несмотря на то, что все функционировало как задумано, геймплея не хватало. К сожалению, в играх, особенно при выборе концепции в формате «геймджема», иногда возникает разрыв между идеей и готовым продуктом.

Я считаю, что самым большим недостатком Treasure Gobblin' является ориентация игровой зоны. Верхняя стена сцены не позволяет игроку использовать верхнюю левую и верхнюю правую зоны лазерного взрыва. Если бы я продолжил разработку этой игры, я бы, скорее всего, превратил игровую зону в круг с башней, расположенной в центре. Это дало бы игроку свободу использовать всю сцену по своему усмотрению, не чувствуя себя ущемленным.

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

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