SDL & Enlighten

As promised I'm going to post on my first endeavor of this project (hmm, does the project itself need a name?). If you're not that interested in the development story you can skip to the game itself (unzip all files to a directory, double-click enlighten.exe).


The Idea
This is actually something I worked on last year. Working for an honest-to-goodness game company and actually releasing games has made me a lot more confident about my ability to follow through on a game and create something "professional". I was looking for a way to take this a bit further with a project that I had control over.

The idea was to learn more about developing titles for a PC and try out my skills at creating a fairly complex puzzle game. I decided to create a clone of Lumines, a puzzle game that I was very addicted to at the time, and had great gameplay and execution which I admired (Tetsuya Mizuguchi has done a lot of great work, and I like what he has been doing with Q Entertainment). At the time I had several ideas about how I wanted to expand the initial concept -- I was interested in putting in some dynamic lighting models and trying light as a game mechanic. Certain blocks would emit light and without enough light it would be difficult to see and use the entire board. I called the game Enlighten with this in mind.

Execution
The first task for me was to pick a development platform and create the basic engine I would need to create the game. The likeliest canidate was DirectX. It's nearly industry standard and has pretty much everything I'd need for the game. There were a few problems with DirectX though. It's proprietary, you can't port it, and you need Visual Studio to develop with it. I wasn't excited to blow money on copy of Visual Studio for my home computer. So I looked at my options and found SDL, a C-based library that does most everything I need, is free and is multi-platform.

I set to work creating a prototype of the game. I read over some tutorials, figured out the basics of how to push pixels to the screen and read keyboard input and created a down and dirty engine for updating based on user input and rendering to a small window. Then I got to gameplay, first having blocks that dropped, then blocks that stacked, and finally blocks that filled in holes (albeit, automagically, there were no physics involved). I introduced the timeline and allowed blocks to delete. At this point I'd spent about 15 hours researching and a few hours coding. Then I added some graphical flourishes. A score readout, a menu, a background image. At some point I got side-tracked looking at graphical effects and decided to put in a plasma effect for the backdrop of the game.

Getting the graphics and the code in was relatively painless. I wrote some graphics primitives, blitting stuff, some alpha blending, etc., and it just worked. Where I got bogged down was in implementing the game "physics" of Lumines. Even though I appreciated the somewhat analog nature of the original game, I hadn't appreciated just how complex the rules were for determining when to delete something. I also got bogged down into trying to implement those rules in as efficient a manner as possible, which when considering the overhead for drawing operations, was almost certainly a waste of time. It made me consider the development process of the game and wonder just how many iterations the original design went through and how they got down to exactly the rules they did. And appreciate how complex rules may be required for a simple user experience. I suspect that the game was probably designed from the perspective of the user experience itself and the rules came later.

I played around with a few visual effects. What you see in the final product doesn't have all of these. I tried having a fade effect as the piece moved around the board. The alpha-blending proved a bit too expensive for the lower-end laptop I tried the game on. To get good acceleration for this, apparently, it would have been necessary to draw using OpenGL on a 2d projection -- I chose not to go that far.

Conclusion
All told I spent about 20 hours planning/researching for the game and about 30 or so hours coding the thing. Not a lot of time all things considered -- basically one "work week" and I had to build up a lot of my engine from scratch. I didn't finish the gameplay completely. There are a few quirks in the gameplay, I didn't do "levels" and I never got to the lighting models I wanted to do. I looked into getting some music loops to play during the game but didn't follow through on that. But that's ok. I did get a non-trivial fun, game done with SDL in a fairly short amount of time. And I got enough expore with SDL to determine that it is definitely sufficient for smaller-scale puzzle style games although if I wanted to do some more extreme graphical effects I think I would need to integrate OpenGL into my project or move to DirectX.

Moving Forward
My goals have changed a lot since I made Enlighten. Instead of trying to make one game right the first time I want to throw out a bunch of ideas and then maybe come back to those that worked particularly well or were fun -- I may even come back to Enlighten at some future date. But for now I'd like to work on some smaller ideas that are more fully my own. I did get to play around with SDL though and become more confident that I can make a decent looking PC version of a game though.

I've also decided that, for the purposes of documenting this all on the web, I will get a better response if I am able to create web-based games. So I'm looking at Flash as a platform for developing games. So far Flash is proving very different from what I'm used to -- it's geared for artists, animators, movie-makers -- not programmers. Programming a game feels like a hack. But it does have a lot of nice tools for visual effects and I have an idea for a game that I'm putting through the paces now.

More on that soon (I hope).