Skip to content

Posts from the ‘Development’ Category

23
Jul

Bumper Kart Hockey… and more!

Bumper Kart Hockey

Bumper Kart Hockey has been submitted to the App Store! I’ve really enjoyed working on this game these past few months, and I’m looking forward to seeing it go live! While the app waits for Apple’s approval, I thought it would be interesting to share the roundabout way that this game came to be, and also give a preview of what’s coming in the future.

This all started because I saw a lack of fun kart-style battle games on iOS. There were plenty of racing games, but I wanted something with more direct interaction between players, like the classic Mario Kart Battle Mode. I wanted something casual but competitive that anyone could pick up and immediately enjoy playing. I had an idea for a “king of the hill” type of game where the primary interaction between players would be bumping their cars into each other. Each car would be disc shaped and the physics would be extremely dynamic, akin to driving around inside a pinball machine. Players would zip around the arena, bumping into obstacles and trying to knock each other out of the “hill”, designated by a small circle on the floor which moved every 30 seconds. It quickly dawned on me that I could create lots of different game types based around the same bumper car free-for-all concept, and that it would be a fun way to do a casual kart game! Bumper Karts!

"King of the Hill" mode

“King of the Hill”

After lots of work (and several helpful tutorials on box2d physics and peer-to-peer networking), I had a prototype of my bumper car idea, with “king of the hill” plus four additional game modes. One of the game modes I implemented was “hockey”. Trying to create a 4 player free-for-all hockey game was… interesting. In my version, players earned a point by being the last to touch the puck before it went in an opponent’s goal, and they lost a point for knocking the puck into their own goal. After playtesting with friends, it was clear that my hockey mode didn’t really cut it as a 4 player game. But, with only 2 players, it worked beautifully!

That’s when a new product strategy clicked. I knew that my biggest risk was that I could spend a considerable amount of time building a large multiplayer game, and then not attract enough players to reach the critical mass necessary for online play. I decided, then, to build a smaller game first, focusing on one game type (hockey), optimized for 2 player matches. And, I would ensure that this game would be fun to play offline by including computer (AI) opponents. I would later add timed “challenge” modes, with leaderboards that allowed for asynchronous competition.

Finishing Bumper Kart Hockey took longer than expected, as it almost always does, but I’m really proud of the result. I was able to integrate some great features, including MFi game controller support, and video replays via Everyplay. Below is a replay of one of my matches against the “Hard” AI. You can watch more clips that my friends and I have already shared by going here.

My long term plan is to develop a Bumper Kart “brand” by releasing more Bumper Kart apps featuring other game types. Until I have a large enough player base, I plan to stick with game types that don’t require more than two players to be fun. I haven’t decided for sure what game I’ll do next. I’m leaning toward a Bumper Kart racing game, where the races are short sprints, on narrow tracks full of crazy obstacles. I’m excited to start working on it, and I expect development to go much faster this time around. For now, though, I’ll be focusing on a successful launch of Bumper Kart Hockey, vanguard of the Bumper Kart franchise!

30
Apr

The Rotex Recap

Rotex, the abstract strategy board game I released in March, was a bit of a flop, unfortunately. I wasn’t expecting wild success (it doesn’t quite have that addictive quality Five-O has), but it definitely performed below my expectations, so I wanted to reflect on that and tease out some lessons from the failure.

Background

Six months ago, I left my day job as a programmer/designer in the mobile games industry and embarked on a new adventure to develop my own games full time. I was motivated by the fact that Five-O, even after several years and very little personal attention, was continuing to gather positive reviews and earning a stable, albeit small, income. If one app could earn $10-15 per day seemingly indefinitely, and if I could quickly develop several more similar apps, maybe I could grow this into a business!

Thus, with wide-eyed enthusiasm, I began prototyping new game ideas. My goal was to design a game that could sit on top of the Five-O “engine.” Basically, that meant designing a two-player game that would be fun to play online, asynchronously (via turn-based multiplayer). Since hours might pass between your turns in an asynchronous game, every turn should be interesting and require careful thought. A lot of card games and other traditional games don’t fit this model because they have very quick turns. Also, players shouldn’t be expected to retain a lot of information in their heads about each individual match. After all, they could be playing in lots of matches simultaneously! Games with hidden information, or with sequences of actions that span multiple turns, can be very difficult to play asynchronously. So with all this in mind, I came up with an idea for a hexagonal variation of Pentago, which I initially called Hexi, and which later became Rotex.

One of the strategies I employ when working on a game design involves building an AI opponent. It seems crazy to write an AI at such an early stage, but I find that I save time in the long run because it helps me discover balance issues quickly without requiring a lot of user testing. In my opinion, a proper AI opponent is also an essential feature for a digital board game, so I also need to make sure that it’s possible to create one. Plus, I just like coding board game AIs.

