Deluxe: Sprint 2

Friday, May 06, 2022

What is this?

I'm working on a game! Currently titled "Deluxe", it's a continuation of the VR Starfox-like I was working on early last year. The on-rails forward motion has been removed and replaced with a player-navigatable space, drawing inspiration from games like Bulk Slash and Geograph Seal.

I'm also trying to keep myself on track by running sprints (~two week dev cycles where I tackle small- to mid-tier tasks in an ever-growing backlog). At the conclusion of each sprint, which neatly coincides with a BGS dev meetup, I'll be presenting results at said meetup and posting a recap of what got done and a peek at what's next. These recaps are broken down by ticket, so each title is the task lifted right from my sprint tracking doc. The content is (mostly) my notes from completion of the ticket.

The Sprint 1 Recap

You might've noticed this is sprint 2, and there's no post for sprint 1 on the blog. I hadn't quite worked out how this was going to function when I started the project, so that post just got skipped. What you missed was basic project setup, some planning, and creation of the core Creature type, which I'll probably put a post together on in the future. For now all you need to know is Creatures are the main elements of the game, from the player ship and enemies to projectiles, destructable objects, item pickups, and pretty much anything else that isn't a static object like most of the game environment.

Now, on to the Sprint 2 progress!

Map out player controls

I took a peek at the Steam Hardware Survey , specifically to see what the currently popular headsets are. Combining that with the Controller mappings note in the issues section of the Godot OpenXR plugin, I came up with a shortlist of the controllers I'd like to target, and from came up with a list of actions I think I'll need for the game and menus. Drafting them up in a doc helps me keep tabs on all the things, and it made bringing it all into Godot's Input Map much easier.

Audio Mixer

This was (so far) shockingly simple. Audio's probably my weakest skillset when it comes to game dev, so I'll likely eat those words later. Anyway, creating an AudioBusLayout is incredibly easy, and appears to have a lot of flexibility. The AudioBusLayout contains AudioBuses , which you can imagine as a bunch of different channels in a mixer. Each AudioBus can get it's own levels and effects, and you can chain AudioBuses into one another to allow for grouping of mixes. In this first pass, the "parent" channels handle Music, UI, and game sound effects (SFX). Ambient sounds for the player and enemies are mixed into a general Ambient mixer, and player/enemy projectiles have their own mixers. Ambient and projectile mixers all pipe into the SFX mixer.

Audio sources on creatures, weapons

Another fairly easy one. Since I'm instancing scenes for creatures and weapons, I just needed to add an AudioStreamPlayer3D to the baseline scene others inherit from, and they all get one. Setting the appropriate AudioBus on the baseline scene means the inheriting scenes get the right channels on the mixer assigned automatically.

Placeholder sound effects

Fun fact: there is a veritable treasure trove of old-skool sample CDs floating around on the Internet Archive. Naturally none of this stuff can be used unless I purchase a license for it, but for testing stuff out and getting some killer classic sound effects/ambient audio? chef's kiss

Seeking projectiles

Creatures, as they currently exist in the game, can use an optional Move_Target Spatial that they'll follow around/move towards at their given speed. I put this in originally because I needed a way for the player ship to fly towards the player's hand. Once I started working on the homing missiles (which double as a simple entry point to some dumb enemy "AI"), I decided to take advantage of the Move_Target as a way to both steer the missile creature and give it something to look at.

Missiles inherit the base creature script and export a Target spatial node path. If assigned, during _physics_process the missile's Move_Target is pushed towards the Target with a given force and moving roughly at the same speed as the missile itself. One problem with this is the missle can catch up with the Move_Target , but it's not such a big problem that the missile stops working. The end result is some simple missile creatures that can, eventually, hit something no matter where they started pointing when they entered the scene. The exported value for Homing_Force allows for easy tweaking.

Baseline destroyed creature scene

Particles baybeeeeeeee! Godot's particle system is really fun to play with, and just throwing a little explosion together with it is a breeze. Add some dynamic scaling to particles and a nice billboarded sprite material, and you've got some fun ka-booms!

Game Manager/Baseline Level scene

This is the one thing that kinda sorta didn't get "completed", because it's still too early to really know what this is. The Game Manager in particular isn't fleshed out fully because I'm undecided on whether I want to use one single Autoload for managing all game state and major functions, or if I want to break it down into several smaller Autoloads that are more focused on a given task. I'm leaning towards the latter.

Also, tracking game state ties into the Baseline Level scene. I've got a basic scene for managing a gameplay level, that can register itself to the current Game Manager implementation and provides helper functions for adding new children to the scene under the appropriate parent nodes (things like projectiles, spawned enemies, and items). In building this out, I realize that I can actually use the level scene itself as the "state" of the game, rather than some external class or enum. It can hold logic for what scene/state to transition to next, keeping things simpler and clearer for me as I add more levels and other scene types.

What's Next

Consolidate Hitboxes and Hurtboxes

Right now creature damage utilizes two separate colliders, a hitbox and a hurtbox. The hurtbox defines damage done to another creature, and scans for hitbox colliders to do said damage. Even when I was first creating it it was getting confusing, so I'm going to try combining them into a singular hitbox for sanity's sake.

Teleportation

Player movement is an absolute must, so this has to get in. I'll need this for things like the Graybox First Level as well, so I can start playing with level scale and navigation comfort.

Grip Swap

Given the nature of ship control in this, I'd like to be able to let the player swap hands on the fly so their arms don't get too tired too quickly.

Graybox First Level

Blocking out a simple stage that the player can teleport around and shoot at things in is basically a step away from a vertical slice. Absolute must to see if the gameplay is actually going to be as potentially fun as I think it'll be.

Navigating NPC Prototype

The homing missiles were the first test of creating AI for a Creature object. This is the next big step, giving it awareness of the environment. This comes after the graybox, so there's actually an environment for it to navigate.

Wrapup

If you made it this far, thanks! I'm really excited about this project, and clearly excited to write about it. Sprint 3 should wrap on 5/19, so expect a new big post then. Also, you can find me over at mastodon.gamedev.place and diode.zone posting more immediate updates and video content occasionally, so give me a follow for little bits along the way.