Bad Golf

In September of 2010, I started working on "Bad Golf".

I'd been playing a lot of "Stick Golf" for the iPad, and figured I'd more or less rip off the concept. The idea of a 2D physics golf game isn't anything new, harkening all the way back to gorilla.bas and Scorched Earth, so I didn't feel too bad about it.

Bad Golf was intended to be a multiplayer golf/fighting game. The players would play golf on a 2D side-view course, but between shots, they could fight each other and slow down the other players from reaching their ball.

Once I got the main golf game going, I saw that I was going to have a problem. I wanted to have courses that had "islands in the sky", or other kinds of landscapes and layouts that wouldn't necessarily be readily accessible by a player running around. Would they have jetpacks? Or grappling hooks? Or could they climb vertical walls? Pretty quickly, I nixed the whole fighting aspect, and just went with a straight golf game (but the title stuck).

After working on so many projects where I lost steam, or painted myself into a corner, I knew that I needed to rely on as much external help as I could. For example, I was absolutely willing to change my vision of the game depending on what free tools and libraries were available. Many people wouldn't settle for a third party particle system library, for example, because it didn't have all the features they might want. I knew that if I took the time to write my own, I might run out of gas before I got to the end.

Bad Golf makes heavy use of the Farseer Physics Engine, and it's great. It took some time and effort to figure it all out, but soon I had a ball bouncing around the screen. Farseer has "texture to physics" functionality, which basically meant all my course design could be done in a paint program. One less tool to worry about.







Particle effects were done with the Mercury Particle Engine, another fantastic tool for making pretty flexible and substantial particle effects. Why on earth would I even start creating my own particle engine when I have options like these?

Coding was pretty easy. The game is straightforward enough that I didn't need to struggle with any design decisions or tuning problems. Course creation was a big pain in the ass, but I eventually got to the point where I said "screw it, it's good enough" and pushed forward.

I wasn't going to plunk down the $99 for the Creators Club fee until I was damn sure I was actually going to release the game. When I finally got to the point, getting it up on the Xbox was pretty much a breeze. I did have one big issue, in that it took about 40 seconds to load a level on the Xbox, compared to maybe one second on the PC. This was a problem, and introduced me into the wonderful world of the Content Pipeline.

You see, every time a level (hole) was loaded, I was reading in multiple graphics files. One was the background, and one was the foreground, but another one defined the physics of the hole, and another one had the special features (water hazards, sand traps, tee location and hole). Those last two textures had to be analyzed, and the texture-to-physics process run. What I realized was that I could do all that analyzing at compile time, and spit out raw level data. Then, in my game, I didn't need to recalculate everything, I just read in raw data and draw my level. Load times went from 40 seconds to sub-second. Classic Content Pipeline problem.

I was surprised at how much plumbing needed to be done, once the final gameplay was all working. Menus, fonts, screen changes, high scores, blah blah blah blah. That was kind of tedious. I used the Game State Management sample as a base, but customized it. Spending time learning the GSM is well worth the effort. It's a great starting point to any game.

I enlisted my friend Eryn to work on art for me. He did a fantastic job, but I quickly realized that it would take a lot of time and effort on his part to make 36 pictures.



So I found some textures and did some Photoshop magic to create a kind of flat-paper theme. Good enough. I threw together an official preview video, and I was good to go.



Bad Golf had a relatively uneventful playtest, and went into peer review in early December. On December 24th, it was released to the Xbox Marketplace. A day I will never forget. My game was actually published. For professional game devs out there, this maybe isn't a big deal, but as a hobbyist, this was huge.

I had no idea what to expect. Honestly, all I wanted to do was make my $99 back. Spending all that time and energy and losing money on the deal would have sucked. I told myself that I wasn't doing it for the money (and that was true), but it still would have sucked.

I had to wait a few days for the first sales reports to come up. I asked a friend of mine at work to guess how many copies were tried and purchased? He guess eight trials and one purchase. The real answer was something like 700 trials and 200 purchases. I made my $99 back on the first day!

While Bad Golf stayed on the New Releases list, it continued to get dozens of downloads per day. Then it pretty sharply dropped off, and for the last four or five months has been getting about 2-3 purchases per day.

Here are the statistics, as of today:
Trials: 7251
Purchases: 1760
Purchase/Trial Ratio: 24.27 %

That 24% conversion rate is something I'm pretty proud of.

The first week of sales (the last week of December, 2010), netted me about $500. The next quarter (Q1 2011) netted about $600. $1100 over the course of a few months isn't life-changing money, but it's satisfying to know that people are out there playing my game.

What I didn't expect were the reviews. It was thrilling to read reviews of MY GAME out there on the Internet. Some reviews were prompted my emails from me saying "Please review my game!" Others were just on their own. One guy made his own YouTube video of him playing the game. These were all awesome.



This was pretty much the icing on the cake:

Bad Golf is a crummy little golf game, but it's MY crummy little golf game, and I'm proud of it.