Unique Fantasy

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

Some observations:

  • 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.

Work Efficiently

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.

Seek Criticism

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.

Conclusion

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.

Steam Release Checklist

A curated list of Reassembly bugs that were fixed after release

Every game developer strives to release a perfect game. Many bugs are hard to predict, especially for indies with only a few computers and no experience. I wanted to document some of the things I missed in the hope that other developers will not miss them. These are especially relevant for native (i.e. C++) games which are a little closer to the platform than e.g. Unity games. Almost all of these bugs were fixed during our Early Access period and before the “official” release.

The vast majority of Reassembly work/bugs during the Early Access period related to gameplay elements. The bugs listed here are selected for possibly relevancy to other games and are mostly in the platform layer. A complete list of changes is available on the Steam Announcement Page.

Localization/unicode related

  • Steam usernames are UTF8 and frequently contain ƃᴉzɐɯ∀ st☢ff. Reassembly uses Google’s Droid Sans Fallback and Open Sans Emoji to provide additional characters for rendering usernames, and SDL_ttf or Cocoa/NSFont to actually render the text, depending on the platform. In an ironic twist of fate, the first version of this article was lost because wordpress choked on a U+E10D (rocket) character.
  • The game may be installed in e.g. C:/вещи/Steam/SteamApps/…. so any assets must be loaded using unicode paths. OSX and Linux use UTF8 for everything and are easy to support but Windows builds must convert to wchar_t* UCS2 encoding via WideCharToMultiByte/MultiByteToWideChar or similar.
  • Non-English versions of Windows return native-language error messages in GetLastError/FormatMessage. This means that any logging mechanisms must support unicode. Printf/sprintf on windows support a %ls format specifier for wide character strings but will crash on non-ascii (thanks to Russian alpha tester Krypt for helping me track down this bug).
  • Games that hardcode WASD will not be playable on many Non-English keyboards. Keybinding systems must support unicode keyboard input.

GPU/Graphics related

  • Vsync on/off/adaptive options are probably a good idea. Adaptive Vsync (aka tear control) is a good solution but is not supported on all drivers. Many players have old/slow GPUs that won’t achieve 60fps and consequently would have a bad experience under Vsync. Some players have 144hz monitors and would like to take advantage of them.
  • Should the game launch in a window, in “true” fullscreen mode, or in a borderless fullscreen window (fake fullscreen)? True fullscreen mode has performance and especially smoothness advantages, while fake fullscreen allows easier alt-tabbing. Reassembly simplifies video monitor modeset issues by always using the same fullscreen mode as the desktop, and defaults to true fullscreen.
  • Some people have their desktop set to 16 bit color depth. This may cause OpenGL context creation to fail if you request a 24 bit framebuffer.
  • Significant numbers of Steam users have GPUs that only support OpenGL 2.1. Things like framebuffer objects, floating point framebuffer formats, and various functions may not be available or may only be available through older EXT variants (check GL_EXTENSIONS).
  • Some people have broken or seriously out of date graphics drivers. This is mostly a support problem but…
  • Various GPUs do a poor job of implementing certain OpenGL features. For example, antialiased (GL_LINE_SMOOTH) lines look terrible on many ATI GPUs. Adding video options to the game allows players to work around unforeseen problems.
  • Many people still have 4:3 monitors. If the game resizes UI elements according to the current aspect ratio, make sure to test at 4:3 (in addition to 16:9, 16:10).
  • Many people will disregard minimum system requirements and try to run the game on very old/slow computers. Detecting the OpenGL version and at least popping up a sympathetic dialog is much better than crashing in these cases. Adding options to reduce CPU/GPU usage at the const of graphics quality will also allow many people play your game that otherwise could not.

