Category: Gamedev

  • Gentle People Devlog I

    I’ve been working on my current video game project, ‘Gentle People‘, for just over two years now and back in September 2025 I hit an ostentatious milestone: the game was, for the first time, basically fun to play. This is not at all a straightforward thing to achieve in making a video game, and my list of past projects (mostly unfinished) is a testament to that. My goal in working on this new game had been to prioritise prototyping the game mechanics, the win-lose-draw aspect of the whole thing, above all else. And it had worked!

    Naturally, on having this realisation I decided to go straight back to the drawing board. Here’s what I had:

    My initial concepts for the game, a band management simulator, were based entirely around the idea of shuffling bands between cities to record albums and play gigs, and so the main interface had ended up being this pseudo-world map with cities represented by Monopoly-esque tower blocks and routes between them drawn with rudimentary golden lines. Along the top you’ve got some important numbers: the season and year, which amount to the turn number, a count of how close you are to winning (‘historic moments’), how many bands you currently manage, how many actions you can make in each turn, and how many number ones you’ve had (five together get you a historic moment). Down at the bottom there’s space for buttons, which are the primary way you interact with the game (you can click the city models, for example, but there are also buttons for doing the same). As you and the AI players sign bands, they appear represented as little static people moving between cities.

    Put simply, this is a very boring interface. The excitement of the setting – inspired surely by my listening to Andrew Hickey’s excellent History of Rock Music in 500 Songs – is the interpersonal stuff, the drama, the who’s-in-who’s-out of it all, and while that stuff can’t really be the way you win the game, having it all visually stuffed into text-based side menus seems like a terrible waste.

    _space_train taught me the power of throwing a bunch of little descriptors at made-up people.

    So: the drawing board. What I want, on a base level, is to maintain the gameplay of booking gigs and releasing records, but with the player feeling like they’re there, in the background of some documentary about the Beatles, pulling the strings. Put simply: seeing some tiny little people moving about would make this way more compelling – one of the best things about _space_train (my first and most sprawling gamedev effort) was the permanent cast of personality-driven little aliens scurrying about the train around you. But that means having the game take place somewhere – there has to be a building that both the band and you, the manager, are plausible in at the same time. I went for an odd combination of the label corporate office and recording studio for the moment, with a pin in the idea of how to represent gigs for later.

    swat was going to be an all-narrative game with a vaguely cyberpunk bent. I only stopped working on it because I got distracted by Gentle People – so it goes.

    Cue lots of feverish coding between September and now for adding the capacity to draw a tiny little office and place a character in it to walk about; I was lucky in this regard that I was building Gentle People on top of a previous game effort I’d called ‘swat’ because the look of it was inspired by what I could remember of SWAT 2. That had a little person who walked about, but only between individual square dioramas. I had to do lots of wrangling to extend it to draw arbitrary-sized offices and then on top of that add a concept of ‘rooms’, because I was imagining that to perform different music industry tasks you’d need to walk to the relevant department at the label (still not entirely convinced this won’t be tedious in practise, we will see.) swat had an existing map editor, which was handy, and rather than adapting it to edit maps of arbitrary shape I instead put in another layer of ‘meta-map’, and an editor for gluing together lots of diorama maps into a larger whole.

    The meta-map editor. Might need to revise those colours.

    With all this in place I just needed to map the existing gameplay functions onto these rooms, which wasn’t too awful – though the big function that draws the entire UI is getting on for 1600 lines of code now. I’m resisting the urge to try and do something clever to break that down, thinking fondly of VVVVVV‘s 8000-case state machine.

    This is where I’ve got to; lots of effort the past few weeks has gone into fixing various things that broke along the way, such as saving/loading, the rendering of some floating icons in the intro, that sort of thing. But I’m now back at the point where the game is mechanically playable, and just about fun, but with a much more engaging set of visuals. The next step will be to add the tiny little band members running about and go from there. The best thing about working on a game like this is constantly feeling like I’m about to add the feature that turns it from something functional to something absolutely amazing; the worst part is actually trying to add that feature and finding that it will take ten times as much work as expected.

    Please, if you enjoyed this then read me talking about Poirot.

  • Gentle People: A Band Management Sim

    My current ongoing game development project is ‘Gentle People’, a sixties-era band management sim about nudging some bands towards putting out some hit singles, albums etc. Updates are currently paused while I pick through a large UI overhaul but the bones of the game are in place and quite fun to muck about with. It’s written in Rust using Bevy and compiles to WASM for the browser.

  • You take an onion

    I wrote a very silly one-page party game RPG based on something my friends and I have been doing ad hoc for several years now. It’s called Step One: You take an onion and I firmly believe that everyone should experience it once. Was featured in the b3ta newsletter, fulfiling my genuinely held lifelong dream to win the approval of message board users from 2005.

  • The most frustrating habits of Rust crate maintainers

    Rust has a fantastic and well developed universe of 3rd-party crates which will help you develop almost any application, right up until they suddenly won’t. Here are four ways in which you will be suddenly and deeply frustrated while learning this exciting new language.

    1. Weak typing is a documentation-specific feature.

    One of the unique aspects of Rust is the subtle but specific control over the movement of data under the ‘borrow’ system, which provides tough but fair oversight of access to information. To work effectively in this system, you need to know all about your data types, their capabilities, their restrictions, their lifetimes and much else — especially if you want to pass them into and out of functions.

    Enter the idiomatic documentation style, in which you’d be forgiven, encountering the language, for believing that the whole thing was weakly typed all along:

    Taken (with apologies) from the rand crate book, the most popular rust crate.

    Members of the community will be happy to inform you that compiler error messages are the fastest source of correct type name information.

    2. The new version is completely different and we’re all using it now.

    Enjoying all the conveniences afforded to you by this popular crate? Well, watch out, because that’s the deprecated 0.15 package.

    That’s right, despite being at the end of a 32-crate long chain locking you in to 0.15, main development — and somehow a bulk of users — are focused on 0.16 now.

    The API is fundamentally incompatible, usually due to the start or end of support for a platform you’re not interested in, and all of the dependencies are partially updated — if at all.

    3. “I have made excellent progress on this in a private branch seven months ago”

    Oh no — you’re using your fancy new Rust crate, but it won’t interop with another similarly fancy API or library that you’re also using! In fact, they’re mutually exclusive.

    Fortunately, there’s a GitHub issue for tracking this already, and some smart young grouse is making very perceptive comments and hinting that the solution is just around the corner — seven months ago, with radio silence and the fork set to private ever since.

    4. You shouldn’t, and therefore you can’t.

    Code, colleagues and convenience will often contrive to back you into a corner on some proposed feature or extension. It’s ugly, but there’s no other way to do it without necessitating some fundamental restructuring of your application. You sigh as you open your box of ugly hacks and set about patching it up.

    Unfortunately, you hit a blocker — some Rust package you depend on is complaining loudly about the exact thing you’re intending to do, and is blocking the build. Time to take to the airwaves, and search social media to see if there’s any quick way around this one. The replies comes quickly and in force: “you shouldn’t, and therefore you can’t”. Whether or not there’s a technical barrier to solving your problem, there’s an organic barrier that will be just as effective. Computers are machines of infinite flexibility, but that may not hold for your fellow coders.

    (Double points if there is a workaround available in the interface, but it’s been unmaintained to the point where it no longer works correctly.)


    A disclaimer, of course, that this list is at the very least wildly unfair on the good work usually done for free by package maintainers and the community around Rust, whose contribution to problems I’ve needed fixing absolutely outweighs their contribution to problems that have made me swear loudly.