It’s common to use an analog input method (control stick, trigger button) to control a digital system. Maybe you want to control menus with an analog stick. Maybe you want to detect a tap or double-tap of the analog stick. Or, as is the focus of this article, maybe you want to fire a bullet with an analog trigger. Getting this right requires more subtlety than you might expect.
While INVERSUS isn’t shipping with shooting bound to an analog trigger, it did start out that way. You can get some insight into why I changed schemes in my article on the parry system (although it might merit its own article), but the important thing to make clear is that it wasn’t changed due to trigger feel; the triggers felt great.
Let’s assume we have successfully preprocessed our controller data and have a clean floating point value from 0.0 to 1.0 representing trigger pressure. Zero represents a released trigger and one represents a fully pressed trigger.
My specific goal was to implement a single-shot fire when the player pulled in the trigger, but I’m going to abstract that goal a bit. What I really want is to translate the analog button input into a digital button input. A digital button is either in a pressed state or a released state. If we can evaluate the same pressed/released status of an analog button then it should be easy to bind it to any game action that takes digital input. For shooting, we can fire the bullet when the state transitions from released to pressed.
So how do we translate our analog button to a digital button?
INVERSUS launches on August 16th for $14.99 on PlayStation 4 and Steam! That’s like, crazy soon!
On top of that, if you’re waiting for the Steam version and just can’t wait one second more to get invested, you can pre-order now for 10% off at inversusgame.com or the Humble Store.
Before you go call all your friends and share the good news, I’ve also got two (yes two!) new game play videos to share!
Excited to fight your friends in versus mode? Check out the latest in INVERSUS competition:
Dying to master the arcade? Here’s the latest in co-op and single player action:
Did you get your PAX tickets? INVERSUS will be there full force as part of the PAX 10! On top of being insanely excited to have gotten accepted, this will also be the first time showing the game after release. I look forward to taking off the training wheels and playing hard as everyone brings their A-game to the booth.
E3, BIG and EVO
So what about all that stuff that’s been happening since the last newsletter? For starters, E3 with IndieCade was amazing. It was full of new faces, fun matches. INVERSUS also had this amazing setup with a couch:
Right after E3 the game was shown in Brazil at the BIG Festival. I didn’t get to attend, but INVERSUS won the Innovation award! I also got to head to Vegas last weekend and demo at the EVO fighting game tournament. It was my first time at EVO, and getting to demo at an event all about competition was fantastic.
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.