What I discovered was that the game was more frustrating than fun. My AI opponent would always beat me with a move I didn’t anticipate, and if I let the AI play against itself (another useful testing strategy), games would almost always end in a draw, as if it were just a complicated version of Tic-Tac-Toe. My attempts to fix these issues through new rules and changes only made the game more complicated and less elegant, doing more harm than good. In the meantime, I had also begun working on another, completely different game prototype which seemed to have a ton of potential – a 2D kart-style game with real-time multiplayer (more on this in the next blog post). So, my focus shifted away from Rotex for a while.

Fast forward to mid-January. An issue had cropped up in Five-O where the app would sometimes crash when loading certain Game Center matches. I was able to address the issue, after which I made a few other much needed improvements and released an update. As a side effect of working on the update, I now had the Five-O codebase fresh in my mind again, so I contemplated taking a stab at finishing Rotex. I estimated it would require about a month to take Rotex from prototype to finished product, using the Five-O codebase as a template. So, even if the game wasn’t perfect, at the end of the month I would have another product in the App Store which would energize me and help me learn even more about the market.

So, I spent the month of February finishing Rotex. During that time, I developed an art style that I liked, and discovered some small tweaks to the rules which greatly improved gameplay. I even found time to implement an interactive tutorial, which I felt was absolutely necessary for an abstract game like Rotex. I struggled to develop an AI opponent that wasn’t either God-like or hilariously bad, and I’m not sure I succeeded in my efforts. But, overall, I was quite pleased with how the game turned out.

The Numbers

Rotex was released on March 16th, 2014, and got about 1000 downloads in the first week. That would have been great, except that I had decided to make the game free, using only advertisements to generate revenue, and the number of daily active users (DAU) was low, averaging around 150 per day. My marketing and cross-promotion efforts were succeeding in generating a nice trickle of new downloads, but players weren’t sticking around to play very often.

After a month and a half in the App Store, Rotex has been downloaded 2,189 times. During that time, only 328 online multiplayer matches of Rotex have been completed. Single player mode is much more popular, with almost 10,000 matches completed. But, for comparison, Five-O players, during the same time period, completed about 211,000 single player matches!

In terms of revenue, the advertisements in Rotex have only generated about $22 so far. On March 28th, I released an update with an in-app purchase option to remove ads for a dollar, and that has generated $5. Even though the game has been a commercial failure, I’ve learned some valuable lessons, a few of which are summarized below.

Lessons

1. Ad supported business models don’t work for niche games. Ads work best when a game is addictive and appealing to a broad audience. This might explain why there seems to be a higher ratio of paid apps to free apps in the more niche App Store categories, e.g. board games. If I could start over, I would drop the ads and sell Rotex for one or two dollars instead. Also, having the option to pay to “remove ads” is not a good alternative. It’s fine in principle, but users would be much happier to hand over their money if they got something else in addition to having the ads removed.

2. User testing should never be skipped. If I had spent even a small amount of time just watching other people try to play the final build of Rotex, I would have noticed an obvious user interface issue. In Rotex, after placing a tile and rotating the board, users must “submit” their move by tapping the play button, exactly like in Five-O. I discovered, too late, that many people expected moves to submit automatically after they made them. I suspect this is why a larger percentage of online matches go unfinished in Rotex; players may be making their moves but never submitting them. I recently released another update with a modified tutorial and some animation to draw the eye to the play button after a valid move is made. If that doesn’t work, I may need to rethink the user interface design.

3. Cross-promotion is a cheap and viable source of downloads. Everyone knows the App Store has discoverability issues, especially for indies. If you’re not lucky enough to get featured, you have to fight for every download. By building your own network of high-quality apps, and cross-promoting between them, you can make all of your apps a lot more visible without an expensive investment (besides building the apps in the first place). Currently, my network is only two apps, but I plan to add several more in the coming months.

4. Leveraging existing codebases leads to much shorter development times and fewer bugs. This is pretty obvious, but I was surprised at how much of a difference it made. I’m currently developing another game from scratch, and it is taking months of work to get to a minimum viable product. In contrast, I developed Rotex from prototype to finished product, complete with a battle-tested online multiplayer system, in about one month by using Five-O as my “template.” Not only that, I also fixed a few bugs and made improvements that I was able to funnel back into Five-O. From now on, when considering game projects, I will definitely prioritize the ones which leverage my existing work.

What’s Next?

I have some ideas to turn Rotex around in the future, perhaps by re-releasing it as a paid app. Currently, however, I’m working hard on my next project, which I hope will be a successful entry into a new and exciting genre. If all goes well, it should be ready to release within the next couple of months. Watch for a more detailed announcement soon!

21
Dec

Five-O Development Story

I’ve always thought that there were some big advantages to playing board games on a computer. There’s the automatic scoring, automatic shuffling, automatic set up and clean up with no small pieces to get lost, and, if you can’t find anyone to play against, there’s the option of playing against the computer. Back when I was in college, I took a course in artificial intelligence where we designed an AI for playing Connect 4. I enjoyed the project so much that, after it was done, I wanted to write another board game AI. But, this time, I wanted to design the board game too.

