This week I’ve got a lot done in the way of Steam integration, save files, automated builds, some better randomization for galaxy generation, as well as some much needed bug fixes to make online play smoother. Got a lot done but not much on the visual side of things. But hey:

Nice to be one step closer to a shipping product

Got basic Steamworks apis integrated as well. Pretty painless with the Steamworks.net library for Unity. I was hoping to get steam invitations working this week to make play testing a bit easier but it looks like it’ll require a pretty extensive test environment that I simply haven’t setup yet. So I’ll be sticking to our current matchmaking system until then. I’m going to need a few virtual machines running different steam clients to get full end-to-end testing on the lobby functionality. The testing and development environments for multiplayer games always have been a bit cumbersome compared to their single player counterparts.

Bugs bugs bugs

I’ve taken the effort to get a decent suite of unit tests for Space Food Truck using Unity’s Test Tools. In the past, they’ve kind of lingered once some basic functionality was implemented but never really maintained, or even worse didn’t have any (see: Tilt to Live Series). In Outwitters, I had a small suite of client-side tests to validate some unit abilities but never really maintained much of them after several content updates. Meanwhile, the Outwitters back-end has an extensive suite of unit tests. They have been utter life-savers. The extra time spent writing thorough tests would quickly pay for itself just in stopping regression when updating the server-side logic.

Taking that lesson I wanted to apply it to Space Food Truck. The game logic itself is largely covered in the unit tests. Again, extra effort, but it’s bought me great flexibility when trying gameplay experiments, tweaking or fixing gameplay rules. I can quickly go in, change some gameplay rules or abilities, have decent confidence I didn’t break anything fundamental to the logic of the game. That’s great for sleep. But SFT gameplay kind of lends itself more easily to unit testing. For one, a lot of the architecture for the gameplay is a highly modified version of Outwitters core code. It’s a bit harder to do with an action-based game when a lot of your logic can heavily rely on simply collisions and collision detection (systems Unity handles internally and hard to test end-to-end).

The bugs I’m running into now are, unsurprisingly, anything that isn’t unit tested. Go figure. This is largely visual and UI bugs. A lot of times the underlying logic is happily chugging along and fully validated but the UI tripped over itself and has no clue WTF to do anymore. Getting UI and gameplay prefabs testable is an even larger effort (integration and automated UI testing) that I simply haven’t taken the time to do so. Part of the reasoning stems from time constraints (bad argument, I know) and also we’re using quite a few pieces of middleware to drive the visual aspects of Space Food Truck. Getting those isolated and into a testable form isn’t easy (especially if some don’t come with source).

Onward

Took a bit of time earlier this week to get a planet montage of some planets from Space Food Truck. Far from fellow indie Colin Walsh’s epic scale of Drifter’s “grand tour” video, but still fun to look at nonetheless. Looking to get more lobby UI working next week as well more graceful handling of less than ideal online environments. So far I’m on schedule with the sprints I’ve planned. Wonder how long that’ll last…