Hardware/System related

  • Test the game on hard drive systems and SSD systems, particularly if any kind of asynchronous/streaming system is involved. Hard disks can be VERY slow – you may need loading progress bars in places were SSD systems would not.
  • Different gamepads have different polling intervals, button mappings, deadzone requirements, etc. Test at least PS4, PS3, Xbox 360, and Xbox One controllers. With an event based API like SDL_GameController, make sure to poll for ALL events every frame instead of just processing one, or events can get very backed up. Consider analog stick deadzone and smoothing options. Test mouse and keyboard functionality in UIs with a gamepad plugged in, in case stray gamepad events interfere. Make sure to handle the case where a gamepad is detected but initialization fails, or where the gamepad is unplugged/plugged in during gameplay.
  • 5 button mice are common. Make sure you don’t e.g store mouse button state in a bool[3] array with unrelated variables immediately afterwards.
  • Key bindings should probably still work even with caps-lock on.
  • Many Steam users still use Windows XP. Supporting XP/Vista/7/8 with one build involves selecting the “_xp” toolkit in Visual Studio and using GetModuleHandleEx/GetProcAddress for any APIs that were introduced after XP, with fallbacks. Make sure 3rd party DLLs also support XP.
  • Test any scroll wheel functionality on mice AND touchpads. Apple touchpads in particular can generate scroll events at a very different rate than traditional mice.

Steam/Steamworks related

  • There is a 1GB/1000 file limit on Steam Cloud saves. Exceeding this limit results in lost save game data.
  • Many Steamworks API calls (achievements/stats APIs, cloud save APIs, etc. including SteamAPI_RunCallbacks()) seem to grab a global mutex and consequently can block for long periods (multiple frames) of time if another thread is for example writing a large file using the API. My solution was to only ever call steam APIs in a non-critical-path thread.
  • Many API calls (ISteamRemoteStorage::GetFileNameAndSize, ISteamRemoteStorage::FileExists) can be very much slower than OS equivalents. If you call these frequently or depend on their performance, it may make sense to maintain a cache of results.

Crash handling

Reassembly implements a crash handling and reporting system similar to Mozilla/Google Breakpad that has been invaluable in improving quality. Via the Win32 API call SetUnhandledExceptionFilter, it is possible to catch NULL pointer dereferences and other errors that would otherwise crash the program. The program can then collect a stack trace and log file and upload it to a server before popping up an apologetic message and actually crashing. The Reassembly code for this is on github (including a similar implementations via signals for OSX and Linux). We don’t ship .pdb files but include the .dll load addresses to enable associating symbols with the memory addresses in the stack trace.

A CGI script that accepts file uploads can run on any web hosting solution and contain less than 100 lines of code. Compressed HTTP uploads are available through libcurl or dozens of other easy to use libraries.

By collecting (frighteningly) large numbers of crash reports, we were able to triage and fix the most frequently occurring crashes first. It also quickly became obvious that only a small percentage of players report their crashes via email, steam discussion boards, forums, or other explicit methods, and that crashes so reported are not always representative.

This method was very effective for fixing crashing of all kinds, and particularly for race conditions and other bugs that can be hard to reproduce without specific hardware.

It’s very important to anonymize collected log files, including removing information like the current system username which may be present in paths.

Professional QA

Indie Voyage, our Kickstarter/publishing partner, hired a professional QA tester (Chris Watkins) in the month leading up to release. He uncovered a large number of UI, tutorial, and general user experience problems and greatly increased the game quality. In retrospect I would have allocated more of our Kickstarter budged to this area and started sooner.

One of the dangers of Early Access and similar community-driven systems is that players quickly learn the game and focus on advanced end-game features. Players that are put off by the initial experience do not contribute to the community. Focusing development on the end-game is valuable but can leave new players confused.

Final thoughts

Despite my best efforts Reassembly is still not 100% bug free. I’m very proud of how close we have come, and hope the accumulated knowledge is useful to someone.

I did search for a service that would automatically run the game across hundreds of machine and OS configurations looking for problems but was unable to find one. We had a system (actually, at least three different systems) like this while I was at Nvidia for testing the driver and various internal tools and it was great.

Hardware dependent graphics problems are a persistent issue. The cross product of GPU/driver/OS is very large. Actual crashes are great in the sense that they produce stack traces and can usually be worked around directly by e.g. checking GL_EXTENSIONS more carefully or avoiding undefined behavior. Rendering glitches – parts of the scene mysteriously not visible, unexplained z-fighting, etc. – are more insidious. I have not found a good way to debug these besides guessing or buying the GPU in question and hoping to be able to reproduce.

April 2015 plans

I’m back from my post-release vacation and excited to get back to work on Reassembly! These are the things I plan to focus on in the coming month.