The first step was coming up with an idea for a board game. It was around this time that Sudoku was becoming really popular. I remember thinking about how Sudoku puzzles were a lot like crossword puzzles but instead of words and clues, they used numbers and logic. I wondered if other word games might work with numbers instead of words, and came up with the idea of creating a number game that would be played like Scrabble.

I’m certainly not the first person to come up with the idea of a crossword-style number game. In fact, I remembered playing a board game like this growing up. But, when I searched the Internet, I found that there weren’t any available for the computer yet. So, I decided to make one. I started by crafting the rules, mocking up a game board, and coming up with a catchy name, Five-O.

It didn’t take long to make the first playable prototype of my new game. It didn’t score your plays, it didn’t even check that they were legal plays, but it was good enough to see that Five-O had potential to be a really fun game. So, piece by piece, I wrote the rest of the code for setting up games, handling turns, and validating and scoring plays. And, once all that was in place, I wrote the AI code for the computer opponent. It was really cool to see it all come together.

Mac version screenshot

A screenshot from the original Mac version of Five-O

After putting the finishing touches on Five-O, I spent some time looking for a publisher. Having no luck, I considered self-publishing through a new online store called MacGamesArcade. But, graduating from college, moving to a new city, and starting a new job soon consumed my time and Five-O sat on the shelf, unpublished.

Then, during the summer of ’08, I started developing iPhone games. The App Store was just what I needed to finally get my games out into the world. It meant learning Objective-C, Cocoa, and a whole new style of user interface design, but something about writing apps for mobile devices was just so much cooler than writing plain old computer games, so I dove in head first.

My first iPhone app was nothing to write home about. It was a Pac-Man style arcade game with simple graphics and gameplay. I considered developing a version of Five-O for the iPhone, but I just couldn’t imagine it being much fun on such a small screen, so I worked on other projects in the meantime.

When Apple introduced the iPad, my first thought was “I’ve got to get Five-O on that.” The large touch screen was going to be great for playing board games. And, with my experience developing iPhone games, I knew I could get the job done.

It took a lot of evenings and weekends, but I got Five-O working on the iPad. Through all the rewriting, refactoring, and tweaking, it matured into a nice little game, with decent graphics and a slick user interface. I want to thank the Ludum Dare community for helping me power through the final stretch of development. They ran an “October Challenge” for indie developers where the challenge was to finish a game and sell one copy before November 1st. I worked hard to meet that deadline, and I’m proud to say Five-O got its first sales on October 30th, 2010.

Since then, Five-O has been featured by Apple in the New & Noteworthy and What’s Hot sections on the App Store, and it has been lauded in reviews on several different websites. The success has been really encouraging, and I’ll just wrap up by saying thanks to everyone who has purchased Five-O or supported me in other ways. I plan to continue development on this game, and I’m excited to see how far I can take it.

14
Dec

DropOut Development Story

The original version of DropOut was actually written for a college programming class. The class was Intro to Java Programming, and the final project was to build a game. I’ve always been a sucker for “match 3” puzzle games, so I decided to create my own.

When I started designing the game, I looked to other popular games for inspiration. I came up with the idea of making a game similar to Tetris Attack, but with game mechanics similar to PopCap’s Chuzzle. The idea was that you would try to match colored blocks to make them disappear before the board filleDropOut Screenshotd up, like in Tetris Attack, but you would move the blocks by sliding whole rows at a time, like in Chuzzle. Some of the pieces would also have locks on them, so you couldn’t move certain rows.

There were lots of technical challenges along the way. Early on, I made the decision that I wanted the player to be able to slide the rows even while blocks were simultaneously falling down or disappearing in other rows. After all, in a game where speed is important, nothing is more frustrating than when the game doesn’t let you move fast enough. Implementing this took some clever programming, but it was worth it. Another challenge was keeping track of combos for scoring.

I finished DropOut and turned it in at the end of the semester… and then I kept working on it. I added the “falling star” blocks, which made the game a bit more interesting. I also sent it out to friends and family and made changes based on their feedback. I knew the game was good when it got the mother-in-law seal of approval.

About a year went by where I didn’t work on DropOut much, and then the iPhone arrived on the scene. That’s when it dawned on me that DropOut was perfect for a touch screen. Being able to touch and slide the rows was just so much more elegant than using keyboard controls on a computer. The App Store was also proving to be a great tool for indie developers to self publish. So I ported the code from Java to Objective-C, redesigned all the graphics, added sound effects and online high scores, polished it up, and submitted the game to Apple.

DropOut was approved and released, and even though it didn’t make a big splash in the casual games market, it was a great learning experience and I really enjoyed working on it. Seeing high scores posted from all around the world was especially gratifying. Since the initial release, I’ve added, through updates, background music, a color blind mode, and even two new game types – Puzzle and Blitz. I don’t have any plans for a major update any time soon, but if I find time in the future, I think a multiplayer version might be a lot of fun. I’d also love to hear suggestions from you. Leave a comment if you have some!