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.

EGP - So Much For Mini Updates

Yeah, my bad. It's not that I don't love you. It's just that I suck at blogging in general. I have lots of things to say. I thought about posting mini-updates several times in the past week. I didn't though. I was working, or I didn't have time, or I wasn't in front of a computer. Stupid excuses. No glimpse of my working habits here.

So, on to news. Last Friday was the Experimental Gameplay Project - Competition 2 deadline. Until they extended it by a week at the 11th hour. Today is the new deadline. The extra week has been a godsend. I went from having a neat idea, and half a game, to having a playable and near complete game.

Playtesting happens today. The game gets tweaked, polished, and submitted. It feels nearly done. Truth be told, I'm pretty happy with it.

The Post-Mortem goes up tonight (after I write and edit it). So does Inkblot. If you get a chance, check it out.

EGP - Best Supporting Code

When you sit down to design a game, especially when you are working around a simple idea, or striving for a focused gameplay experience, you tend to think along focused lines. I began thinking about Inkblot (in a rough and unfocused sense) back at the end of July when I first read about the Experimental Gameplay Project’s Contest. Over the following weeks, I focused on what I wanted to create, trying to get a clear picture of it. I thought about the Dance Pad – how I could use it in a unique way. I thought about the game mechanics – how the blob should move, and grow. I thought about feedback loops – how I was going to drive the player on, and reward them for playing well.

What I didn’t think about was all the rest of the stuff that has to go into the game before, and around, the gameplay to make it into a whole. In short the supporting code. The Academy of Motion Picture Arts and Sciences gives high regard to actors and actresses in supporting roles for a reason. While they may not be the stars, with all the focus and glamour, the films they are a part of would be pale and flat without them. So to in programming.

I have spent the past two days getting an outline of my game working. I had to work on supporting art resources (not my strong suit). I had to code together the core objects that make the game a program. At the moment it can load resources, change some core options (such as 3D acceleration and Fullscreen mode), and get into a Game Start mode. Fortunately the framework helped a lot, and will continue to do so.

This has been a big lesson to me. I tend strongly towards two activities, Design and Problem Solving. These are the things I love the most. I like to envision new ideas, map them out, and develop them into solid concepts. Most of this happens off-screen, in note books, on scraps of paper, and in my head. I also like to design creative solutions to difficult problems. Whether this is writing the prototype code to do something cool, or finding and crushing the obscure bugs, it tends towards unique and challenging tasks.

I don’t like to write menial code. I hate setting up boring classes, writing dozens of accessors, and generally getting the foundations of the program poured. I would be happy if every task was a new thing to learn, or a new challenge bright and clear. Then, after each solution is revealed, pass off the boring implementation to someone else. Life’s not like that, and good programs (games or otherwise) need a lot of good supporting code behind them.

I should have set more time aside to get my game structure working. So far it’s been 8-9 hours on the code, and about 4-5 on the art. I only got about 4 hours last night, but I made sure that the application ran, and was ready for the gameplay.

EGP – Down to the Wire

I’ve been slightly absent in my blogging as of late. Not due to inactivity, mind. Just unable to find the time to sit and write. So much for that, I’ll make time. I’m back, and I’m going to make a point of putting updates back on track. If this is coming out all disconnected and strange, it is because my brain is occupied elsewhere; I apologize.

First, news: At the beginning of August, the Experimental Gameplay Project kicked off its second Gameplay Competition. Sponsored by Red Octane, the EGP set off to cover new ground and get intrepid programmers and designers to create new ways to play. The challenge – Create a non-rhythm based game designed to be played with a Dance Pad. Round One consisted of designers putting forth their best ideas. The chosen designs (15 in all), would move on to Round Two.

Round One Winners got mailed an actual Red Octane Ignition Dance Pad (yes, they gave away 15 of these for really simple designs!). We now have until the 8^th of September to prototype out designs. Yes… we. I was set alight by an idea. I submitted a design. I was chosen to go on to round two.

I’m now on the wire.

-----

This is the final 5 days of the competition.

I’ve been quiet (blogging-wise) up to this point: partly because I’ve been busy and party because I’ve been spinning my wheels. I’ll admit that I’m a bit rusty when it comes to programming and prototyping for windows. I have a tendency to over-design and over-think problems. The practical upshot of this is that I spent the first week (during my vacation) spinning my wheels on ideas. I created half a dozen prototypes trying to get a graphical idea to work. I managed it, but at the cost of a week.

The second week was me trying to get my brain into game-programming space. I needed a game framework that would allow me to do direct image manipulation, which was easy to use, and that was free. I found a few and settled on the PopCap Games Framework. I spent the second week learning the API and game programming practices. I was back at work, and learning a new API is not the lightest thing in the world. Week two, cram session.

So where am I now? I’ve got a framework. I’ve got a prototype layout. I’ve got some graphical resources. It’s about to get wacky. Stay tuned this week for micro-updates and pre-mortem breakdown. Perhaps even a few glimpses of Inkblot.