New Features

Modding/Workshop support

Reassembly already supports a form of “User Generated Content” through the fleet sharing wormhole/agent system, and many users have had fun with the sandbox or by modifying cvars that control game behavior. I know for a fact that many Reassembly players are significantly better at building spaceships than I am. As a first pass at modding support, I want to expose and document the existing config files and let people publish their changes to the steam workshop, making it easy for other players to enjoy them. The initial mod workflow would be something like this:

  1. In game, convert an existing save slot containing ship designs into a “mod” for new-faction mods, or create an empty “mod”. A mod consists essentially of a number of text config files and spaceship files.
  2. Edit text files to define the mod. This includes adding new blocks or modifying existing blocks, adding or modifying spaceships, changing one of nearly 300 cvars that control various game behaviors, modifying the world generator config file, tutorial or message text, shaders, etc. You will be able to reload config files in-game and view relevant syntax errors.
  3. In game, upload the mod to the steam workshop.

Players will be able to download mods through the steam workshop and then turn them on or off and select precedence (if mods conflict) in-game. I’m excited to see what people come up with! I expect modding support to go through several iterations as we work with modders to expose more functionality and improve the workflow.

Modding support should allow the community to experiment with tons of new content much faster that I would be able to support myself.

Better Fleet AI controls

Better control over AI, both in tournament mode and in the main game, is probably the #1 requested feature. There is already a system in place for generating AI programs based on ship design and faction personality, so most of the work is in UI design. I’m planning to have per-design (this ship should only attack from long range, this ship should always rush, etc.) AI policy plus global fleet policy (everybody stop shooting, attack anything that moves, etc.).

Other Stuff

Localization

A significant fraction of our players are not native English speakers and translating the relatively small amount of in-game text and providing better default keybindings should improve their experience. The game already uses Unicode internally so code changes should be minimal. If anyone is interested in helping translate the game into their native language and/or setting up keybindings, please contact me.

Complete Gamepad Support

Likewise, adding gamepad support to the editor and menus would not be a huge amount of work and would be cool.

Wormhole server / feed

I recently added a search feature to the wormhole feed – there used to be a giant list of users at the bottom of the page but it was getting out of hand. I’ll continue to improve this system as well as the game server which processes wormhole uploads decides which agents populate new worlds.

Bugs / Polish

I’ve received several reports of black screen issues on certain just-barely-supported video cards. There are a few lingering general crashes, and glitches like agents spawning inside of asteroids. The tutorials, as always, need polishing. Some players are reporting trouble downloading agents when starting new games. There are always thousands of little changes that significantly improve gameplay but aren’t worth writing about individually.

Conclusion

I expect this work to take up most of April. Game development is an iterative, community-driven process and we’ll take another hard look at the game for June and see what needs to be done.

February 28th Tournament Results

Thanks to everyone that submitted ships and or tuned into the February 28th tournament! Special thanks to DeluksGaming for joining us!

There were some technical issues getting set up (and some exciting live-coding) so we were only able to run the first two categories. The seeding results are now online:

[Probe] [Interceptor]

Amazigh’s Funnel won the interceptor category and CmdrJohn’s Federation Run And Hide won the probe category.

The twitch streams are recorded on youtube: [Part 1] [Part2]

We will conclude the tournament on March 14th at 2PM PST.

Youtube

I, Arthur Danskin, the copyright holder of Reassembly, grant you, whoever you are, permission to post or stream footage of Reassembly on youtube, twitch, or similar video sharing sites, in the context of Let’s Plays, reviews, or for other purposes. You may also monetize this footage.

You may additionally include the game music in your video.

Including a link to purchase the game (store.steampowered.com/app/329130) and/or soundtrack (peakssound.bandcamp.com/album/reassembly) is encouraged but not required.

Also, thank you for posting videos. As an independent developer with a very limited advertising budget I rely on this kind of thing to let people know about my game.

Beta!!!!

The day is finally here – Kickstarter Beta backer and Alpha tester keys will be going out early tomorrow morning (November 25, 2014).

The Steam Early Access page is up and the game will go on sale when keys go out. I’ll get a steam widget up on the front page some time soon.

