E3 is as big as it gets when it comes to game conventions and INVERSUS will be joining the party. Chosen from hundreds of applicants, the it is part of the IndieCade showcase. I’ll be flying down to Los Angeles to demo the game each day alongside a TV, four controllers and a couch. If you’re attending E3, I look forward to seeing you!
Indie MEGATRAILER @ E3
What if you are in Los Angeles, but don’t have an E3 badge? I’ve got you covered. INVERSUS will be freely playable for the public on Thursday June 16. The folks over at Indie MEGABOOTH will have a trailer set up just across the street from the convention in the Devolver Digital area. There are new games on display each day and you can check out the full schedule here.
BIG Festival 2016
I’ve shown the game all over the U.S. and it’s time to let it explore more of the world. From June 25th through July 3rd, INVERSUS will be showcased at the CCSP in São Paulo as part of Brazil’s Independent Games Festival. It’s also up for the Innovation award! I won’t be able to personally attend, but if any of you are there, be sure to tweet me some pictures!
Just this past weekend INVERSUS was one of the five winners in the Indie Game Award Showcase at MomoCon. While I was here in Washington trying to finish up the game, judges from Kotaku, Destructoid, Geek & Sundry, and Vlambeer had a great time playing it. I’m flattered and will be making time to visit MomoCon next year!
We’re pretty deep into this thing and I haven’t even talked about the game itself.
If you follow @InversusGame on twitter, you’re well aware that I’ve been heads down in online multiplayer tech. I’m happy to say that the forecast is clear and sunny. Check out this online co-op! With the help of friends in Germany and Japan, I’ve been stress testing worst case lag scenarios. Week by week the experience is getting smoother. It’s finally fun from opposite sides of the world which is a huge feat given how fast paced and twitchy the gameplay is. While Mr. Physics and his so-called “speed of light,” won’t let it be perfect, by improving the worst case, I’ve made the average case hard to discern from a local match.
Everyone has been asking for it, and I’m excited to say that INVERSUS is going to ship with online multiplayer! You no longer need a group of friends on the couch to play competitively. Even more exciting, I’ve already got the core of it working on Steam. Click here if you want to see a gif recorded from the first online match. It uses a rollback system similar to a modern fighting games and already plays great!
All that said, there is some new work ahead. I need to get the networking functional on PS4, add support for friend invites, handle four player matches, and deal with tons of error cases. I also want to try online co-op arcade mode (fingers crossed)! As a result, the release date is getting pushed out to late summer. The wait will be well worth it, however, and I appreciate your patience.
PAX East 2016
PAX East is right around the corner, andINVERSUS will again be joining the Indie MEGABOOTH! I had a great turnout with IMB at PAX Prime last fall, and can’t wait to meet everyone on the east coast this time around.
If you’re attending, stop by, say hi, and play a few rounds. I’ll be there all three days. Check out some more of the IMB selection in the trailer below.
Best of the MIX
I got to show the game at IGN this month as part of the annual Media Indie Exchange event and it was a hit! Judges Mitch Dyer of IGN, Mary Kish of GameSpot, and Alex Austin of Cryptic Sea Studios put INVERSUS as runner up for best game out of nearly 50 titles.
What better way to finish this off than a list of random stuff that’s been happening?
SXSW was a blast. I got to show the game to tons of new people and even did a live broadcast demo on the Twitch.tv stage. If you missed out and want to see me try to function on camera, I also did this short video interview with Chris Watters of GameSpot.
I opened a new Twitter account specifically for the game that is easier to search for than the company account. You can follow @InversusGame.
PCGamer had some great things to say in their roundup of local multiplayer games they saw at GDC. “Inversus is one of those games you play for less than 30 seconds before you’re totally sold and mumble something like ‘oh [expletive], that’s cool’ and feel slightly ashamed about your own contributions to the world. “
When a game supports controllers, the player is likely using an analog stick at all times. Nailing the input processing can have a substantial impact on quality throughout the experience. Let’s walk through some core concepts along with examples from INVERSUS.
Before tuning the analog stick, you need to know how it works. What is the hardware actually reporting when you move the stick around? Here’s what the stick inspection for INVERSUS looks like. I don’t claim this to be the best possible display, but all the conveyed information is important.
Before I cover each part in detail, let me present a high level overview. I was using an Xbox 360 controller attached to a PC. The top row represents stages of processing on the left stick. The bottom row is the right stick. You’ll notice that the top row has more data on display than the bottom row. This is because INVERSUS only uses the left stick and it gets special treatment. I’ll only talk about that top row from hear on, but everything still applies to the right stick for games that use it.
As of this morning, INVERSUS has officially been announced for PlayStation 4 and will be available for download on launch day. I got to write up a post for the PlayStation blog introducing everyone to the game. You can check it out here.
I’ve graduated from the old Steam Greenlight page to anofficial store page! You can click on that link to follow the game on Steam and pick it up the moment it’s released. Steam also creates their community hub for every game so INVERSUS now has Steam discussion boards and everything else. They haven’t really kicked off yet, but they are there and ready for when the game launches.
Trailer and Soundtrack
In preparation for the PS4 announcement, I updated the trailer (see below). I kept the message but polished it all up a bit and replaced all the gameplay and music.
First off, the music in the trailer is now actually pulled from a track that will ship with the game. I was previously using some free music byLyvo and when I contacted him about it he was really interested in writing something custom. Many months later, we now have a finished soundtrack which really keeps the energy up in game!
You might also notice some new levels and 2v2 versus battles in the trailer. The 2v2 mode is a huge hit when testing and leads to some great variety in chaos and tense comeback plays.
Last month’s visit to Washington D.C. for Indie Arcade was a big success. Close to 12,000 people showed up. Next month, I’m heading back to Austin, TX for SXSW because INVERSUS is nominated for the Gamer’s Voice Multiplayer Award!
I’ve been playing around with multiple players on a team. Two players fending off the enemy swarms of arcade mode looks to be a hit! I’ve also tested three and four player variants, but they get a bit too chaotic at the moment. Luckily, I’ve got some more tricks up my sleeve to help clean up the issues.
In the meantime, here’s some brand new co-op game play:
Indie Arcade: Coast to Coast
I’m heading back out on the road with the game. I’ll be at theSmithsonian American Art Museum in Washington D.C. as part of Indie Arcade: Coast to Coast on January 16th. It looks like I’ll finally get to visit the capital! Hopefully Obama stops by for a couple rounds. I’m sure he’s a big INVERSUS fan.
So when can I play INVERSUS?
Late spring is looking promising; I already have the game up and running one console and have started in on the others. I’ve also got my localization frame work functional. It can even handle non-Latin characters (check out that Japanese menu to the right)! This is extra exciting from the dev side of things. There is still a good pile of work to finish, but it’s finally just a pile and no longer a mountain.
I have long been interested in the ramification of control schemes on a game design, and I hope this post helps demonstrate the importance of subtle input nuances. I also want to present an example of the work, thought and exploration requires when designing a responsive interaction.
INVERSUS has two core attacks. A quick tap of the fire button will shoot a single projectile. Holding the fire button will charge a shot and if the player holds long enough, three lanes of projectiles are shot.
Only the normal shots were implemented when I started making the game. When a fire button was pressed, a projectile was released. Life was simple. Things changed when I decided to implement the charged shots.
The charge mechanic adds substantial depth to the game (perhaps I’ll dig into that in a future post), but comes with a significant cost. In order to detect an uncharged shot versus a charged shot, I need to evaluate how much time has passed between the button being pressed and the button being released. This means that I can no longer spawn the normal single-lane projectile on button press. I need to wait until button release. As a consequence, the game gained a negative user experience in perceived input lag (the extra time it takes a player to release the button after press).
How bad is it?
The amount of time it takes to press and release a button varies from person to person, and varies according to the conscious effort made to actually release the button as fast as possible. Let’s say it takes the average player around 0.15 seconds (which I believe to be a reasonable estimate). This might be only a fraction of a second, but it creates a noticeable input lag between the player’s intent and the game’s response on screen. Subtle differences likes this can make or break a game’s satisfying feel.
Currently, I have projectiles moving at 11 tiles per second. How far will a projectile move during the additional 0.15 second delay to detect a button release?
When under attack in INVERSUS, projectiles will collide with one another and cancel out. This encourages the player to shoot at incoming projectiles to block them. Given the above math, we can see the impact on the experience. If a bullet is moving towards your ship and you pressed the fire button when it was within 1.65 tiles away, you likely won’t release the button in time to block. You might also curse the screen when you subsequently explode and lose the round.
The player controlled ships move at a speed of 10 tiles per second (slightly slower than projectiles). How far will a ship move in the estimated 0.15 second input lag?
Players often move perpendicular to the direction of fire. For example, the player might be moving from top to bottom while lining up a shot left to right. Due to the input delay, we can tell that a player moving at max speed needs to start the press-release motion 1.5 tiles early. This is going to cause a lot of missed shots and frustration when the player isn’t stationary.
Finding a solution
I knew this was an issue the moment I added charged shots, but I also wanted to evaluate how they played before just dismissing an on-release input scheme. With the charge mechanic being such a strategic success, I’ve lived with the input delay for close to a year and half. That whole time I’ve been mulling over potential solutions and being reminded of the issue watching play tests. I recently had to prep a new build of the game for submission to the IGF and SXSW festivals and used this as my motivation to finally tackle the issue.
I have always viewed the delay in blocking incoming projectiles as the larger problem. When this one goes wrong, you lose the match almost instantly. There isn’t much worse of a response.
My long considered plan for fixing this was to do more than just firing a single projectile on button release. I wanted to also fire a small pulse wave on button press. I hoped that on a quick tap the two would trigger close enough to look as one element aesthetically. If you held the button for a while, the two would be separated. On press, the little pulse would come out. On release, the normal bullet fires. If the short pulse wave lasted long enough to cover the input delay, it could be used to block a shot in these frustrating cases.
Prototype 1: Hold to block
When it came time to prototype the solution, I decided to start with a variant that was a bit simpler. The INVERSUS input layout has a separate fire button for each direction (up, down, left, right). When deciding to charge a shot, you need to choose a button and commit to a direction at the start of the charge.
I made it so that when in the charging state (the time between button press and release) the player will block an incoming shot from the charged direction. Once a shot is blocked, the charge is canceled and the bullet is forfeit. An interesting side effect of this mechanic was that it placed even more pressure on your opponent to flank.
The results were promising and the problem cases no longer resulted in a death. It initially created an odd state where the player might still hold down the charge button throughout a block. Because the ammo is consumed and the shot is canceled, players end up in a state where a button is held but the game isn’t reacting. To fix this, I made the next shot start charging automatically if the player doesn’t release the button after a short time.
The remaining issues were in visual communication. INVERSUS has a specific minimalist art style that is not conducive to small details. The new blocking system asked for a directional shield to be communicated on the ship, but it couldn’t compete with the other communication channels from power-ups and ammo counts.
I never found anything perfect, but here is a subset of concepts I tried out:
Prototype 2: Pulse on press
My next prototype was based around the pulse concept I had initially conceived. On button press, I shot out a slower projectile with a very short lifetime. On release, I shot out the standard projectile. Once again, this solved the desired problem. It also introduced a really fun parry mechanic because if you intentionally timed your press such that the pulse blocked an incoming projectile, your button release would then be able to shoot your projectile unimpeded. Unfortunately, it also came with a new set of issues.
The pulse is detached from the ship and due to the high speed of the ship, the ship can quickly move into or away from the pulse. When moving over the pulse, the visual language gets messy. When moving away from it, it creates this odd effect of both visually lingering in space and still being able to block a bullet.
I followed this up with a slight variation in which the pulse is positioned relative to the ship. If the ship moved, the pulse moved with it. This read much better in the common case, but it meant that when the player moved up against a wall, the pulse could draw out of bounds. The myriad edge cases led me to move onto a new prototype.
Prototype 3: Shoot on press
It had been a long time since I played the game with the charge shot completely removed. I decided it was worth revisiting this simpler system now that so much else surrounding it had been refined. It felt great. Really great. However, the strategic depth and player expressiveness took a huge hit. In the end, it was worth playing in this state for a while to remember the quality bar I wanted to achieve.
Prototype 4: Shift to charge
The next prototype involved modifying the control scheme in an attempt to get the best of both worlds. I made it so that fire buttons would launch a projectile on press by default, but if you were holding down a “shift” button it would change the functionality to allow charging. The end result was a cumbersome interface that felt unnecessarily complicated.
This also needed smart input chord detection which was not compatible with the other design constraints. To be more specific, a player will often press the shift button and a fire button at the same time with the intent to start a charge shot. For this to work well, you need to detect the fire button being accidentally pressed a hair prior to the shift button. Unfortunately, the whole goal of this is to get the projectile launch immediately on press. Canceling it on a late chord detection also won’t work due to how fast the projectile travels.
Prototype 5: Separate charge button
Taking a slight spin on the “shift to charge” system, I tried changing the shift button into a charge button. In this world, holding the charge button (assigned to one of the shoulder triggers) would immediately cause the ship to charge up without requiring the player to pick a fire direction. Once fully charged, pressing any of the fire buttons immediately launched the triple lane shot in the appropriate direction.
It actually felt pretty good using the trigger input for charging up, but mechanically this system was not viable. Without the penalty of committing to your fire direction at the start of charging, players were strongly encouraged to always be charging. Removing the return on investment style choice from the charge mechanic negated all the strategy that made it worth keeping.
Prototype 6: Fire and then charge
If the projectiles moved slower, there would be a solution in which the single lane shot is launched on press, but then canceled if the player continues to hold the button. I could then transition to the charged shot that launches on release. However, the projectiles move so fast that they go too far for a reasonable cancel period (about 1.65 tiles according to the earlier math).
With that ruled out, I decided to try a system where on-press would fire a single lane shot and continuing to hold the button would charge up the next shot. This felt great in the tactile sense, but created very awkward choices in game. Players would often waste one ammo just to gain the ability to charge the following shot. It made players immediately question why anyone would ever design a game with such a weird control scheme.
Prototype 7: Hold to detonate
At this point I decided to reevaluate the whole charge thing and try some alternate replacements that would control better. I started with single-lane shots firing on button press. If you continued to hold the button, it would prime the in flight projectile for detonation. By releasing the button before the projectile hit a wall, it would detonate early in a small explosion. This felt fine and added an interesting skill path, but was far too powerful (hitting players around cover) and presented the player with far less interesting strategic choices.
Prototype 8: Direction shift
Continuing to explore some new design space, my next attempt also started with firing a single projectile on button press. This time, holding the button down and then sliding your input from one fire direction to another would steer the projectile at 90 degree turns. It was almost like playing the game snake with each bullet. The result was fun to interact with, but the player just focused on the bullet and no longer cared much about movement.
Prototype 9: Parry and riposte
Finally, I arrived at a prototype that I was happy with. It is a melding of the “hold to block” and “pulse on press” prototypes. There is now a brief moment on button press where the player is blocking in the fire direction. This is accompanied by a quick and subtle animation on the appropriate side of the ship.
This once again creates the high-skill parry mechanic that was in my “pulse on press” prototype. Waiting to press the button until just before being hit, lets you block the incoming shot without spending ammo yet. You can then release the button to fire your bullet back. The end result is like performing a parry and riposte if you time your shot correctly. Timing too early results a classic projectile-to-projectile block. Timing too late ends up in taking a hit.
It solves the initial problem case where a player presses the button in time but does not release it and it adds one more interesting choice for players to evaluate. I’d call this a success.
With the blocking issue out of the way, all that is left to solve is the shot delay on lateral motion. In retrospect, the solution seems a bit obvious but it took me a long time to recognize that I could solve the lateral input issue with a separate system from the block deflection issue.
When the player presses a fire button, I track the current ship position. If the player releases the button quickly after pressing it, the projectile launch position is adjusted to match the press position, but only along the axis perpendicular to the fire direction.
If you are moving towards or away from the direction you are firing in, the projectile firing works just like it always has. The projectile will never spawn inside of you and it will never spawn far ahead of you.
If you are moving laterally to the firing direction, the projectile position is set to where you were just a moment ago (in the lateral direction). You can now line up those shots better.
The correction is applied at 100% if the button is released within 0.11 seconds (i.e. the projectile is fully shifted to the on-press location). The correction fades out to 0% at 0.19 seconds. This prevents any odd discontinuities when hold times vary slightly.
It still doesn’t feel as snappy as a fire-on-press system, but it is far closer. Skilled players sensitive to timing won’t feel cheated by the game and new players learn to time their shots far quicker.
The biggest missing piece is improving the feedback of the parry to celebrate the player skill and separate it from normal projectile-to-projectile collisions. Right now the sound is different (although not great) and the visual effects are reused.
I just got back from visiting Bit Bash in Chicago where INVERSUS was on display . This was the both the biggest festival INVERSUS has been to and the biggest screen it has been played on. The number of attendees was in the thousands and the game was set up on this giant projection screen.
It was showing on the far side of the festival floor and attendees couldn’t see the screen when first entering the space which was unfortunate, but they could see this rad He-Man themed half pipe with Omnibus on display, and that helped draw people into view of INVERSUS.
There was also plenty of room to build a line and watch the current match!
Later in the night, there were a bunch of DJ sets in the center of the room to draw in a crowd and play the game under the atmosphere of a smoke machine.
With Bit Bash volunteers manning the game, I got to sit back and observe. It is likely that more new people played the game there than have ever played before. I took a bunch of notes about potential improvements to add to my ever growing list; now I need to figure which, if any, to tweak before PAX next weekend.
INVERSUS was greenlit on Steam yesterday! Prior to starting the greenlight process, I was rather curious about what to expect and what I should be doing. Thus, I read a bunch of postmortems about other games’ experiences in the process. People say it is far easier than it has ever been and perhaps another postmortem isn’t of great use, but I still want to return the favor and give future devs another reference point.
Prior to this, I was familiar with the concept behind Greenlight and some general DOs and DON’Ts, but I hadn’t ever really dug into the actual system and viewing games inside it. My biggest surprise was how large of a quality range you can find in the submissions. There are a number of unpolished projects and stepping out of that band is the best way to separate yourself.
INVERSUS has a very minimalist art style that has had a ton of thought poured into it, but I am prepared for a segment of the mass market to have a hard time differentiating it from the plethora of blocky indie games out there. That said, on Steam Greenlight, almost 100% of my feedback was glowing. This was not due to an extensive prior community around the game and it was not due to any internet coverage. It was almost entirely due to presenting a product that showed a high level of craft.
Let’s dive into how the game actually performed and then we can go over some of the parts that helped it get there and how I feel about it all.
The game had 6,289 unique visits to the page. 5,288 of those visitors actually voted. 3,294 of those votes were “Yes” when presented with the question “Would you buy this game if it were available in Steam?”. This is the percentage breakdown of the voters.
The game was greenlit in a span of eight days. This is the graph directly from Steam.
Below is a touched up version of the graph to better represent the time period the project was actually live. I flipped the switch a little before 1pm on a Sunday afternoon and got approved around 3pm on the Monday eight days later. From what I could gather the greenlight clock would actually flip days around 5pm my time (PST).
The most obvious takeaway here is that you get a really large bump of views at the start. No one has rated your game yet so it will get into more queues and you are on the front page. I was also lucky enough to hold a spot on the front page for 3 whole days. This is entirely based on how many new games are getting submitted after yours.
I also found it interesting that I got a bump in views on the Sunday before approval. Being curious if somewhere online was responsible for linking to the page or if it was just normal steam activity I checked in with the Google Analytics. Steam lets you link into Google’s system which is a great feature and I recommend doing it. First off, it is worth verifying that everything is working and as you can see in this similarly shaped graph from google it seems likely.
It turns out that almost all of my traffic every day came directly from within Steam. The only referrals that were even noticeable were about 100 from twitter, 50 from facebook, and 50 from a greenlight postmortem that was posted to gamasutra and referenced my page (but it was not responsible for the bump).
As I’m sure you have read elsewhere, you want a good trailer and you want a good branding image. INVERSUS is built onto top of a simple yet novel mechanic and communicating how it works was my primary goal in the trailer. It starts of with a very quick “story” demonstrating how attacks are used for both spatial control and destroying the opponent. I tried to keep the focal point moving at each “chapter” to keep the viewer engaged during what is arguably a veiled tutorial. Once that is out of the way, I kick into fast cuts of actual gameplay knowing that you are better able to appreciate the mechanical complexity of a match.
For the branding image, I wanted something that would catch the eye with gameplay, show competence in my ability to deliver a polished project, and entice the viewer to find out more.
In a continued effort to showcase a bit of class, I used a lot of images in my description section (you can see it here) to breakup the wall of text and make it look like I had more control of the HTML layout than I actually did. I tried to model it after a subset of what is on inversusgame.com and I think it worked out well.
At the end of the day, if you are making a polished game, I think you will be just fine getting through. You don’t even need to focus on advertising outside of Greenlight (although it is a good talking point).
Had someone told me not to worry too much about the process, I might not have agonized over the details as much and saved myself some time and headache, but I also might not have put my best foot forward to the degree that I did. When it comes down to it, just submitting to Greenlight has put over 6000 new eyes on my game and a large number of them are looking forward to it based on what they saw. This is where you will build your initial set of followers on Steam that want to be notified when you actually release. From that viewpoint, I think all the agonizing and polish ends up well worth it even if the game could eventually slip through with less work.
In a previous post about polishing the impact frames when the player slams into a wall, I mentioned wanting to make one more adjustment. The player should stretch just a hair parallel to the wall when it squishes into it. So here is a quick update showing where I’ve ended up for now. And once again, this is a lot harder to feel in a web video than it is in the actual game, but let’s give it a go regardless.
Here it is in motion.
And here are some static frames from the the above video.
On impact, it is only a couple pixels wider, which really helps you feel the collision without making the player feel like jelly from a more exaggerated stretch.