Inkblot – Post Mortem

Timeline (or 2 1/2 Weeks Too Long)

Week One – Spinning My Wheels

My first week of the competition was spent in Saskatchewan, at my parent’s house. They live in one of the most rural provinces of Canada, in a small town, and half of my family was going to be working for the week that we were there. I took my laptop, loaded with Visual Studio 2005 Express Edition, and high hopes of Getting A Lot Done. I did. And I didn’t.

I spent the first week trying to work out, in code, how I was going to make my vision of a spreading stain of ink come to screen. I was playing with Visual Basic, partly because I could. Partly because VB let me set up applications very quickly, while writing minimal code, so I could tinker. These were some of my first Visual Basic .NET programs ever. To my credit, I did slap off 6 different prototype designs trying to get the blob to move and draw right. By the end of the week I was ready to go home, but I had my mechanic.

Week Two – Getting Up to Speed

Shortly after getting home I had a revelation that could have saved me the previous week. Now I had a good idea of what I needed to do. I was ready to jump into some code. Except, I wasn’t going to be able to program a whole game from the bottom up. Three things were critical to any “game framework” that I was going to use. It needed to be primarily 2D (or at least have really good 2D support, and allow me to do pixel operations). It needed to be easy to use (language wasn’t too important, but one I was familiar with would be ideal). It also needed to be free.

I found the PopCap SexyAppFramework. This is the backbone that the best PopCap Deluxe games have been programmed on. As a bonus, it came with a series of demos to get me up to speed. Week Two was spent learning the PopCap Framework, and reacquainting myself with C++. By the end of the week I knew how I was going to implement my blob, and the shape of the game itself.

Week Three – Dash to the Finish

I programmed 70% of the finished game in the third week. It was hectic and busy. I spent two to three days taking the framework and building the foundation of Inkblot. Resource Loading, Title Screen, Game Board. All the supporting code that makes it run. Only then could I make it dance. I built the procedural blobs that you play against. I added user control. By Friday I had an almost game. There was no reason to play it; it was more of a toy than a game. I could have handed something in, but it wouldn’t have been finished. Then we got an extension.

Week Four – Cruisin’

The addition of a week changed Inkblot into something playable and, I think, fun. It also changed me from stressed and manic into laid back and happy. What happened is that gameplay took shape. Inkblot went from toy to game in several easy steps. I added input through the Dance Pad (thanks to the code provided in the EGP Framework). I added a goal, with limits. I added feedback. And then I added cycles. All of this was simple and easy. All of this made all the difference in the world.

The Missing Half

For those keeping score at home, there is still half a week of time missing. The Contest (part 2) technically ran from August 16, when the winners were announced, until September 15. 4 1/2 weeks. The first half a week I was getting ready to go to on vacation, I was busy with work. I did nothing that furthered Inkblot. If I had been on task, the first 2 1/2 weeks would have happened before the second part of the competition even began. I would have had more time to do what counted. In reality I had two week to program Inkblot. I should have had four. The missing half was really the first half.

Things I Learned (or Trite But True)

Any “realistic” system can be cheated (and is usually better if you do)

I’m a bit of a purist. I think it comes from my engineering side. I like equations and simulations, things that are clean. Cheating is dirty. But cheating not only gets things done faster, it sometimes does them better. The way the blobs work can be explained, technically, as a field effect. Each drip exerts a field. Where two drips overlap the fields add. Everything not above a threshold value is removed. This makes smooth areas where the drips touch.

Practically speaking, this is a number of image blits, each drip having a transparency gradient from the center to the edge, followed by a masking operation to smooth the edges. This is faster than running all the calculations needed for the pure way. It also allows me to draw with non-perfect shapes, which makes the blob seem more uneven, without adding any overhead. Faster and better. It took a week to get to this because I went looking for a pure solution.

Things always take twice as long as you expect (even if you expect them to)

This is just a fact of life. I thought I could learn the PopCap framework and have the core of the game up and running in less than a week. It took much longer than that. If it wasn’t for the lenient attitude that the EGP and RedOctane have had for this competition, I would have bitten the dust weeks ago. Maybe I’m out of practice (actually, I know I am), but even when I was on time, things took longer than I expected. There are always little bugs to fix, and little tweaks to make. It all adds up.

Plan for life to get in the way (because it will)

You need to make time for everything else. I thought I could work on my vacation. If I had stayed home, maybe I could have. Even though my family knew I was working on something, it was still more important that I spend time with them. The rest of the competition was the same. I’d get some time uninterrupted, but I’d also have those days where things needed to be done. Locking myself in the computer room wasn’t an option. Sometimes life (and other people) are more important.

The feature you want won’t be available (and creating it will take too long)

Corollary: creating a workaround only saves time if you only do it once. My practical example is the numbers that count in the level. The PopCap framework has a nice system for image-based fonts. The problem is that they have no easy way to scale the fonts or print larger text. Making the numbers grow and fade would have meant creating a new way of drawing fonts. The workaround was to use preloaded images. If I’d needed to do it again, I would have had to duplicate the process. It was a singular quick-fix. It works, but only because I use it once.

What Went Right (or The High Points)

I feel the game turned out quite well, and I am happy with the result. In fact, I found that the closer I got to completion the more it would up looking like my initial proposal. Or at least the proposal in my head. Procedural blobs worked better than I had hoped, and meant that I didn’t have to waste my time on generating art. It also means that the game can play forever. I wanted it to be fun, and challenging, and simple. I feel that I’ve achieved that. People can use different strategies for getting the blob to fill the space. I wanted people to move, and press lots of buttons, and stretch themselves a little to do it. I think they will.

What Went Wrong (or The Laundry List)

I could list a bunch of things, I suppose, that failed or went awry. Who can’t? The worst three things that happened were: wasting the first weeks, not playing it enough, and not having sound. I’ve gone over, in excruciating detail, the first point. The second point is self evident. Games cannot improve in a vacuum. They need to be played and then they need to be made better for it. For all that I think Inkblot is fun (and so does my wife), I don’t know that you will. I could have done more to find out.

Not having audio is a minor point, but one important for creating a polished work. You’ll notice that there is rudimentary functionality written into the game to handle audio. There are sliders for music and SFX in the Options Dialog. The code that it would take to load sounds, and play them back, is minimal. It would take nearly no time. But finding or creating the rights sounds wasn’t on my timeline. It has no sound because I didn’t want to tack something on, and I didn’t set aside the time to do it right.

Conclusion (or Wrap it up Already!)

I had fun with this project. Even with the extra time that it has taken, it never become insurmountable or painful to work on. It was a challenge, and I enjoy those. It was invigorating to have something to program, and it was even better that it was my own design. I went into this competition hoping I would get a chance to design, to program, and to grow. I’ve done all three, so I’d call this a win.

I hope that you enjoy playing Inkblot half as much as I enjoyed the time I spent making it. If you’ve been reading this and still haven’t played the game, perhaps now would be a good time. Thanks for reading, and playing. Comments go at the bottom. :-D

-----
Download Inkblot here, or check out the other games and EGP Comp 2 entries at the Experimental Gameplay Project.