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.

This one macro trick for easy data definitions

Commonly cited advantages of dynamic languages like Javascript or Python over C/C++ are the ability to easily mix data definitions with code in source files and to introspect classes and other code structures as if they were data. Standard C++ syntax also often requires duplicate and otherwise annoyingly verbose syntax when declaring many similar objects.

Thankfully, as with many other problems, we can overcome these limitations by creatively using the C preprocessor. Contrary to prevailing C++ doctrine, I believe that cpp macros can be the most concise, easy to understand, and high performance way to solve certain problems. With a little functional macro programming we can define reflective structs and enums with zero overhead.

Let’s say we are writing a game about building spaceships out of blocks. We have a class to represent the persistent data for each block, and we want to be able to serialize and deserialize that class, but we also read the fields of this class a gazillion times each frame and need them to be normal struct members – we can’t use a hash table or something instead. We also add or remove members frequently and don’t want to have to change the code in six places every time we do this. Here is a simple way to accomplish this.

(Note: This is simplified code from Reassembly – I hate iostreams and am not actually using them in Reassembly but for the sake of exposition it was the simplest way.)

That’s it. Now we can add and remove block fields without having to update the serialization routine. We can manipulate the struct fields any way we want by writing new macros and passing them into the field declaration macro. Useful examples include parsing, resetting fields to default, operator==, or listing struct fields for purposes of tab completion.

Another useful application is reflective enums/bitfields.

At the risk of pissing off both the Effective C++ crowd and the hardcore C crowd I will introduce an elaboration using templates and the visitor design pattern for better generality. We define a function called getField(object, name) that returns the value of a reflective struct field given by name. We can use the same technique to parse/serialize arbitrary structs, list members, generate UI for editing structs, etc.

The actual game code for this is on my github repo, together with some convenient macros for defining reflective structs and enums.

Reassembly Standalone Ship Builder


The standalone ship builder is a self contained version of the complete spaceship editor component from the full game. It comes packaged with a few tracks from the full soundtrack and all the ships from the last two tournaments to try out and test your creations against.

To enter the tournament, just upload your creations to the Tournament Ship Submission Page. Everyone is welcome!
Complete rules and discussion on the forum post.

Don’t forget to back our Kickstarter!

Ship Contest!

As some of you may know we held a ship design contest where the goal is to design a ship that can fight against other player’s ships in an asynchronous AI controlled multiplayer battle.

We had a lot of great submissions from alpha testers and we are running the actual contest live on twitch in about 20 minutes.

You can see it live here: twitch.tv/manylegged

We will post a recorded version on Youtube later and edit the link in.

Edit

The competition is complete! There were some dramatically close battles and unexpected upsets, everyone learned a lot about building ships, and we have a list of AI behaviors to improve! Thanks everyone for submitting ships and tuning in. We will be posting the results and recording soon.

The Crusier category finals were postponed due to technical difficulties – we will finish running them soon!

Here are screenshots showing some of the entrants. Protohara Probe Mk. 2 narrowly defeated Protohara Drone in the Probe category (both Protohara proton beam’d the rest of the probes without difficulty), while Ontos very narrowly defeated BATTLEDEATH in the Dreadnought category after several changes in position.

Screen Shot 2014-08-25 at 7.16.54 PM

Screen Shot 2014-08-25 at 8.04.41 PM

Indie Megabooth / PAX Prime

We are excited to announce that we will be showing off Reassembly at the Indie Megabooth at PAX Prime at the end of August, just a few weeks away! We will be at kiosk 19 of the Minibooth section – if you will be at the convention come say hi, try out the game, and grab some fliers.

Reassembly in the Press

* Indie Hangover is streaming Reassembly RIGHT NOW on twitch
* Let’s Play from SpaceMonkey9288
* Screenshot roundup on Indie RoundUp
* Screenshot roundup on REGRETZERO

How to fix color banding with dithering

Update: Since found a much more in-depth presentation on this topic titled banding in games by Mikkel Gjøl.

Color Banding

Computers represent colors using finite precision – 24 bits per pixel (bpp) is standard today, with 8 bits for each of red, green, and blue. This gives us 16 million total colors, but only 256 shades for any single hue. This is typically not a problem with photographs, but the discontinuities between representable colors can become jarringly visible on gradients of a single color. This artifact is called color banding.

Space games often have dark gradient backgrounds and thus suffer from visible color banding. Games following in the tradition of Homeworld 2’s gorgeous vertex color skyboxes are particularly afflicted compared to games with texture art because the gradient is mathematically perfect and there is no noise to obscure the color bands.

Here are some screenshots from a few games showing the effect. Make sure to click through to the full size image and verify that the color bands are indeed typically only one bit apart (DigitalColor Meter on OSX is great for this). The color banding is easier to see in a dark room.

Homeworld 2 (R.E.A.R.M.)

Homeworld 2 (R.E.A.R.M.)

Obviously these games are still incredibly beautiful! I just wanted to point out that many popular games exhibit visible color banding despite the existence of well understood solutions. Color banding in Reassembly bothered me enough to fix, and I thought that the solution was simple and effective enough that it should be more widely known.

Dithering

As mentioned above, color banding is caused by 24 bit color being unable to perfectly represent a gradient – the limit of color resolution. We can increase color resolution at the expense of spacial resolution via a process called Dithering. Since we are just trying to draw a smooth gradient and don’t care about spacial resolution, this is great. Dithering takes advantage of the fact that a grid of alternating black and white pixels looks grey. Please read the wikipedia article for a full explanation, and see also Pointalism for an early application.

dither

Bayer Matrix

