How We Released Our Indie Game Demo
If the title didn’t make it obvious, we recently released our first demo for Intrusion Protocol (vote on Greenlight!). Sounds simple, right? You get your project to a point where it’s playable and put it out into the world. Well, what if there’s a small instruction missing that makes the player have no idea how to play the game? What if there’s a major glitch you just happened to avoid? In my opinion, you have to demo your game with a lot of players in person before you release a demo to the entire internet.
We demoed Intrusion Protocol at a booth at two St. Louis Science Center events before we released to the general public, and I’m so glad we did. The player feedback from those two events helped us identify items that we definitely needed to fix before releasing to the masses. One thing I quickly noticed while demoing is a few spots where we had to give some verbal instruction. “Press this button.” “It may be easier to skip that.” Right off the bat these players showed us things we needed to tweak without even knowing how much they were helping.
Of course, we also got direct feedback from players. While we were nervous to do our first demo booth, we were very happy with the amount of positive feedback we got. Not one person hated the game. Everyone seemed to have the urge to keep going and get to the end, which is exactly what we were going for. However, they also told us things that they thought were unclear, frustrating, or simply not good. Once we collected that feedback, we had a clear list of improvements to make.
Okay, so just add these things and put out the demo. Simple, right? Well, not so fast. Some of these things are easy fixes. Others, not so much. We had a long meeting about what we needed to prioritize. For each item, we had to balance necessity and difficulty. This was the most difficult part of the process. Let’s start with the no-brainers.
Pain border: Players had a hard time telling when they were getting hurt by the enemies. We already had a number that pops up by the player sprite when damage occurs. Adding a red flash around the screen was relatively straightforward. Done.
Spike color: Although we debated (and continue to debate) what the new color should be, actually changing the sprite for the spike is simple. For now, it’s red.
Gravity block: A ton of people playing the demo didn’t see the gravity reversal block at all. It needed to be more intuitive. We debated color changes, but for now we’ve added additional animation in the direction each block changes gravity. Early feedback says this helps a lot.
Pause menu: Although this one required a bit more engineering, it was absolutely necessary. During the live demos, players often found themselves in a situation where there was no way they could finish the level in time, but they had no option to restart. Also, hitting the start button sent you back to the main menu instead of pausing. Yeah, that’s very bad. Even if it was a bit more difficult implement, we couldn’t launch a public demo to the masses without those features. So, we took the little extra time and made it right.
Now we get into the more difficult items. These things required a lot of debate and engineering, and ultimately didn’t make it into the demo. Sure, we would love for the demo to be absolutely perfect, but we also needed to do the big thing that a lot of developers and hobbyists continually don’t do: Actually release.
I’ve talked to so many people in person and online that have been making games for years, but haven’t released a thing. Side projects get picked up, worked on for a bit, then dropped. We don’t want to get stuck in that loop. No, what we release won’t be perfect, but nothing is. Every single game ever made, indie or otherwise, can be improved in some way. Except Tetris, of course.
Remove or modify paths or areas: There’s a spot right at the beginning of the game where the player can go up into a small area to collect a time pip. The problem is that 99% of the time, the pip isn’t worth it. It often takes more time to get to it than the 5 seconds it gives you, and there are lasers that can make you restart at the beginning, costing you a ton of time. We had so many players going after that pip without knowing this.
So why not just take it out? Although Intrusion Protocol is a speed-running game, we want to have certain elements for completionists. We wanted that inconvenient pip to be there for the person who wants to do every single thing they can do in a game. In the end, we decided to leave it, and in the future change it to a hidden secret area.
Tutorial: We went back and forth on this one a lot. We contemplated having a simple overlay at the beginning of the game that tells the player what to do. Left stick to move. Hit the pips. Don’t hit the enemies. The problem is that we don’t want to halt or interrupt the game at all, especially since we are marketing Intrusion Protocol as a speed-runner. Then we thought about adding text to the dead space of the levels as the player passes that area. The text would not appear until the player hit a certain point, and would disappear after they passed. As much as we tried, we could not get it to look and work how we wanted before our demo deadline. We could have pushed the deadline out further, but Intrusion Protocol is a really intuitive game. If you’ve ever played Mario you know how our basic mechanics work. We still want to implement this feature at some point, but it wasn’t feasible for this demo.
There you have it. That was our process for releasing Intrusion Protocol’s first public demo. We had our basic build, got ton of player feedback from the live demos, and then prioritized what we needed to have in the game before our demo release date. All in all, the process was pretty smooth.
Do you have any opinions about our process? Think we could have done something better? Let us know in the comments. See you next week!