Thank you again to all the Kickstarter backers, the alpha testers, Peter, Colin, Rob, Christine, Eddie, and everyone else who contributed to this release.

This is just the beginning! I’m excited to see all the new spaceships everyone is going to build, and I’m excited to get tons of feedback from the new influx of beta testers and get back to work. Please direct suggestions and bug reports to the forum!

Note on Linux Support

I wasn’t able to get Linux Steam integration ready in time for the deadline. The game already runs on Linux and some of our Alpha testers run the Linux version – I expect that it should be ready on Steam within a week or two.

Beta Progress

It’s been about a month since the last update and we are well on our way to Beta release!

Async Multiplayer

Screen Shot 2014-11-20 at 11.05.39 PM

wormhole (perlin noise!)

After flying into a wormhole, players can now upload their current fleet to the server. These fleets will be downloaded from the server and injected into newly generated worlds. Players can conquer their way across each world, defeating other player fleets, and then fly thorough a wormhole into a new world. Injected fleets will stick together, get in fights with ambient ships, and generally behave like the player’s own fleet.

Server authentication works either via steam or by reusing the Anisoptera Games Forum login info. This is essentially to prevent players from impersonating each other and so we can keep track of which fleets each player uploaded. Login is only necessary for uploading fleets.

There is still a lot to do with respect to notifications and organization. Eventually we want to allow players to track statistics from their uploaded fleets – how many players did it kill? How many people fought against it? There should be a way to browse uploaded fleets, maybe upvote especially cool ship designs, and so on. We are also considering some form of steamworks integration.

Tutorials and Introduction

We were able to playtest the newly improved beginning of the game through our showcase at the MIX at GDC Next just last week and found that people were able to start playing the game without instruction much more effectively than at PAX Prime the month before that. In several instances players asked me a question, only to have it immediately answered by an in game tutorial prompt. There is still work to do in this area but I’m confided that Beta testers will have a good first impression.

Steam Integration

steam logo

steam logo courtesy of Eddie Peters

The folks at Valve have done an excellent job making the steamworks integration process as painless and straightforward as possible The steam overlay, for example, required a grand total of one line of code to enable. Beyond setting up the store page and uploading builds, we have also added support for the steam cloud so that saved games will be seamlessly transitioned between computers. As part of this work we enabled gzip compression on the (plaintext) save file format, making save files much more compact (previous alpha builds could generate hundreds of megabytes of persistent data as the world was explored).

Other Changes

gaussian blur on pause screen

sweet gaussian blur on pause screen

Beyond these main items and fixing lots of bugs we also found time to do some graphics improvements. There are new snazzier shader effects for resource blobs. The gpu-based particle system was modified to use GL_POINTS instead of triangles, making it both faster and prettier, and the inter-menu gaussian blur effect was greatly improved. The same blur shader is now applied at a much lower setting to add bloom to weapon and particle effects. These effects can all be disabled on low end systems.

There is also a new box on the devlog page to the right (just below the twitter widget) showing recent source code commits.

Reassembly Beta Plan

The Reassembly BETA is scheduled for release this November. The goal is to have the overall structure of the game in place at this point, then spend the time between beta and release polishing and adding content. I wanted to outline the major features that will go into that.

In general the gamedev process (at least for me) involves iteratively looking at the game and then trying to change it in a way that makes it better. There is a lot of trial and error and it is hard to plan too far into the future. We got Kickstarted though, and the backers deserve to know how we intend to use the resources they so graciously provided us with. This is what I plan to work on for the next month. These items will continue to be developed through the beta period, but this month will be dedicated to laying the foundation.

  1. Asynchronous multiplayer
  2. Tutorials and introduction
  3. Steam Integration

Asynchronous Multiplayer

The basic idea is that spaceships you create will show up under AI control in other people’s game worlds and vice versa. The intention is twofold: first to do something really meaningful with player creations and secondly to provide more content than I could possibly design myself. This sort of feature is often called “User Generated Content” but I think “Async Multiplayer” is more appropriate for Reassembly because the content creation (spaceship design) phase is an integral part of the gameplay itself.

