I got introduced to AirConsole because of a contest. My team and I liked to participate in Ludum Dare challenges every quarter because making a complete game in seventy-two hours is an awesome way to exercise your game design muscles. So when one of them showed up with some info about a contest associated with the Global Game Jam that had a $5000 top prize, it was a no brainer! After all, with all of practice in the past and my long, and storied career as a game developer, that $5000 prize was going to be easy money. With two separate games getting nominated for Shareware Game of the Year by GamePro magazine in the nineties, I should be able to crush the competition in a month long contest. Of that much, we were all certain. We had this contest won before even deciding on an idea. Let's Go Team!
When w created our cotest entry, our first game for AirConsole, Fight With Friends, we went a little bit crazy. We loved the fact that you could have lots of players. After all, everyone has a smartphone now, right? Fight With Friends supported up to 12 players.
With twelve friends crowded around a 4K HDTV, what could be more fun then some sort of round based combat/competition where you can beat your buddies and rub their nose in it in front of the group? Yeah! A massive, multiplayer arcade style beat down! Perfect!
Of course we will need variety to keep it interesting, so lets base each round on a completely unique retro arcade classic. Quick make a list of all the archetypical video games from the seventies and eighties... Cool! twelve unique games with completely unrelated play mechanics. Good plan. This game was going to be awesome!
And since they are all old-school, our controller is going to need lots of varied button layouts and different trpes of fast action controls. So we should probably just prototype everything using the mouse and keyboard now, and we can just slap together a controller for the phone once we get all the play mechanics implemented. Great! Divide the different mini games up among the team and we are off and running!
You may be wondering why I am telling you about a different game we made in a blog about making Delinquent Miners, Right? Well, the answer is simple: despite years of experience and hundreds of games delivered, I acted like a newbie and did everything wrong. Don't misunderstand me, Fight With Friends turned out awesome. With twelve people crowded around that big screen it really is amazingly fun, if I do say so myself, but it is entirely mismatched to the platform and the target audience on AirConsole. Whether you are writing a novel, or a cookbook, or a flyer, or a video game, the first question every creator should ask is: "Who ais my audience and how will my work benefit them?" We failed to do that in a big, big way.
Let's discuss our mistakes. Ignoring the hubris of assuming we would win, we didn't, virtually every choice we made was a mismatch for AirConsole. Getting twelve players to work in an arcade style, graphically intensive game targeted for WebGL is challenging. It takes more time, lots of optimization, and testing at load requires twelve people to be hanging out with you whenever you work. It would still be worth it if AirConsole customers hung out in large roving herds, but unfortunately the player statistics make it quite clear that they do not. In close to a year we have only seen more than four players at once a few times. The lifetime average players per game is hovering at around 3.1 players. Two couples, or four friends, waiting to be seated at a restaurant or chilling in the living room after work. That is a more typical scenario for AirConsole usage. The funny thing is Alice, the Software Development Lead at AirConsole told us that early in the process, but we ignored it because it would be so much more fun with lots of players.
"Arcade Style Beat Down," you say? "Complex, Fast Action Controls," as well? Are you crazy?!? Turns out we were. The controller specification for AirConsole clearly states that you should keep controls simple and limit player inputs to 10 times per second. What's more, the complexity of a controller that changes with every game and in some games multiple times as the game progresses is a liability, not an asset. Especially since the mechanic in each game is different, users needed lessons on how to play each game the first few times they play just to get the hang of things. And with no tactile feedback on a phone screen it is easy to get lost during the game when playing. And looking at your controller to reorient your self is a bad thing in an action game where death is immenent at every moment.
Up to this point, all of our mistakes have only been a problem for the end users. You know, the people who have to play our game for us to make money? The last two were huge headaches for the development team: Too many unrelated game mechanics, and wiating to add the real phone-based controllers until the end. Although we had a "working version" done for the contest deadline, it took multiple months of refactoring code and cleaning up little messes before we had a true release version ready. The first one is obvious, multiple game play mechanics require a lot more work than a simple mechanic that is used creatively throughout the entire game. I won't spend a lot of time on that one, but BE WARNED!!! The second one is less obvious, especially to the unitiated.
It is always going ot be easier to implement game play if you don't have to wait for the simulator to start and the controllers to load, and the game is much easier to play with a keyboard or XBOX controller than with your phone or using a mouse on a web browser simulating phones. The problem is that you are not only doing the work of writing a controller interface twice, but often problems in game play only show up when you are using the simulator or testing an uploaded build. We often had to refactor code to compensate for a stupid problem that should have been noticed early on when changes would have been easier. If you only take one piece of advice from this entire blog, I recommend that you build your controller early and upload you builds regularly throughout the creation process. That is exactly what we will be doing as we make Delinquent Miners.
We now return to our regularly scheduled programming...
When I decided to write a blog covering the full developmnet cycle of an AirConsole game using UNITY, I defined a few guiding principles to help limit and refine the intial design concept:
As I pondered on these criteria, I remembered a game called "Vector 3" that was published by one of my associates, Sam, for Android. It was a fast paced arcade puzzle using a bubble popping mechanic. A year or so ago, he even tried to make an AirConsole game from it called "Bubble Pop Party", but eventually put aside because the direct touch interface didn't translate well to a phone that couldn't display the game screen on the actual display. A moving cursor was awkward and imprecise and removed the satisfaction of jabbing something right before it got to big. Still, the gameplay was fun, if I could find a way to implement it while staying true to guideline #3.
The solution to my problems actually came quite unexpectedly, as most inspiration does. UNITY was having a massive sale on the top assets in their store. As I was purusing their wares, I ran across a product called "Shapes FX Pack" by Oranged Keys. The short video they had not only amazed me with it's beauty, it solved all of my problems. You can watch it here, if you choose:
Shapes and colors were the solution to creating a bubble pop mechanic game that could be played by multiple players. The players color would identify the "dimensional rifts" that belonged to them and the shape would match up with easy to learn buttons on the controller. And rather than eliminating someone when they failed to pop an expanding "rift" before it collide with something, you could simply delay their ability to launch a new rift for a time; the bigger the rift, the longer the delay. That would make rounds time based, and by playing a set number of rounds you would limit the maximum length of a single game.
Since those trippy geometric effects looked like rips in the fabric of space-time, the players could be space miners harvesting resources from other dimensions. That provides a theme, as well as a purpose. There was lots to still work out, but I felt like I was on the right track, so I bought the asset immediately.
The next day, I got in touch with Sam and told him my idea. At first he didn't seem convinced, but after watching that 3-minute video he was totally on board, too. We scheduled a meeting to discuss it later that week. We were going for it.
At our design meeting we worked out additional details as we rounded out our design concept. The rewards and penalties would be tied to the size of the rift. Since all rifts would start at a random point on the same plane, we would use the area of the cross-section to calculate the reward or penalty. At the end of each round, the players could spend the money they earned to purchase auxilary items that could be used to help or hinder other players, but spending money would deplete your end score for the leaderboards. And after the game was finshed, players could visit the luxury shop to buy bling to decorate their hanger profile picture on the player select screen. These luxury achievements would be permanent and stored in the player's persistent data on AirConsole. That way, your well decked out digs would declare your awesomeness to everyone you played with.
So let's review our design concept against the guidelines I defined before I started:
So as you approach your ideas for your own AirConsole project, I hope my failures of the past and my approach for the future can be of some help. If not, then you get what you pay for, right? If nothing else, when was the last time you went to a web page that used the word "trippy" three times. That has got to be worth something.