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.
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.
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.
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:
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.
This essay is an accessible version of an in-browser game available here.
I don’t like players.
Or, to be less misanthropic, I don’t care for players.
They do their thing, and I do mine. I make my games like I built sandcastles as a child.
Can you come play in my sandcastle?
Maybe, sure, once it’s done.
Once I’ve drawn the line in the sand that means “the part where this gets made is over and the part where it falls away into oblivion has started”.
Sometimes of course, I am a player.
I try to play appropriate respect to the people who make the games I play, which is maybe to compliment them on their artistry if there’s an appropriate venue to do so… probably not on twitter… and remain silent the other 99% of the time.
Nothing more perverse than taking someone’s art and offering them unsolicited technical advice.
Lots of people in games have a community; I wish them all the best.
But I have a community, and it is not in games.
To have a community in games I’d have to compromise my participation in communities elsewhere and I’m not willing to do that.
Like most people, I think, I’m already anxious enough that I’m failing to meet my existing social commitments.
I’m not willing to take on the burden of more friends.
Sorry.
I could get a job making games. But I won’t. No apologies there.
Without players, and without a community, and without a commercial interest and promotion and professional marketing and all that guff…
There aren’t many venues through which people to play the games I make.
I can expect a polite level of interest from my friends, like when they talk to me about climbing or rowing or filmmaking or cooking or running.
They might have a look, as a curiosity. Or they might not. Their interest is not my interest.
For the most part, this does not bother me.
I like the part where I build the sandcastle, and if I depended on other people’s validation of my art (at least in this instance) then I might act differently.
But I don’t, and I won’t.
It just seems so odd, to make a game that is not to be played.
So much so that I’ve taken some time out and made games that can be played, just to make sure I could.
But I feel just as unfulfilled in either instance.
Giving those games to people, to play them, is nerve-wracking.
When I’m at home alone, just me, I dance.
I put some music on, whatever I’m feeling like, and I just slam around.
Back and forth, up and down, in different rooms.
Or I put on some movies I don’t think anyone else would be interested in, and watch three in a row.
Or I sing, and record myself singing, then delete the recording.
These activities have never felt less than complete.
Which I not to say that I don’t appreciate participatory art; I’ve made videos, I’ve directed a play, I’ve done things which are collaborative. They’re fun.
But I make my games for me, even as they pull away from me.
They demand of me that I learn the skill of marketing and networking and twitter, and they press me against this horrible flat surface where I read about… how the steam storefront is changing and what that means for wishlisting… or else how there are game jams happening this weekend.
They even have game jams for people who make games alone.
But I don’t want any of that. I like to make my games, by myself.
Even now, I’m writing an essay so I can release an essay, in the exact space where I make my game and do not release my game.
It’s just how it is with me.
Can I make games alone if I don’t like players?
I guess, I can.