Functionally, this is a “glue” feature that requires moving data around without disruptively changing the game code. In the first iteration players will upload their fleet by flying into a wormhole. Opposing fleets will pop out of wormholes and engage the player and surrounding AI ships. We will track statistics so you can see how the alternate dimension versions of your fleet are fairing. The server will automatically validate and sort fleet uploads. Since the world is already procedurally generated and fully serializable none of this requires new technology.

The unit of ship interchange is going to be the “fleet” – a group of ~5-10 ships designed by the same person with a unified color scheme and design sensibility. Players naturally design and fly a range of different ships as they play the game, trying out new weapons and gradually increasing their point cap, and a fleet of mixed ship types is interesting to fight against and makes sense in the game world.

I am really excited about this feature. Seeing players design new spaceships that I would never have imagined has been really fun for me, and having them all come together in a world is going to be awesome. We saw during the tournaments that there is not a single best spaceship design and many different strategies are competitive. The ship sharing feature should create a feedback loop that keeps the game fresh and interesting for a long time.

Tutorials and Introduction

Reassembly is a complex game and introducing new players of all skill levels gracefully continues to be something we work on. We want to be respectful of player’s time and intelligence, providing guidance where confusion and frustration would otherwise result but without being patronizing. The paying beta players that will soon descend on the game should have as good of an initial experience as possible.

Steam Integration

The goal is to do the Beta release through Steam Early Access. This will let us take advantage of the updating, crash reporting, cloud saving, etc. functionality built into Steam. This will save us a lot of work in the long run but it will take at least a week to integrate the steamworks API and set up the storefront page.

Conclusion

These features should keep me busy for the next month. There are also several features that are planned for final release but will be added in the beta period: new block types, gamepad support, improved AI, more polished graphics, etc, etc. The great thing about an open beta is that we will be able to respond to player feedback and improve the game. Feedback from alpha testers has been integral to getting the game to where it is today.

PAX Prime 2014 Postmortem

Submissions for PAX East 2014 are opening soon so I thought I would write up my experiences showing Reassembly at PAX Prime in the Indie MEGABOOTH Minibooth last month. The MEGABOOTH was a very positive experience for us – in addition to having a great time we launched a kickstarter campaign the day we got back and successfully raised $35,000 to finish the game.

Background

I (Arthur) wrote Reassembly and run Anisoptera Games. I’ve been working on Reassembly full time for about a year and a half, before that I worked at Nvidia. Peter Brown composed music and sound effects for Reassembly. Colin, Rob, and Christine from Indie Voyage ran the kickstarter and are helping out with PR, marketing, QA, and production. We shared a hotel with my friend Greg Batha who was showing Bit Bit Blocks at the Minibooth. All of us have been to gamedev conferences before but this was the first time exhibiting for any of us.

Minibooth

10356397_710346275712442_4268586593046816684_n

Peter demos the game at our booth


Willy Chyr has written a really good overview of the Minibooth setup which I will not duplicate.

In preparation, Colin and Christine hand emailed approximately 200 journalists and youtubers resulting in ten interviews during the show. The Indie MEGABOOTH provided a press list which was invaluable here. We had a number of impromptu interviews as well, possibly as a result of this outreach. We also organized a press dinner with demos for several more people.

We designed and printed official game t-shirts for ourselves as well as postcards to give out. Having never done this before we followed the guide at Indie Boothcraft. I also recommend Indie Hangover’s five part guide to getting the most out of a convention and Andy Moore’s guide to PAX on a budget (Also his latest game ROCKETSROCKETSROCKETS is really really good).

Cost breakdown

The table below details our booth costs excluding travel, lodging, and meals (which cost us about $3000). All told team members spent about $5000. The Indie MEGABOOTH provided the kiosk itself, placard, computer/monitor/keyboard/mouse, and 3 exhibitor passes. Colin had an additional 4 day expo pass through speaking at PAX Dev.

We also brought a pair of headphones.

Item Cost
Indie Minibooth $1400 for 4 days
T-shirts $400 for 12 (nice) shirts
Postcards $216 for 2500 postcards
Fliers $0 for 10,000 fliers (via cross promotion with Indie Hangover)
Press Dinner ~$120 in Pizza and Beer
Water, Granola bars ~$30

We gave out approximately 95% of the postcards and about half the fliers. It’s hard to measure how many people actually visited our website as a result of this, but we assume it was some. It was convenient to have something to hand people interested in the game.

