Hey, this is a sort of a postmortem, sort of a technical discussion for the game Invasion of the Ball Beings from Sigma Pavonis that I made for the KO Slam Jam.

Part 1: Background

First a quick recap on the setup for the jam. There were three themes announced in advance to allow for planning ahead of the 72 hour jam. The themes also had an associated “spice word” which can add a twist to the theme. Your game could use any or all of the themes, and the spice words were optional. The themes for this jam were 1)Transition, 2) Slam, and 3) 120 Seconds. I did not use the spice words.

I. Themes and Ideas

After writing up nearly a dozen ideas, I had a difficult time coming up with one that stuck with me. In my experience, doing a jam requires a compelling idea to provide a burst of motivation to carry through the couple days of crunch. Without a firm idea that excites, I generally fail to complete a game jam.

This jam was challenging for me to come up with a sticky idea. I spent the first half of day 1 just trying to think of a game to make. I ended up reviving a design doc I wrote six years ago which was an exciting idea for a game, but midday on day 2 I realized the idea was too overscoped to finish in time. I tried a backup idea I had for the rest of day two but that also failed to stick. Finally, first thing on day 3 I revived yet another design doc from a few years ago and hammered it into shape to fit the 120 Seconds theme. The result? Invasion of the Ball Beings from Sigma Pavonis.

II. The Third Idea

The intent behind the original idea was to make a game with dirt simple AI – rolling balls that would just move in a straight line towards the player. I struggle with AI so it was envisioned as a way to realize a larger payoff from a simple system.

The original game would have put the player in an open city environment where they would have to fight their way to a shelter. As the game went on, more and more balls would rain from the sky. Various environmental puzzles would need to be solved to progress towards the shelter. There was even a note about being able to build defenses in the level.

Obviously that all had to be stripped out. The result is what you can download and play now. The player has 120 seconds to kill as many Ball Beings as possible. That’s it. The new idea fits the theme and is simple to make. However, with only a single day to make the game, it was still an open question whether I could finish it in time. (spoiler alert: I finished it in time)

Part 2: Technical Stuff

I. Level Geometry

Despite having made multiple FPS games in recent years for various jams, I do not have a well-defined pipeline for creating level geometry. I’m not a fan of Probuilder; it feels like a super clunky modeling tool and the UI leaves a lot to be desired. Brush-based CSG is how I made levels long ago in the source engine, and there are CSG tools for Unity, but it’s not a perfect workflow either. Making repetitive features (e.g. a dozen doors scattered around, all the same size) can be a little tedious.

The solution I went for with this game is modular models. I made a few types of walls and some generic pieces like blocks and ramps in Blender, and then I was able to piece them all together to form the geometry of the level.

The building models that make up the level

This approach is nice until you start scaling individual instances. It’s a lot quicker and easier to scale a floor to make it cover an entire room than it is to copy-paste a single floor section 10 times and line up each one. The drawback though is that textures get stretched, and there is inconsistent texture scaling unless you make a new material for every scale. Bad!

The solution here is a shader that uses worldspace coordinates for the UV. I can't remember where I got the shader from, but it works great. It even prevents z-fighting with overlapping faces, although baked lightmaps can still result in some z-fighting, though it didn't appear to be that common for me. Something to watch out for though.

Worldspace textures in action

This method isn't without its drawbacks. There's no way to control texture orientation on angled faces or rotated objects. However it works great for rapidly building a consistent looking level which makes it well suited for base geometry. Any ugly spots can be covered over or reworked manually.

II. Triggers

I made a trigger system a few games ago. I wanted something to allow me to easily and flexibly make things happen in a level, script encounters, etc. Once again this saved my bacon. There's not a lot of scripting in this particular game but I was able to set up the level start sequence, reset timers and kill counters, etc. really quickly and easily. They're powered by UnityEvents and are incredibly useful, perhaps I should neaten the code up and release them?

Triggers to start the level, reset stats, sequence audio playing, etc.

I also made a new VisibilityTrigger – it tracks whether the position of the trigger object is on screen, and can fire when visibility is gained or lost. I used this for the falling enemies. It looks bad if they simply appear in the sky so if you look up they won't spawn. Look down again and they resume falling on your head.

The complete trigger collection

III. The Shotgun

The shotgun is derived from the one I made for my previous game Orbit Guard (go check it out!). I really like how the manual reload mechanic amps up the tension as there are more actions for the player to conduct in order to reload. It requires a bit more attention than simply pressing R and feels like you’re actually reloading it.

There are two issues however with the shotgun, though both are technical in nature. First, I noticed (and subsequently forgot) while making Orbit Guard that there is sometimes a couple frame delay between pressing R and the shotgun opening or closing. Since this is the first time I’ve ever worked with animations in any of my games, I’m not sure why this may be but it’s something I’ll have to look into. Perhaps an animation state has to complete before transitioning? Whatever the cause, it feels pretty bad when it happens.

The second issue is that sometimes a reload input is missed. I haven’t looked into it at all but my first guess is that the shotgun is a frame or a few away from being in the Open state when the mouse input is pressed. A solution would be input caching for a few frames before entering the Open state. I need to dig into this a bit though to confirm my suspicions.

Overall the shotgun is a great addition to add depth to the game but unfortunately is likely to hamper the experience of some (most?) players depending on how often they run into the above issues.

Part 3. Final Notes

I. Tone

This is a game about giant fleshy balls raining from the sky. It shouldn’t be taken too seriously. The title and intro text are a bit offbeat to reflect this. The rhyming intro text was a spur of the moment idea I had. The original design document I wrote a few years ago had some intro/lore text and kinda sorta read like a rhyme, and I was reminded of a Calvin and Hobbes comic of a similar nature so figured it’d be a fun little thing to try. Writing at 11PM after 3 days of crunch and not enough sleep definitely had an effect on the quality but overall I think it turned out okay.

II. Material Remapping

I discovered this in the model import settings. Very nice. In blender I can assign materials to the relevant parts of the mesh, then in Unity I can manually make the material and assign it as a remap. This was very useful for the buildings because I had one material for all building blocks and I didn’t have to manually set up prefabs for each building block. It also stopped Unity from importing a “No Name” material for everything which littered the material browser (more on that in a minute).

III. Project Organization

As you can see in the image above, this time I tried to collect assets based on what they’re used for instead of organizing by asset type. For example, say I need to make & assign a material for the shotgun. Before I would have to scroll to the weapons subfolder of the materials folder, make a new material, scroll to textures, drag my texture on, scroll to models folder, find the shotgun model, and assign the material, all while wading through a massive open folder tree. Now it’s all right there in front of me at once. Easy.

Under the Assets folder I have a folder for each main asset type. These folders have their names in all caps. It helps them stand out which aids navigation in the aforementioned huge open folder tree.

I’m still working on ways to make my project structure better but these are some solid improvements.

IV. Unity, why?

Why do you include baked lightmap images and internal sprite images in the texture browser when I’m searching for a metal door texture?

Why do you include sprites for built-in UI elements in the sprite browser when I need the one UI sprite I made for the game?

Filter that crap out. I need my assets.

Guess how many of these textures are mine vs internal Unity crap

V. Closing Thoughts

This game was a 24 hour blitz after a 48 hour crunch. Stressful, but fun. I learned better methods for my 3D asset pipeline and project organization. I think the end result is pretty good too. Once again I spent a bit too much effort on making the game look pretty but the game looking good is half of what keeps me motivated.

See you at the next jam.