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.
On Sunday afternoon, INVERSUS officially entered the fray of Steam Greenlight. For those unaware, Greenlight is community driven method for making a game available on the Steam marketplace. Once passing the Greenlight process, I will gain access to the Steam SDK and be able to start integrating with their ecosystem (achievements, etc).
If you have a Steam account, you can go to this page to vote! So far it’s going really well. All the comments have been positive any we are (as of right now) 99% of the way to being in the top 100 games!
Bit Bash Chicago
INVERSUS is back on the road and the first stop is Chicago on August 22nd. The folks who run the Bit Bash indie game festival were fans of what they saw online and will be setting up a station for the game.
I’m also going to fly out and spend the day. I’ve never been to the windy city before and I think this will be a real fun excuse to visit! The event is at 1260 W Madison from 2-11PM.
Here’s a rad trailer showing a bunch of the stuff you can play if you come by.
I’m thrilled to say that INVERSUS will be part of the Indie MEGABOOTH at PAX Prime this year! This is one of if not the best places to get to show an indie game to the masses and is a really big deal for getting the game out there. This year PAX is from August 28th – 31st at the Seattle convention center. Tickets have been sold out for a long while now so you likely know whether or not you’ll be there.
Specifically, I’ll be demoing as part of the MINIBOOTH section of the larger MEGABOOTH. Just look out for the area with a bunch of kiosks instead of booths and you can find me. I’ll be there all four days. If you want to talk to me when I’m dead tired and have lost my voice, stop by on the final day.
Adding an assortment of subtle polish items to your game is a great way to create that je ne sais quoi that leads to comments about fluidity, feel, and tight controls. Each little bit might not have a huge impact, but the summed result separates you from the crowd.
Inversus has a very minimalist aesthetic and at first blush a build of the game from a year ago might be hard to distinguish from what I have now. However, what I have now looks and feels an order of magnitude better. One of the comments I often get is how smooth the game looks, but its a bit hard to pinpoint why unless you know about all the things to look for. Today I’m going to talk about the most recent one of those things.
I made a new trailer last week which you can see below. The video opens up with the player bashing into a wall. This impact hadn’t received much love prior to recording so I used it as an impetus to spruce things up. When first prototyping the game, player ships would just slide around the screen as static images. Honestly, to most people that is still what it looks like they are doing, but at the same time it “feels” better. One part of that feel is the subtle application of squash and stretch.
I want the ships to maintain their original rigidity. It helps sell the neo-arcade vibe and gives them strength. On the other hand, I want the screen to be very reactive to player input and movement. I want fluidity. To get this balance, I apply a hint squash and stretch. This bit of flavor has been part of player motion for around a year, but it was not part of smacking into walls until last week.
Below you can see the three stages of iteration. In game, this all animates at a smooth 60fps so this isn’t a perfect 1-to-1 representation, but it gets the point across. You might want to block out two of the animations with your hands to help focus on each individually.
Top: Perfect rigid motion (this is how the game started)
Middle: Squash and stretch while moving (this is how the game was for the past year)
Bottom: Squash and stretch while moving and on impact (this is how the game is now)
Let’s take a look at stills from the three most important states.
On the left you can see all three iterations have the same square stationary state.
Once the player starts moving, the later two iterations stretch ever so slightly in the direction of motion and squish perpendicular to the direction of motion. The difference is on the order of a few pixels, but it really makes a difference to how your brain processes the screen.
Finally, at the right bottom you can see the player ship briefly squish up against the wall. Unfortunately, it doesn’t stretch past its stationary width during the squish. Adding a couple more pixels of counter stretch here will likely make this interaction feel even a more natural and I’ll slip that in sometime this week.
If you are passionate about feel and creating satisfying interactions, I suggest looking at each action of your game, no matter how small, and gracing it with with a hint of life.
For a long time, Inversus only featured a single pickup type, the red fast bullet. Let’s talk about some new additions to the team!
Picking up the smash item turns your ship red. You have a few seconds of speed boost and the ability to smash through cells on contact without spending any ammo.
Feedback wise, I’ve added some subtle controller rumble on each block break. The acquisition sound is still the same as for the fast shots and might need to change. The biggest issue, however is that you don’t get any audiovisual feedback regarding how much longer the power lasts. At minimum, it needs some sort of accelerated blink over the last couple seconds.
The shield pickup puts a red border around your ship. It lets you take an extra hit before losing the match.
Currently the shield lasts until the rounds ends or until it breaks from being shot. This is proving to drag matches out and it also makes it less exciting for the pickup to respawn while you are still shielded. The next step is likely going to be turning it into a timed mechanic (similar to the smash pickup but longer). Hopefully, this will force some aggressive risk taking during this period of safety.