Well, it’s not toooo late! By my calculation, at the time of writing there’s still a little over 52 hours left to participate!

To enter, go to this Playcocola link, read the instructions & you should be able to record a playtest session. I’d suggest around 20 minutes will be enough & then there’ll be a short survey at the end. If you get the highest score during a recorded playtest session before midnight (GMT) on Monday will receive $50 Steam Credit to spend on whatever game strikes your fancy.

As an added incentive to spread the word, if you have a friend who you know loves retro games, indie games & score-chasing in general, tag them in reply to this tweet & you’ll also get $50 steam credit if they go on to win!

Lastly, if you’d like to be notified about future playtest sessions, you can sign up here & I’ll email you when the next one comes around.

Thanks again & looking forward to getting your feedback. It’s still very early days for Drift Vector but with your help I think it could end up being something rather special!

In fact, almost everything relating to the game is very WIP at the moment, I’m rushing to get a demo out under a pretty tight deadline (which I’ll say more about veeeerrryy sooooon….) and there are a few other things in the works which I absolutely can’t wait to tell people about!!

Also, don’t worry, Rockets & Research is still in the works, but in all honesty, development had slowed right down over the summer while I got stuck in the weeds with debugging orbital mechanical mathematics to the point where I needed a bit of a break to work on something a bit more immediately fun.

It’s hard to believe that the game has been out for almost a year now, and in all honesty it has performed far better than I’d imagined…

I’d really love to do a full warts-and-all post-mortem with Jeremy as well as the whole Goblinz team (if I can get them to agree to it!) at some point to share what went well, what didn’t and what we (or other upcoming game devs) can learn from the experience. We’ll see :-)

In the meantime, if you don’t already have a copy, head over to buy Ozymandias on Steam while it’s 35% off (or 39% off for the Deluxe Edition!)

I know Test Driven Development isn’t exactly anything new per se, but it doesn’t seem to be quite as common in game development as in other fields. It’s always been one of those things that I’ve felt I should get into the habit of doing but never quite found the time to prioritise and has also felt a little intimidating. In addition, the few times I’ve tried to do TDD in the past, it’s been a very good way to chew up time and make things more complicated, rather than less. That’s likely mostly a result of my own inexperience, of course…

This month, though, I’ve hit upon a technique that’s worked quite well for me, which I’m dubbing “Test Driven Debugging”: Instead of trying to sit down and write a bunch of tests before doing any coding, I write a bunch of code first (whiteboarding any complex parts as necessary), then run the game to see if that produces the expected output. If not then, I go ahead and create a new test function & use it a bit like I would a REPL environment. GUT makes it really quick & easy to run a specific test function, so it’s super quick to iterate while slowly stepping through the logic of some system and using asserts (or sometimes just good ol’ fashioned console output…) to confirm that intermediate results are as expected. As soon as I catch something that’s not coming out the way I’m expecting it, then I can go back to the source code for that thing & try to fix it (or my understanding of it!), then re-run the test(s) to check that the fix worked.

To give a more concrete example, I have a GenericOrbit class which is supposed to be able to handle orbits with any eccentricity, however until recently the game only ever really included circular & elliptic orbits (i.e. eccentricity < 1). So when I started getting super-weird results from hyperbolic orbits, I went through the following process:

1. Add a test_hyperbolic_orbits() test function, within which, I:
2. Created & initialised the necessary objects
3. Started querying the relevant orbital parameters with different initialisation values. These were mostly fine
4. Started querying the positions & velocities returned at different timestamps
5. Noticed that I was getting nan values far more quickly than I would have expected
6. Went back to the code for the GenericOrbit class’s various functions, comparing them to the relevant math from the Fundamentals of Astrodynamics book I’ve been primarily using as reference.
7. Adding print statements inside those functions being executed to try & establish the point at which those nan values might be originating.
8. Found & fixed the offending lines in the code for the Stampff functions which were trying to square root a value which would often be negative for hyperbolic orbits.
9. Re-ran the tests, updated some of the assert checks where necessary, added a few more, removed some of those print functions
10. Ran the full set of tests to ensure I’d not broken anything else & then committed the change to source control

So it’s not that different to how I might normally debug my code, but with the difference that without really spending any extra time writing tests, I’ve got:

1. A nice, convenient place to do it rather than an ephemeral REPL session.
2. A signal to tell me if I break that thing in the future during a refactor or something and
3. A sort of accompanying documentation I can re-read in the future to remember some of the quirks in certain systems etc.

I’m not sure if others use “TDD” this way and I’m sure that I’d horrify a lot of more experienced devs with my tests, but it’s been pretty helpful so far, especially when trying to get to the bottom of bugs resulting in subtle maths-y errors like this one! Lord knows there are a lot of opportunities for those in a project like this!