There are a lot of fancy dithering algorithms but I chose to implement Ordered Dithering via a Bayer Matrix because it can be done efficiently in the fragment shader. The basic idea is to add a small value to every pixel right before it is quantized (i.e. converted from the floating point representation used in the shader to 8 bits per channel in the framebuffer). The idea is that the least significant bits of the color that would ordinarily get thrown out are combined with this added value and cause the pixel to have a chance of rounding differently than nearby pixels. Bayer Dithering takes these values from an 8×8 matrix which is tiled across the image.

I store the Bayer Matrix in a texture which I sample at the end of my fragment shader. Here is the code to generate the texture. Note that we enable texture wrapping and nearest neighbor sampling and are using a one channel texture.

Then at the end of the fragment shader add the scaled dither texture to the fragment color. I don’t fully understand the 32.0 divisor here – I think 64 is the correct value but 32 (or even 16) looks much better.

That’s it.

It’s important that this happens in a shader where the full gradient precision is available – if you do it in a post processing shader reading from a 24 bit color buffer it won’t work. In Reassembly I actually do it in two different places – in the tonemapping shader which reads from a floating point render texture and in the shader that draws the Worley background.

[Reassembly]_Screenshot_(20140808)(03.59.40.AM)[606x500]

Background halo with color banding

[Reassembly]_Screenshot_(20140808)(03.59.59.AM)[606x500]

background halo with dithering

[Reassembly]_Screenshot_(20140808)(04.00.35.AM)[606x500]

shield with color banding

[Reassembly]_Screenshot_(20140808)(04.00.45.AM)[606x500]

shield with dithering

How to prevent dangling pointers to deleted game objects in C++

Early versions of Reassembly were plagued with crashes due to game object lifetime problems. For example, the object representing the AI for a first spaceship would have a pointer to the enemy spaceship it was targeting. If the targeted spaceship was destroyed (and the object was deleted) the first spaceship could cause a crash the next time its AI ran. Alternatively, various parts of the user interface reference the player’s spaceship object and then crash when the player spaceship is destroyed and its object deleted.

There are a lot of potential solutions to this problem. We can delay deletion of doomed objects for a few frames and any code that references these objects can check if they are still alive before using them. We can traverse any objects that might reference a game object every time a game object is deleted and NULL any pointers to the deleting object. When there are many types of game objects and they all reference each other in erratic and complicated ways this can quickly become burdensome.

My eventual solution was inspired by an article on Coding Wisdom recommending the use of “Watchers” and arguing against reference counting smart pointers. To quote from the article:

  1. Create a base class “Watchable” that you derive from on objects that should broadcast when they’re being deleted.  The Watchable object keeps track of other objects pointing at it.
  2. Create a “Watcher” smart pointer that, when assigned to, adds itself to the list of objects to be informed when its target goes away.

This is the sort of thing that is probably common knowledge among AAA game programmers but was not obvious to me. I implemented this suggestion and it has worked out really well.

Implementation

My version is available on on my github in stl_ext.h

  1. Game objects that will be pointed to should inherit from Watchable.
  2. Objects that store a reference to game objects should declare the pointer as watch_ptr<GameObject> m_ptr;. m_ptr will automatically become NULL when the pointee is deleted. watch_ptr is a smart pointer so use is the same as GameObject* m_ptr
  3. watch_ptrs are only used when the pointed object may be deleted while the pointer is stored.

It works by adding each watch_ptr to a doubly linked list, with the list pointers stored in the watch_ptr itself. When the watch_ptr destructs, it removes itself from the list. When the Watchable object destructs, it traverses the list and NULLs all the pointers.

Threading

Obviously the doubly linked list traversal is not thread safe. Reassembly uses two main threads, a render thread and a simulation/event thread, with a few more workers. There are a few rules for safe usage.

  1. When the update thread is done with the object, NULL all references to it (call nullReferencesTo()). This will prevent any further references to the object from that thread.
  2. Only delete game objects that need to be referenced by the render thread from the render thread. This is often necessary anyway because destroying these objects can also delete OpenGL buffers, which must be done from the render thread. I push ready-to-delete objects in the update thread to a queue, then delete at the end of the render thread frame.
  3. Always copy the watch_ptr to a normal pointer before checking NULLness when using from the render thread. This will prevent the update thread from NULLing the pointer after the NULL check but before the render thread is done with it. Since the render thread will not delete the object until the end of the frame, we don’t have to worry about referencing free’d memory

Name Change, Alpha Progress

We decided to change the name of our game from “Gamma Void” to “Reassembly”. The new name is more specific, descriptive, and meaningful and we think better is a better match. We also wanted to avoid confusion with several other games which also have the word “Void” in their title, in particular modular spaceship building games “Kinetic Void” and “Void Hunters.” Our website will be updated over the next few days to reflect the change and the next alpha build will have a new title screen.

Reassembly

A few people have contacted me asking when the next alpha build will be going out and whether they are included in the alpha program.

The plan is for the next official alpha build to go out some time in August. If you are on the alpha list you will get an email, and I will also make a post here. If you emailed me about the alpha build and I haven’t responded yet, don’t worry, I will go through everyone before sending out the email. No one has been removed from the alpha list.

Colors

I put a color picker in the new-game-screen to allow personalizing your faction. I’m excited to see what people come up with!

Color picker
hot topic spaceships
acid green and dark purple

Happy accidents

I love it when bugs turn out to have really cool effects. I was messing around with the HDR effects rendering and accidentally stopped clearing the floating point weapon and particle effect FBO in between frames, so the effects just pile up. Probably not something I can use directly in the game, but cool enough to share.

Screen Shot 2014-04-30 at 9.00.38 PMScreen Shot 2014-04-30 at 9.07.04 PM