I’ve heard a lot about the Indie Bubble, #indiepocalypse, and other doomsday predictions, and watched as fellow developers released good games only to see them crater commercially. This is my assessment of why Reassembly has been a (moderate) success, and what I will focus on for the next game.
My hypothesis is that people play games as a form of fantasy fulfillment and that developers should aim to create games that fulfill a specific unique fantasy as efficiently and powerfully as possible. Anecdotally failure to fulfill a unique fantasy is the most common reason otherwise fun games fail commercially.
Fantasy Fantasy Fantasy
People buy (and enjoy!) games that offer a unique fantasy. A fantasy is like a daydream, a vision of an experience. It can be expressed in a single sentence, a single screenshot, or a couple seconds of video. A game needs to express its fantasy better than any other game or there is no reason to play it. Here are some (obviously reductive) examples:
FTL: command a spaceship like in star trek
Hotline Miami: be a psychopathic twitchy 1980s serial killer
The Stanley Parable: feel like an intellectual game designer
Papers, Please: be a border control agent for an Eastern European country
Fez: re-live 2d nostalgia while exploring the mysteries of the 3rd dimension
Nidhogg: fight in a surreal blood sport for the honor of being eaten by a giant worm
Galak-Z: be a skillful 90s mecha anime protagonist
Minecraft: survive, mine, and craft a sanctuary in a world made of cubes
- The title of the game specifically references the fantasy, not mechanics.
- Sometimes the fantasy is experienced by the game characters. Sometimes it is experienced by the human player.
- Many games interpret a popular fantasy from other media.
- The fantasy is fundamental to each of these games, and the mechanics and art directly support it.
Reassembly’s fantasy is “build a fleet of spaceships out of blocks and pilot them in combat”. The open world game mode was designed to give players a reason to build different types of spaceships and to generate diverse combat scenarios. Tournament mode gives more reasons to build spaceships. Story was deliberately omitted and the graphics were kept abstract to encourage players to inject their own specific spaceship fantasies into the game.
If the game provides a compelling unique fantasy, it doesn’t need excessively high production values. Building the game asymmetrically around your own core competency will insure that it does at least one thing well, which is enough. AAA games need high all-round production values because they are competing for ownership of a few fantasies: be a badass soldier, be a dragon-slaying viking warrior, etc. Don’t try to compete with them! Alexander Bruce’s talk Antichamber: An overnight success seven years in the making excellently addresses this topic.
Let players contribute to the game. This can take the form of Early Access, where players provide feedback and bug reports. Multiplayer games use players to provide high quality teammates and opponents. Games with building allow content created while naturally playing the game to be exchanged with other players (like Reassembly’s Agent/Wormhole system). Modding systems like Steam Workshop allow dedicated players to use external tools to create content. In aggregate players spend many more hours playing games than developers spend building them.
Give players as much mechanical and aesthetic control as possible so they can tune the game to better fulfill their fantasy. Even something as simple as letting players pick their favorite color can greatly increase investment and variety. Component/building systems and procedural content generation provide a huge amount of gameplay variety given how little work they are to implement.
Excessive polish or an extremely smooth tutorial are not important unless they are part of the gameplay fantasy, and can be huge time sinks. Many game developers obsess over making the intro tutorial sequence of their game incredibly smooth and pleasant. This is a form of craftsmanship which I deeply respect, but it is not really what games are about. If the game fantasy does not resonate with players they are not going to play the game anyway. If it resonates, they will be willing to deal with rough patches, even resorting to wikis for forums, in order to experience the fantasy. “Pleasant” and “painless” are not how we want our games to be described.
To reduce costs, Reassembly was developed largely out of my apartment and cafes. My primary costs were housing and food. The game uses a custom engine and vector graphics because I am a pretty good programmer but a terrible artist, and because having lots of totally custom giant spaceships on screen is fundamental to Reassembly’s fantasy. About a tenth of the upfront cost went to contractors, and another tenth to exhibition at conferences like GDC and PAX.
Friends and game developers are too empathetic and too polite to provide ideal feedback. They can comment on the game’s craftsmanship, but are usually not the target audience and usually won’t love the fantasy. Side note: Giving polite feedback is ultimately counterproductive, and something I have been guilty of too many times.
Seek feedback from people for whom your game’s fantasy resonates. These are your prospective players. Terms like “core gamers” are meaningless and deceptive. The folks behind SteamSpy wrote an excellent article about how your target audience doesn’t exist. Send free copies of your game in development to receptive people and take their feedback extremely seriously. Reassembly’s initial alpha tester pool found out about the game via gameplay videos on youtube more than a year before launch.
Player feedback was an integral part of Reassembly’s development. Alpha testing began just over a year before the final release (about half way through development), basically immediately after the game became marginally playable. Feedback from these players was invaluable because their only motivation was to shape the game into something they personally really wanted to play. I was able to experiment and learn in a supportive environment, fixing problems as they were encountered through constant feedback. When the game launched on Steam Early Access, we deliberately priced it somewhat high to insure players would be motivated to complain about problems and we would be able to respond to all of their comments. By the time we actually launched, it was clear that there was a market for the game and that the kind of people that purchased the game would enjoy playing it.
It Was A Mistake
I made several technical decisions early on that turned into unnecessary time sinks. Reassembly uses a render thread and a simulation thread, and this dichotomy is extended to every single GUI in the game. In retrospect using a single thread would have been fine in many situations and could have prevented weeks of bug fixing and many annoying crashes. The OSX version of the game uses native Cocoa text rendering instead of SDL_ttf like the Windows and Linux versions – this extra code path duplicates a lot of functionality and honestly the Cocoa text looks worse on non-retina displays anyway.
The Steam Cloud integration in Reassembly is a bit hacky – the world steaming system as designed creates potentially thousands of small sector files, and I hadn’t realized that Steam Cloud had a hard limit of 1000 files until after the game was in Early Access. I worked around the limit with the save compaction system, which periodically stops the world for several minutes and compacts blocks of 256 sector files into a single sector cluster file. This mostly works in practice but has been a constant source of frustration for players, particularly for the most active players with the most sector files.
I wish I had been able to bring on another programmer in the months leading up to the release of the game. I think an extra set of eyes could have seen many stupid bugs and improved the quality of the game in many ways. It may have prevented me from getting quite so burned out after release. I was worried about costs and whether anyone else would be able to understand Reassembly’s scattered code. In retrospect I think it would have been worth while.
Crashes really detract from the game fantasy, particularly when they result in lost data. I wish I had built better automated testing early on. A simple bot that runs around playing the game like the one described in this Talos Principle Talk would have allowed me to find all kinds of problems earlier. I should also have invested in more testing hardware – there have been many GPU specific bugs that could have been prevented by automatically testing the game across a few machines periodically.
I see game development as fundamentally a form of leadership in collective imagination. First, you identify a need for a specific fantasy in your cultural community (man, if we could build spaceships and then blow them up, that would be so cool). Then you build the game, making sure the community is on board and interested. Reaching out to community leaders on youtube and twitch (thanks Deluks, Aavakis, Lathland and others) is the best way to let the relevant community know about the game. A community will ideally develop around and sustain the game (thanks sumplkrum, Camo5, and others). Everyone has a good time building spaceships together.
Tynan Sylvester’s excellent book Designing Games discusses this topic from a different angle and in more depth.