A few years ago, if you’d have asked me what I’d most want for people who fancied making a videogame I’d reply “well, more accessible tools”.
If you asked me today I’d probably still reply “well, more accessible tools” because you can’t really have too many different accessible tools and you can’t really have too many different approaches to compensate for people with different abilities, needs and mindsets, right? But I’d also really, really, really like the tools we already have to be more accessible too, y’know?
That’s not to say that I’m not incredibly happy with what we’ve got right now. I am. Look, I’m currently writing a bloody console game and that’s something I kinda hoped would be possible but you know how it is, it’s the sort of thing that even though you can feel the changes in and around videogames, there’s always that “yeah, but corporations” thing.
We’re making great strides with the tools themselves but there’s one place where every single tool still lags behind and that’s in the documentation. Some are better than others, some are much better than others (Soz Gamemaker, you know how it is. I love you but your documentation is terrible.) but mainly, they’re pretty crap.
We sort of take this for granted, I guess. I can see how! We’ve had years now where we’ve had user to user forums where anything that the documentation doesn’t cover can be covered by the community. I’m not really here to rag on that either, it’s fine. There’s also a more recent thing of having a marketplace in and around tools so that people can buy/sell slithers of knowledge too. I’m not really here to rag on that either, I think that’s mainly fine for now. I do worry about access to knowledge being explicitly tied to access to more funds over time but for now, we’re sort of doing OK so I’m not too worried. If I’m going to worry about stuff like that, I’m far more worried with the move to video tutorials over text because man, I just want to do this in my own time and pausing videos is such a pain.
The thing is, a lot of the accessible tools we have now for making games have been around a while. Sure, they haven’t sat still and they’ve evolved a great deal over time to encompass more things, better tech and who knows what else but still, they’ve been around a while. But there’s a thing you’ll notice if you lurk around a user to user forum long enough and that’s “How do I do this?” for maybe the same six, seven or eight things crops up over and over and over again.
Now, obviously, there’s quite a bit of this that can often really, genuinely be answered with “well, read the documentation” and a short gentle explanation of where to look and why (because if you’re the kind of person who just responds “read the manual” bluntly, you are a terrible human and you should be ashamed of yourself) but in the main, these are things that require an ability to know how to combine different things from the manual in ways that to a non-programmer aren’t entirely obvious.
So on the one hand, we’re asking people with absolutely no experience of making games and with no idea where to start to come into our world and make games and on the other, we’re kinda doing it in a way that expects them to have more knowledge coming in than they’re going to have. Awwwwkward.
We’re humans and what we’re really, really good at is forgetting that not everyone shares the knowledge we have, not everyone has the aptitude for certain things that we have and blah blah blah. And what we’re generally very, very good at in game development is being able to detail what a command does and being able to detail how to make one type of game with a series of steps and crap at detailing all the bits inbetween. Where the community or marketplace often comes in is filling in the bits inbetween those two things, the bits we forget/don’t feel the need to write about. Theoretically, this is sort of fine. Ish.
As we bring more and more people in to game development, as we make tools more accessible, having these bits filled in somewhere is going to be increasingly important. It’s important now but as time goes on, it’s going to be more so because this genie isn’t going back in the bottle now. And yeah, I know writing documentation well is quite a skill and I know it’s time consuming and I know it costs money too because someone needs to be paid to write the thing but it’s an essential part of how accessible a tool is, documentation should be the first port of call for anyone wondering “hey, how do I do this thing?”
To write documentation that covered everything? That’d be a madness! A near impossible task because have you seen some of the things people want to make? They’re bonkers! They’re often brilliant, or insane or wonderful or probably a really bad idea now you mention it and man, let us never speak again of that particular game or what have you. Obviously, I’d dearly love for documentation to be as all encompassing as possible but we’ve all only got so many years on this planet, so much money, so much bother to do something and only so much we can do and I appreciate that. I really, really appreciate that. That’s where books and forums should come in.
But that doesn’t mean we can’t do this better. So here’s the thing I’m getting at.
First up, make sure any documentation is able to be read by actual humans who might have less of a clue about code than the person who’s writing the documentation or coding the tool.
Secondly, if you’re the owner or publisher of a game making tool and you’ve been around for a while now, go take a look at your user to user forum because hey, I know you’ve got one, everyone has one of those. Go and have a look back through the questions people are asking over and over again. And before you go “but that’s answered in the documentation” and move on, ask is it really answered in the documentation or are there a load of different pieces of information in the documentation that someone new to making videogames would need to pull together and have absolutely no idea how to do so. I promise, you will find plenty of these.
Now make a list of the most common questions and go and write down the answers because I know you’ll know the answers because they’re going to be things like “how do I stop the player falling through a platform” or “how do I avoid him sticking to walls”, “how do I make the player shoot from the tip” or similar. Maybe you won’t be able to give a full answer with example code, maybe your answer will just be the theory behind it. Best answer is to be able to break it down step by step and teach it. It’s these sorts of not-quite-normal documentation yet not-quite-normal tutorial fodder that tend to get overlooked yet they’re pretty important, yeah?
Then get someone to translate that answer into something readable by human beings so that human beings can read it. Then file it amongst documentation that ships with the tool. Not residing on a blog post, not tucked away in a “how to make a Mario engine” tutorial. Just there. A click of a button away. There because you know these are things that people will want to know when they use your tool and having that knowledge to hand means they don’t have to spend a few hours searching through a forum where every forum search is rubbish, they don’t have to spend a few hours waiting for someone to answer a question that’s been asked a thousand and twelvety times, they don’t have to bang their heads against a keyboard trying to search google for I don’t know, how am I supposed to search for this? They don’t have to spend out a few quid on something that they have no real idea if this is the thing they’re really looking for and even then, buying it won’t exactly explain how to do it.
It’s a simple way to lift everyone up, to cut out some of the headbanging out during the learning process. It’ll still leave room for communities, for marketplaces, for books to dig deeper into and for tutorials for beginners and advanced users.
Accessibility in a game making tool isn’t just about doing a few things at the touch of a button with the tool for people, it’s not just about having a button that’s easy to find or whatever, it’s about how easily someone can learn essential techniques to get their game off the ground as well. If there’s a few small things that can be added to the documentation that’ll make a vast difference to tens or hundreds of thousands of people, why not, right? Then user to user forums have an easy thing to point at for those who ask first, read manuals later. Then user forums can concentrate on helping people through bigger things instead of the basics and more people get to make the games they want to make with a bit less friction.
Accessible tools, accessible documentation. The two really should go hand in hand.
We’ve got the tools*. Let’s make learning easier too.
*but some more wouldn’t go amiss anyway