I can’t actually use a “meat’s back on the menu, boys” pun because I’ve never actually done anything with menus before now. My UI has, up until the last couple of weeks, been limited to the main character control heads-up display, which is operated entirely by keyboard and mouse. So, meat’s not back on the menu, but there is now a menu for it to return to in future.

Too tenuous? Bah, you’re no fun. Either way, gamedev is always on the menu at Chez Robbie, and he’s been hard at work doing things that weren’t specifically mentioned on his feature list to support things that were. (No change there, then.)

Progress Report

A. Level Generation: 6/8

I’ve finally done it! I dropped the plan to have circular rooms because my circle-drawing code is totally broken, but I’ve done octagonal rooms instead — at this resolution, they’re basically the same thing. Similarly, I’ve added pillars to some rectangular rooms to break them up a bit, which means Room Shapes (feature A5) is now thoroughly complete.

Octagonal rooms are a world of pain because they require diagonal walls. These are problematic because of how my tile system works — tiles are built up of four quads that are chosen based on whether their neighbours are open or walls, thereby ensuring lots of combinations slot together nicely without me modelling hundreds of tiles manually. The problem lies in choosing whether to use a diagonal corner or a normal corner, because the patterns of neighbours for both types of corner are the same — there’s no way to disambiguate. I’ve had to build the diagonal walls as solid tiles rather than as four-part tiles; this will make them less flexible but hopefully I’m discarding flexibility that I don’t really need.

The second problem with diagonal walls is that they are half open and half closed. A normal wall corner occupies the whole tile, but a diagonal one cuts through the middle, leaving the opposite corner quite clearly walkable. In terms of the bot pathing grid, I have to convert a few bits of the wall into floor at this point.

It’s not quite as bad as it seems, because I do have three resolutions of grid — while it’s a single solid wall tile at the world generator layer, it can be 3 walls and 1 floor on the quad layer (and 9 walls and 7 floors on the unit layer).

… You’re right, I only have myself to blame.

B. Level Navigation: 1/2

C. Item Systems: 4/4

D. Ability Systems: 2/2

E. Power-Ups: 2/3

F. Neutral Passive: 0/3

G. Enemies: 3/5

H. Traps: 0/4

I. User Interface: 3/3

Yes, I finally took a dive into the world of the main menu!

The first world of pain was around input . My game previously wasn’t capable of taking control away from the in-world character and giving it to an interface window, so I had to dive into my input handlers in a big way to make that switch flippable across all input ever.

It was long overdue anyway — I had input code smeared across a few different places so it felt good to get it safely contained. Plus I broke out some reusable key-press handling logic, so that I don’t have to re-implement debouncing every time I need something to fire once and only once per press. (I did it at least three times before now.)

Luckily, once control has been removed from my in-world systems, Unity’s got its own UI-handling magic. This covers button mouse-over and click highlights, keyboard navigation of button sets, everything. I had some problems setting it up because I’d bloody-mindedly deleted some of the pre-requisites because they appeared Too Soon, and then my cursor image was stealing all the clicks and stopping them from hitting the buttons underneath, but after that it was lovely.

No, thank goodness, you don’t have to press Alt+F4 to leave the game any more.

Some more fascinating pain came as I implemented the New Game option.

This system needs to completely reset the universe by reloading the scenario. This might seem like overkill when my procedural world can be reset by clearing and rebuilding within itself (as happens each time you go down a lift), but I know that eventually I’ll have more than one scenario to choose from. That makes this a good time to get some of these buns in the oven before I lay down any more infrastructure that might become impossible to unwind. (Besides, I’ll need a distinct character creation screen even for this phase of the project. You think I’d forgotten I was actually making a mech dress-up game?)

Unity’s a strange beast when it comes to levels. In many ways its scenes are like Warcraft III maps — they’re totally self-contained, to the point where your game doesn’t exist without some scene calling it into existence. This was my first source of pain: ensuring that any scene with very little scaffolding could still warm up whole backbone of the game. I don’t want to have to remember to add chunks of infrastructure in every level, and I’m glad to say I’ve reached that point — albeit through judicious use of static singletons.

All a level requires is now a concrete sub-class of LevelController, and nestled within that abstract base class’s Awake function is the ominous call RDZ.Bootstrap(). From there, it brings up all the gubbins: game state controller, physics constants, user inferface, the works. All the level-specific logic goes into that sub-class of LevelController and the backbone is contained safely at arm’s length

Progress

Making a game is hard and complicated, but it’s also what keeps me alive and fighting. I’m pretty pumped about it all right now, to be honest — I can see it in my head, and much like the fog of war peeling back as your units move forward, each completed feature reveals the next steps that need to be taken.

With 21 out of 34 features now squared away, momentum seems to be on my side at the moment — so let’s keep riding the wave!