Project: Untitled Space Shooter

I’m ready to press ahead with with a project that’ll help build out the engine.

As mentioned in the last post, now I have an integrated physics engine and can do collision detection and rigid body simulation, that unlocks actual playable game mechanics.

I’m still somewhat limited, no mesh deformation or animation/playback systems yet.

Untitled Space Shooter

I started this game, or at least a version of it, in Unity back in 2022.

It’s the reason I bought the Synty asset packs that I’ve been using in SR.

The game idea is simple, Shoot ’em up (shmup) style scrolling arcade game, where you fight waves of enemies, collect powerups and dodge asterioids etc. Not breaking new ground with this idea, but I kind of like that. It lets me focus on adding my own flourishes and polish to an already well established game design.

However, straight off the bat I need some changes.

Vite Packaging Updates

This is the boring stuff (to me at least), but it needed to be done.

Up until recently all my resources were just in a public ‘resources’ directory. When I added the asset packaging, it provided the opportunity to keep a projects resources together. It just required a bit more work and a ‘public’ api to make it happen.

It’s not perfect and it’s probably not configured properly, but it is working well enough for right now.

YAML Support

Because I don’t have an editor (and I’m not sure I will), I needed to change the JSON only scene description. JSON is great for serialisation when not editing by hand, it’s a well known and widely supported format. What’s also well known is how easy it is to break with trailing commas, missing parentheses and/or curly braces in the wrong place.

You also can’t add comments or comment out sections temporarily, which is something I find I need to do often. Also, I know beauty is in the eye of the beholder, but it’s ugly to look at.

A more intuitive and human-readable/editable format is YAML. Adding support for it wasn’t much work, as with JSON there is a lightweight YAML parser available. All I have to do is choose which parser to use at load time, the structure of the scene description / packages change.

This means I can now do this

entities:
  - name: Camera
    components:
      transform:
        position: [0, 0, 1800]
      camera:
        focalLength: 35
        near: 1
        far: 10000
        active: true

over this

"entities": [
    {
        "name": "Camera",
        "components": {
            "transform": {
                "position": [0, 0, 1800],
            },
            "camera": {
                "focalLength": 35,
                "near": 1,
                "far": 10000,
                "active": true
            }
        }
    }
]

I still support JSON as I already have the Maya scripts that can serialize a scene that way if I find I do need more a more complicated scene.

Input Handler

The next block of work was InputHandler improvements.

I had this long standing comment in the CameraController code:

// TODO: This should be in the InputHandler so it can support remapping

I had hard-coded the InputHandler.isKeyDown into the update function.

This is dumb for obvious reasons.

Instead, I need the ability to bind directional and action keys. This was a fairly straight forward addition, I added InputHandler.bindAxis and InputHandler.bindAction which lets a scene define its inputs:

input:
  axis:
    right:
      negative: [KeyA, ArrowLeft]
      positive: [KeyD, ArrowRight]
    forward:
      negative: [KeyS, ArrowDown]
      positive: [KeyW, ArrowUp]
  action:
    shoot:
      keys: [Space]

and these bindings are loaded with the scene.

It doesn’t make much sense for these to be scene specific but I don’t yet have a “project” concept, which would be the most logical place to bind inputs. If I find myself needing multiple scenes, then I’ll approach this then.

Anyway, instead of InputHandler.isKeyDown I can now do InputHandler.getAxisRaw("right") which will return 0 if neither the negative or positive keys are pressed or -1 and 1 respectively otherwise. It’s getAxisRaw because eventually I’ll add getAxis to provide a fractional value between -1 and 1 based on a controller’s input, but I’m not worrying about that just yet.

Some WIP

So with these few changes in place, I was able to start the project!

Background Effect Component

By far the biggest piece of new work was adding the ‘Background Effect’, not the StarField that is a “simple” Script that creates LineSegments, a path well tread already.

What I wanted… for science… was a gaseous nebula¹ background to complement the star field.

This meant adding a new and optional RenderPass with an ‘arbitrary’ shader and is configured by the scene description. This is an entirely new concept to SR but it fit in to the current architecture with minimal friction.

I could probably use an entire post going over how this works but the TL;DR version is the new ‘backgroundEffect’ component takes a shader path and up to 8 arbitrary parameters (this makes it project agnostic) and the renderer creates the BackgroundEffectPass at initialisation with the Camera uniforms, G-Buffer depth and of course, the arbitrary parameters which it then updates every frame.

When I was working on the game in 2022, I spent a very long time working on the player movement, trying to balance the blend between the dash with the arcade controls and keeping things responsive but fluid. Thankfully I was able to carry that work here, and hopefully you can feel it.

This is a lot of polish early on, and as with pre-optimisation being generally bad practice the same goes for pre-polish and for pretty much the same reason.

I’m going to ignore that because it’s just me and this is a personal non-commercial educational project and the polish makes me happy.

Ta-Ta For Now!

This will probably be my last post for a while, I’ve been burning the candle at both ends lately and my actual job is starting to get more mentally demanding during the day, which is making me less interested in spending another full workday infront of my laptop.