Earlier this month I got a telephone call from Unity. After blowing the dust off my phone and a brief struggle to remember how the thing worked I found myself talking to an articulate woman with a Danish accent who, after collecting all the usual data from me, wanted to discuss discoverability. Had I heard of "Made With Unity"?
Yes, yes, of course. It's a hashtag that comes round every Friday. I may be in my forties, but I'm down with the Twitters. Brief confusion follows and I learn that it's also a website. With my free hand I type madewithunity.com into my web browser and it turns out to be some terrible Christian site. Actually it might not be terrible, but God and I don't really get on. Turns out where I really want to be is madewith.unity.com – ah, good, discoverability is solved and we can all go home!
I spent about an hour looking around the site, but after the first thirty seconds I knew it wasn't going to be any help. The problem? It was showing me things, not asking me questions.
Discoverability seems to be a widely misunderstood problem. It's not about showing players a few games they might not have seen before at random. There are far too many games now for that to be helpful, if it ever was. At its heart discoverability is about matching players to games they might like.
The current state of the art seems to be "genre". And if that provokes an immediate rolling of the eyes I suggest taking a quick look at the world of books, in which genre is still the most widely used approach to finding things to read. Nonetheless, the problems are obvious. I recently added King Machine to the vast repository of knowledge that is IndieDB. The "genre" field is mandatory and none of the options were even defensibly close to the game's actual content. I resisted the tempation to classify it as a Noire Car Combat game, because that's an actual option. So is Mafia MOBA. I mention this to make clear that it's hardly light on options and adding more really doesn't make genre work any better.
If books and films and music suffer from the same problem then there must have been serious attempts to make progress, right? Yes, indeed so. In 2006 Netflix offered a prize of $1M to anyone who could significantly improve their algorithm for recommending movies to users. Being something of an algorithms person I had a quick go myself and very quickly concluded the problems were too far from my field. The money was eventually claimed in 2009 by a team which only cleared the 10% improvement threshold by a whisker. Netflix remains, to this day, bad at recommending movies. But at least it's 10% less bad.
To be clear, the problem Netflix had wasn't ultimately algorithmic in nature. The problem was that the ratings data users provided didn't actually contain enough information to predict what they'd like with anything approaching reasonable accuracy. So if genre doesn't work and extrapolating from other preferences doesn't work then what does?
Another well known matching problem – and very extensively studied – is dating. At first glance it may seem radically different. After all, the most common version of the problem involves searching for only one partner. It seems to me there are a lot of similarities, though. In particular, people don't know what will make them happy. They think they do, but they're often wrong. The data from dating sites is incontrovertible in this respect, but for games it's equally obvious. Most players claim to want good gameplay, then assess what to play based on brief snatches of video.
The rise of "let's play" videos addresses this part of the problem. At the expense of a few spoilers, the viewer gets to see games as they really are. Not quite the same as playing yourself, but decently close. So is this a solution? Unfortunately not. Let me tell you a story…
Back in 2010 a game jam was held in Cambridge, UK. TIGJam UK 2 was primarily a meetup for members of the TIGsource game development community. I'm an early riser and grew up in Cambridge, so arrived early on the second day and headed upstairs in CB2, plugged in my laptop and got on with coding. Five minutes later someone else arrived, looking like he was probably a games person, and came over to introduce himself. We chatted briefly about his recent resignation from King.com and his game, Minecraft. He was surprised I'd heard of it and seemed quite pleased. Four years later he would buy a mansion in Beverly Hills with the proceeds from the same game, largely thanks to (by his assessment) YouTube videos. The point being this: let's plays are a great way to take your playerbase from thousands to hundreds of thousands, but by the time they're getting made your game has already been discovered. Even for Minecraft, that initial discovery was a hurdle.
Don't you only need one player to go viral? Well no, not really. Viral content is largely a myth. It exists, of course, it just doesn't spread in the way you might imagine. The graph of shares is actually very flat. Vast reach is achieved mainly via a very small number of nodes (people, sites) with individually vast reach. In other words, virality does not provide discoverability.
Before I talk about how we might improve discoverability, I should briefly address the "good game" myth. Every so often someone will try to claim that discoverability isn't an issue and that all you have to do is make a "good game". Sounds like sensible advice – after all, who wants bad games? – but unfortunately as well as being useless advice it doesn't work well. I recommend Alexander Bruce's outstanding GDC talk "Antichamber: An Overnight Success, Seven Years In The Making" for anyone who thinks this way. Although perhaps a simpler example still is J.K. Rowling's experience with her book "The Cuckoo's Calling". Written pseudonymously as Robert Galbraith, she hid her identity when approaching publishers and got the same dismissive rejection letters than any unknown author is familiar with. After publication the book sold only around 1500 copies… until her identity as the author was revealed and then suddenly it was Amazon's #1 bestseller. Was it a "good book"?
So how can we improve discoverability for games? From my perspective: better communities. Replacing bulletin boards (before you were born, kid) and forums with social media has a lot of upside, but the serious downside is that our conversations about games are hidden, or at best compartmentalised. I see a lot of creative people frantically accumulating Twitter followers, but for those who take it seriously it's thousands of hours of work for very little payoff.
If tens of thousands of players had access to the firehose of game releases that journalists are perpetually swamped by, we'd have the capacity to sort through it, to find our own ways of classifying things and getting them in front of people who want to see them. YouTube and Twitch handle presenting games fairly well, so that just leaves the finding part. And that's why you need a community of some kind, because when you find interesting things you need ways to share what you've learned. Even more so once you get as far as playing something.
There was a brief moment in 2012 when it looked as though major progress was being made in terms of distribution. I went to a meeting in London hosted by Steam, where they told us about their plans for their new Greenlight service. And last week when King Machine went up on Greenlight I got a glimpse of how things could work. Fifteen hundred potential players in two days! And they liked what they saw, with many positive comments and the all-important votes coming in thick and fast. Then, like every game on Greenlight, the traffic stops. Not because of anything I did. Not because of anything about the game. That's how the system works. Valve give you two days of traffic for free and then you're done.
Never mind games trying to get into Steam. What if we did something like this for all games? And what if it wasn't just for two days? Any time you felt like playing a new game you could just ask the site to show you one. And another. And another. Everyone's games, without limitation. And a place to discuss and share recommendations. Honestly, I'd build the site myself right now if not for one minor problem…
…nobody would know it existed, so they wouldn't use it. You know, discoverability.
Having failed to do any regular blogging during the development of King Machine, I should at least announce that King Machine launched yesterday!
Here are a couple of links…
Buy King Machine (or download the free demo) on itch.io: King Machine on itch.io
Vote for King Machine on Steam Greenlight (if you'd like to play it on Steam): King Machine on Greenlight
Last week I went to the Indie Games Conference 2015 in London. I wasn't just there for the free food kindly provided by Microsoft, or even for the talks (which were very good, even the ones not particularly aligned to my interests). Byron Atkinson-Jones had kindly let me have a speaking slot. Since most of you probably weren't there – it's a much smaller event than GDC – here's a video version of the talk I gave. It's about puzzles.
…now to get back to finishing the King Machine beta. It's pretty close to done! 🙂
King Machine is for the most part not a game about "enemies", but there are some characters in the game besides the player. One such character type are the mechanical spiders which cause problems for the player on some of the levels. And recently they've been causing problems for me too. They're fixed now, but it took a ridiculously long time (nearly a month) so I thought I'd write about this a bit. This is probably mostly of interest to other game designers, but there may be a bit of crossover into other kinds of programming.
So what was the problem? Well, in King Machine the player can alter (and even outright create) bits of the environment. The spiders have to traverse this environment correctly no matter what shape it is. Algorithms aren't something I find difficult, so I happily sat down and wrote a thing which treats the level like a graph and has the spiders traverse it. Easy! Took about an afternoon. Then the problems started.
First problem is that the spiders walk by raycasting possible leg placements. This looks great a lot of the time, but breaks horribly in a few cases. In particular, if something blocks the spider's body but none of the legs are touching it, the spider just gets stuck. Imagine a spider running like crazy, with its forehead pressed against a telegraph pole. Fixing this requires forcing the spider to walk on any surface which obstructs it.
Not that all the problems were with the legs. Next, imagine a sequence of cubes arranged into a path. The spider navigation algorithm easily plans a route along this path. Try it with the spider and it works. But what happens if you put a flat, square board over one of the cubes? Now the spider walks the same path, but when it tries to walk on the cube under the board it never reaches it because the board's in the way, so it just carries on walking. This is a problem with the pathfinding – it assumes that given two touching objects one is always reachable from the other, which is clearly wrong. Fixing this involved a massive increase in complexity as the spiders started looking ahead a bit to what they could actually reach and trying to walk around obstacles. And "around" itself is hardly a simple concept in 3D space!
Now if you're an experienced software developer you're probably already rolling your eyes by this point. And maybe also muttering things about complexity creep and keeping things simple. Maybe you'd recommend fundamentally changing how spiders move to something more manageable? Maybe you'd recommend throwing them out altogether and picking something easy? Good advice. Good advice.
So why didn't I? I see the problem the same way, but I don't agree with the objective. King Machine has been full of problems like this. Things which are awkward and complex and take far longer than they should. But if you go through a project and discard any interesting feature that is hard to implement, what you end up with isn't the thing you were trying to make. Some developers don't have a choice but to pick easy paths and ship as fast as possible. Given that I'm fortunate enough to have the option, I want to use that flexibility to make games other designers can't make.
That's not to say the spiders were really a good idea. A problem which King Machine has had all along is that the version of the game in my head was too complex for a one person team. I didn't know – and still don't know – how a really stripped down version of the game would work. Attempts to reach for a minimum core gameplay just looked too much like puzzle games. I like puzzle games, but King Machine isn't supposed to be one. Perhaps ultimately a certain amount of complexity is needed to support creativity?
Internet, I have a question for you: is it OK to implement "look around" in a 3D game by having the player drag with the right mouse button held down?
Now to be clear, I'm not asking whether this works as a control scheme. I already know it works. But it might still not be OK. Let me explain why…
I'm a great believer in playtesting. An important principle of good playtesting is that if a playtester raises something as a problem, then there is a problem. King Machine has been in development for a long time now and been through many control schemes, but one thing playtesters have quite often asked at the start of their very first play is "Why isn't mouse look always on?". So I explain that it's not always on because you need a mouse cursor. Why? For manipulating objects. For interacting with menus. "Why not lock the mouse cursor to the centre of the screen and get rid of the menus?" is usually the followup question. Well, if the bot turns at a reasonable speed that makes the cursor move uncomfortably fast for object manipulation. Also, some object actions look weird with the camera moving about. Also, the menus are a good way to control… blah, blah, blah…
But here's the thing: no matter what my reasons are for the design they won't stop every single new player potentially feeling the same way, which is a problem.
"New player"? Well yes, because here's the thing: after a player has been playing for a while, the problem goes away. How long this takes varies with (I suspect) how accustomed they are to FPS controls. The control scheme works pretty well using right mouse.
So here's why I'm posting this: I'm getting towards the later stages of development now and I really need to stop changing the controls and focus on finishing the levels and suchlike. Also, it's really hard to write the help system when the controls keep changing! The question is, what should I do with mouse look?
* Change it so that mouse look is always on. Effectively sacrificing quality of control for accessibility (and possibly ease of use in some cases).
* Leave it unchanged, trusting players to settle into the controls rather than giving up 30 seconds in.
* Have both schemes available, with a toggle in the options somewhere (which still leaves the question of which should be default).
* Some other solution, such as having mouse look toggle on/off with a key.
Votes and opinions encouraged! Of course, the natural response to that is "I'd have to play it and see how it feels". Reasonable… but actually wrong. The thing is, even by reading this post you already know too much! Most players won't have read this post and won't be thinking about the same issues at all as they play for the first time. And of course, as with anything, nobody reads the instructions!
So, I decided that King Machine was just about at the point where it made sense to open up preorders. And indeed, as is fairly standard now, preordering will get you access to an alpha version which I plan to update regularly as development continues.
More details on all this later, but for now you can watch the nice, shiny video tutorial for the alpha sandbox…
So, having been quietly working away at the game for some time now, I thought it was about time for a proper trailer. (Looks a bit fuzzy here because it has to be squished to fit on the page. You can watch it in 720p on YouTube if you prefer.)
Special thanks to Ed Fry (@Aeronic) for the music and Emma Newman (@EmApocalyptic) for the voice clips!
I need to have a proper think about whether to have some kind of alpha release and, if so, how soon. Might also mean I start using this blog a bit more. But then, I always say that. 😉
It is a well known and widely accepted thing amongst game designers that extensive playtesting is important. In fact even if you thought you already knew this, there's a fair chance that playtesting is more important than you think it is. But there's another aspect to playtesting which is less often discussed.
First, let's have a King Machine screenshot:
It's changed quite a bit since I last posted here. The actions available to the player have changed a bit and the interface to them has changed massively. Also, the player's robot now has cute little feet. That last is by far the least important change. But still… CUTE LITTLE FEET!
So here's the thing about playtesting: everyone knows you have to do some. Most people know the testers have to be people not on the design team. But what isn't nearly so widely recognised is that if you testers flag up a problem you have to fix it. Or more precisely, you have three options:
- Fix it.
- Decide not to fix it because different testers disagree over whether it's a problem or not.
- Ship a bad game.
Maybe you're laughing at option 3, but it's a lot more popular than you might think.
A big problem with playtesters is that they're often too polite. They say "I had some difficulties" when then mean "this stinks" or "perhaps it would be better if" when they mean "the current approach is beyond terrible". Fortunately there is a known fix for this problem: watch people play.
About five months ago, I spent some time watching people play King Machine as part of the UI redesign. What I learned was that the game was really annoying. Players mostly knew what they were trying to do quite quickly, then spent literally several minutes fighting with the game to let them do it. At the time I'd been thinking the game needed a better help system, but that wasn't really it. The problem was that even the redesigned UI was too fussy. It was very precise, but it was the bad kind of precise that forces you to care about exact control and play extremely patiently. Players seemed excited by what they could do in the game, but the act of doing it wasn't much fun.
What I did about this was simple: I rebuilt huge sections of the game. It took about six months, on top of the UI redesigns I'd already done.
The problem with this sort of thing is that it's enormously expensive (taking a long time), not very sexy (I haven't been blogging about the process for this reason) and if you get it right then nobody will ever notice. Which is why developers sometimes don't bother and just kid themselves that everything will be OK. But once the game releases, players are consistently unforgiving of bad designs.
Is King Machine's interface good now? Actually, despite all the rebuilding I still don't know. It's definitely a lot better, but more – hopefully minor – changes will likely be needed before it reaches its final form. Fortunately everything gets easier from here. I'll be blogging a bit more about the development now that it's mostly back to more interesting areas and in a couple of months or so there should be some kind of demo release so that people can finally get their hands on the game.
Not that this means the game is close to release yet. Feedback from more people is something I'm really looking forward to, but between then and release the aim is to refine the game further based on their comments. Because releasing bad games really isn't in anyone's interests.
I spent last week fixing my pooter, which was generating pretty regular blue screens of death thanks to a dying motherboard. I'll spare you the details. Suffice to say it works again now!
This week, I've been improving King Machine's basic building UI.
This is a process I've left much longer than I should have done for the simple reason that the old UI worked. I could build more-or-less anything I wanted with it. As a result, improving it didn't seem like a priority. Also, perhaps more relevantly, improving it was less fun for me than designing levels, making machines, creating artwork or coming up with new machine parts.
The problem is, there's a big difference between being able to make something with the old UI and the process actually being smooth enough to be fun. Players in King Machine will need to build a lot of stuff and if that process is fiddly and demanding it's not going to make for good gameplay.
So what have I changed?
The main difference now is that there's no need to use the menu at all to line up objects in basic ways. Clicking on the edge of an object will align the edge of the object you're holding with it and pull those two edges together. This makes it far, far quicker to build walkways and surfaces your bot can travel along. Clicking on a face of an object will align the closest face of the object you're holding to it and pull those faces together. This makes it much easier to build complex structures with all the relevant parts lined up correctly.
I'm also experimenting with automatically switching between grab mode and build mode. I have mixed feelings about this. On the one hand, it's quite common to grab something, carry it for a while, then want to build with it at the far end. On the other hand it's annoying to have the game switch modes when you didn't want it to. I'll probably need to wait for playtest results with this feature to work out if I want it.
Next step is to rethink how wiring and logic work. These are the aspect of the game most strongly tied to earlier versions of King Machine, so I've been reluctant to mess with them. On the other hand, you know what they say about sacred cows.
They go "moo".
It's amusing, looking back twenty or even as few as ten years how people seriously used to debate whether high level languages were a good thing. Programmers – and not just the sort with big beards who wore sandals in winter – would sometimes claim that C was just fine and there was no reason for anyone to use anything else. C++ had rather more advocates, but even they were keen to stress that the overheads introduced by their more expressive language were very small. If you did things "right", you were still in some sense writing assembler code. Allegedly.
But all along there have been people who have been quietly doing different things. Even back in the 90s, Tcl/TK could be used to build a fully functional UI for something in under half an hour. PERL has long been used to do all sorts of text-related things with incredibly short dev times. And ultimately even some of the C++ programmers started to bind Python and Lua to their C++ projects. "Scripting" was the word used for these secondary languages, because to admit that they were being used for programming would be to admit defeat.
Now environments like Flash and Unity take things a bit further. You write essentially your whole program in the local ECMAScript dialect (or something similar) and all the C++ is stuff that someone else has written, somewhere in the library layer. Like a kind of OS. Or, if you prefer, like the CPU's microcode somewhere in that layer you probably never even think about. Not that this is really new either. People have been doing approximately the same – albeit without garbage collection – since the 8-bit era.
But what is new is that programmers are finally realising that this is programming after all. In fact, not only is this programming, it's the bit of programming we really care about. Getting things done!
Guess what I'm doing to King Machine this week? I'm adding another language to the big stack of languages.
KMScript is, despite the obvious sounding name, not really a scripting language. What it actually does is to behave like a little virtual machine inside the game. Does that sound completely insane to you? Particularly for a game that's "almost finished"! (In quotes because of course these projects never are.)
In fact this is not some kind of absurd complexity creep. It's the opposite. King Machine's codebase is a huge, sprawling mass. In order to fully debug it and stabilize it ready for release I have to clean it up. But due to the ad-hoc way it has grown that isn't an easy process. I've spent a long time looking through it, searching for ways to simplify it. My conclusion is that there are very few functions that can be shared further and very little complexity that can be removed. However, most of the game's code I don't need to look at most of the time. When it occurred to me that this was rather like having two layers of functionality, I knew what I needed to do…
Within the game world, things happen like a block is created, aligned with another, activated, rotated by 30 degrees or whatever. These are simple things, but currently they are not simple to work with at the code level. So what I need to do is add a new layer of abstraction. So, for example, instead of having a class for "push beam" blocks that inherits from "block" and implements the push beam effect when used such a block should instead be a block containing a small code fragment in a new language internal to King Machine. In that language, a beam within the King Machine world is a known kind of thing and a "push" is a known action, so the behaviour of this block is very simple to express.
So far so not-very-interesting. But the real payoff here is that things like save files and replays can be encoded in this same language. This unifies all the data in the entire game and means I no longer need to add support in four different places for every feature in the game and keep them carefully synchronized. Even better, testing and debugging becomes so much easier because the level of code sharing will be far higher and all the code will be exercised more often.
OK, I lied, that's not the real payoff. The real payoff is that it's going to be fun! What's the point of being an indie developer if I can't have fun, eh?