Reassembly was miraculously nearly bug free throughout the expo. The game is written in C++, is multithreaded, and is still in an alpha state so embarrassing crashes were something I was very worried about. Right off the bat we had a flickering problem with the Adaptive VSync implementation in the game and had to do a new build to turn it off. Luckily I had brought my laptop and this took only five minutes. We did have a couple hard crashes and general gameplay bugs but by and large our bug fixing paid off and everything went smoothly. The machines provided by Indie MEGABOOTH were extremely fast and we had no performance problems whatsoever.

We had 5 people working to make our booth a success: Arthur (me, developer), Peter (composer), Colin and Christine (Indie Voyage), and Yoonah (Arthur’s wife). Manning the booth turned out to be extremely exhausting even with this many people and having the ability to take breaks was essential. Talking to hundreds of players was also very dehydrating – we went through two 24 packs of water bottles (and a number of red bulls). Through some combination of sleep deprivation, overexertion, and constant contact with large numbers of people I also ended up contracting the “PAX Plague” and spent the last two days sniffling. All that said it was very exhilaration – PAX is full of amazing things and we were all glad to get a chance to enjoy the rest of the show.

Lessons

Exhibiting at PAX was extremely valuable for us, both personally and for our fledgling business. The legitimacy and publicity that being a part of the MEGABOOTH brought and the contacts we made with press and other developers were instrumental to the success of our Kickstarter and will continue to be greatly valuable.

For me (Arthur) personally, having spent more than a year writing a video game in a very solitary way, the chance to show it to hundreds of people in person was extremely rewarding. Being able to talk to other MEGABOOTH developers from around the world on approximately even footing was just amazing and inspiring. I shared a kiosk with Samantha Kalman showing Sentris and Paul Greasly showing A Fistful of Gun and they were both extremely welcoming, friendly, and interesting. Two different fellow r/gamedev screenshot saturday’rs came to the booth to say hi. Part of the Minibooth package included invitations to a number of parties with free food, alcohol, and the chance to informally network with other developers and with representatives from Valve, Sony, etc. It is hard to overstate how much work five minutes of talking to the right person can save. I have been to GDC and related parties a number of times but being part of the show was a completely different experience.

On the show floor, explaining the game succinctly over and over again and watching people’s reactions completely changed how I though about the game myself. Many things I thought of as core features turned out to be irreverent or too complex to explain, and things I thought of as trivialities turned out to be very significant to people. It is very easy to completely loose perspective on a project and showing it to new people is the solution. Every single person at PAX was positive and helpful – people who aren’t interested in your game will simply play one of the thousands of other games.

The tutorial we had built into the game turned out to be almost completely useless in the distracting context of the expo floor, and the progression rate at the beginning of the game was too slow for new players to experience the breadth of the game in the short time they had available to play. We ended up loading players into a mid-game save game and walking them through the controls in person. We lost the chance to playtest that first critical part, but have a much better idea of how to fix the tutorial and teach players to play.

I had read about Alexander Bruce (Antichamber) and other’s experience playtesting their games at conventions and was excited to try this out with Reassembly. Reassembly is a very sandboxy game though – there aren’t specific parts of the game that are trying to elicit specific emotions from the player. Rather it’s an interesting world that generates open ended circumstances that you can interact with on a variety of levels. I learned a lot about the UI – this is awkward, this is confusing, this is intuitive. Many people shared suggestions about the game, new types of weapons or armor, strategies for procedurally generating spaceships. I got a much better idea of what kinds of people are interested in the game and why (lots of software engineers, for some reason…). Overall it was more of a mind-expanding experience than a focused playtest.

DSC_0280

Arthur and Peter on the official PAX twitch stream


We were selected to appear on the official PAX twitch stream for a ten minute interview on the third day of the show. This was quite an experience and I was frankly terrified beforehand. When I started working on Reassembly it did not occur to me that “being on tv” would be part of the process. Luckily our host, Justin Flynn, turned out to be extremely charismatic and Christopher Floyd from the MEGABOOTH team offered some perfectly targeted words of encouragement. Having spent two full days explaining the game to people, we were vastly better prepared than before PAX and it went smoothly.

Stay tuned for a Part 2 discussing our Kickstarter.