However it’s only really been in the last 4 weeks that I’ve finally been able to dedicate myself full time to the project. In that time, I’ve completed two full “sprints”. While it’s still early days yet, I feel that it’s important to celebrate one’s “wins”, however small, so without any futher ado, here are some recent ones I’m quite pleased with…

1: “Random solar system generation

This now works pretty well. I’m particularly pleased with the way I’m able to assign different kinds of random distribution to each parameter (e.g. uniform / normal / lognormal etc)

2: Automated tests

These trigger every time I push code to the main branch in GitHub. Still need to actually write a few more of those tests though…

3: Basic “UI layout”

Including collapsable panels and tabs along with vector-based icons etc. I’m still getting my head around how Godot handles this stuff quite differently to what I’m used to with UE4, but it’s pretty close to the initial design:

4: Basic “timeline widget”

This shows the current simulation time and has a horizontally scrollable and “zoomable” window with tick marks and the ability to show instruction widgets. This took quite a while to get right tbh!

5: Object selection system

Including “object list” and “object info” widgets which can be used to select various things in the simulation and view info about them respectively.

6: Custom “orbital zones” material

I’m quite used to doing custom materials in UE4 but I’m pleased to have at least started getting my head around how they work in Godot. Each celestial body now has a visual representation of the “bounds” of its gravitational sphere of influence in terms of a min/max radius around the celestial body that it’s orbiting in a way that I think looks quite pleasing.

This takes into account the eccentricity of the celestial body’s orbit was actually predominantly for testing purposes for the system generation stuff. To simplify the maths I’m going to need for working out which gravity well should be used as the reference point at any particular moment, I’ve instigated a rule that these “orbital zones” cannot overlap each other unless there is a direct parent/child (aka orbital center/satellite) relationship between the two orbital bodies.

7: Basic save / load functionality

This was kind of working before but I managed to track down and fixed a bunch of memory leak issues with my first implementation. At the moment it only saves/loads the “generated system”, but in time I’ll get it to save other stuff as well

8: Started adding the “player actions” and “timeline instructions” systems

It’s important to do this in a way that clearly separates the two and also allows for undo/redo on a per-player-action basis. This is something that I really regret not having added to Ozymandias right from the start, since I was later unable to add it in after the fact without creating a whole bunch of edge cases and UI bugs etc.

While I’ve got a “version 1” of this working, I’ve quickly realised that I need to refactor it a fair bit to ensure I don’t end up having to write tons of boiler-plate code covering every single combination of the two, which is going ok so far, I believe!

9: Fixed a bug in Godot itself relating to sampling baked curves.

This was my first ever contribution to a major open source project, so I’m particularly proud of getting that merged!

10: Got automated web builds working & uploaded to fly.io with a single script.

This involved a fair bit of getting my head around Godot4’s issues with “cross origin policy” headers (which I still only partially understand tbh). It’s not perfect yet, there are definitely some performance issues (my Mac sounded like it was about to take off when I tested it in Chrome!) and there are a whole bunch of console error messages I should try to fix. Plus I can’t seem to get it to load at all in Safari on my phone or Mac, though I was able to get it running on one of the new “Mac Studios” running in the new local Battersea Power Station Apple Store…

If you’ve read this far and are feeling particularly brave, you can even go ahead and see if it works in your browser but be warned that there isn’t really much of a “game” there just yet!

Conclusion

There’s still a little ways to go before there’s enough of a “game” to ask people to test, but that’s ok, game development takes time! Especially when working alone from home, it can be all to easy to feel like one is way behind so I feel it’s particularly important to celebrate these kinds of little victories along the way :-)

Here you’ll be able to follow my indie game dev journey & read about me or the indie games I’ve worked on, like Ozymandias: Bronze Age Empire Sim and Horror Stories: Harvest Hunt as well as upcoming projects, Drift Vector and Rockets & Research.

Please bear with me while I’m still getting everything set up, but in the mean time, let me show you around…

In the top right there should be a handy menu to navigate the site & at the bottom you should find links to my Twitter & LinkedIn as well as the site’s rss feed.

For those who are interested in such things, the site is built using jekyll and served on fly.io via PierreZ’s gostatic. The theme is based on “minima”, though I’ve been butchering it a fair bit to try & make it a bit more “me”.

The site doesn’t currently use any kind of cookies, though I would quite like to set up some kind of basic analytics to better understand what kinds of things people enjoy reading about etc. Hopefully I’ll be able to find a way to do that without using cookies as well since no one likes those annoying pop-ups. I’ll try to set up some kind of commenting system as well, or maybe set up a Discord server. In the mean time, feel free to ping me on Twitter if you have any questions!