Crystal Chaos

Alright, I'm finally done with my first Flash creation. It's a Tetris sort of game with a bit of physics to it. The goal is to clear the board of all crystals and go onto the next level. Crystals disappear when you get 3 in a row (it's not a Match-3 game, I promise). After several moves, the bottom of the board will rise up and if you don't clear the board in enough moves, and a crystal goes over the top, you'll lose the game (at which point you can reload the flash to restart).

Go check it out, then come back here, I'll be waiting for you.

...

What level didja get to?

The real question, one for me is: what was learned while making it?

Making the Game
It's Flash. It works. Mostly. There's one teeny bug in the physics system that I know of and you might have seen. Also, you can't restart your game. There was a bug there and I just got tired of tweaking the thing. And I am trying to tell myself that I don't have to have a completely polished product before I put it down and put it up somewhere. Which is a hard thing for me -- I tend to be a perfectionist with these sorts of things.

The design process went something like this.

1) Hmm, Tetris games.
2) A few stupid ideas and an ideas I'd had in the past but discarded.
3) What if the blocks were rotated 45 degrees?
4) How would they delete? 3 in a row seems the best way to go.
5) How would they fall? I guess they should drop in a somewhat analog fashion with physics for sliding.

Then I made some of it. But I was still thinking about the game as I was playing early prototypes and I realize that it just wasn't that hard, and there was no real pressure to play well. You could make groups of 3 pretty quickly and without hassle. I needed to add some pressure to up the challenge a bit. I thought about having the piece drop automatically after a few seconds. I thought about having a timer after which you had to end the level. All the while, I had been thinking that the game was sort of like Puzzle Bobble in reverse. I decided to borrow a mechanic from that. In Puzzle Bubble the ceiling slowly falls in on you. So in my game, the floor raises.

So I added that. Then I added some levels. I thought about that some. At one point I was going to program in set-piece levels. On the one hand I felt that the game should probably be able to stand up on its own without set-piece levels. On the other hand, while checking out various Indie games on the market I found Soda Pipes, a remake of older pipeline games, which I thought wouldn't be a fraction of the game it was without set-piece levels. In the end I decided against it. Due to practical concerns more than anything else. I don't think at this point that I want to get too heavily into level design. It's an open-ended pit that I might not come out of. Maybe if I worked really hard I could make a given game 50% better with cool levels. But that's not really the point of my experiment -- I'm more interested in giving some ideas quick testd-rives and then maybe some day I'll come back to polish up a few and see how much better they get. So instead of set-piece levels I created a system where the number of colors of crystals increases as does the number of lines of crystals put out to begin with.

Another variable I might have played with that I think could have changed the game is the size of the board. I liked it where I had it but I think that a more constrained board might have made the game more challenging.

Overall I probably dumped about 20-25 hours into the game itself and a fair chunk of time just figuring out how to get Flash working. The physics engine was very simple, as far as physics engines go, but fun to work on. Collision detection between two squares rotated 45 degrees is stupidly easy (I gave that a seconds of thought and then realized, "duh"). I did have a lot of bugs as I worked on the thing but most were caused by an unfamiliarity with Flash, and by Flash's acceptance of code that wouldn't have type-checked in any "real" language. More about that later.

Judging the Game
The result? I hesitate to talk about my opinions too much because well, I don't want to bias your own. I'm hoping that other people can tell me stuff about my designs that I don't see. In this case I'm not too worried. I think the game is ok, and that's it. I do enjoy playing it and trying to get to higher levels. But in general there isn't a lot of thought that goes into playing it and I, myself, can't get that excited about it. I definitely prefer good old Puzzle Bobble (which is fine, Puzzle Bobble is a fantastic game).

Judging the strategy of your game is tough while designing it. Especially for something like this which is only slightly incremental and fairly different than other stuff out there at the low-level -- and a few details here and there make a lot of difference. Who could have thought, without playing them first, that Match-3 games like Bejeweled would be the sensation that they are.

I've been giving Lumines some thought as a comparison (if you haven't played that, play my clone, or better yet get the real thing, and come back to the conversation). The conept is very simple and from a high-level view it's not that clear why it would be as interesting as Tetris. It works because of a few very low level, non-obvious patterns. The fact that Lumines pieces can get stuck in checkerboard patterns which are very hard to break up is very important. It is also highly non-obvious how to setup big deletes. These two, along with a system that requires not only more thought but a lot more hand-eye coordination than my game, results in something that you literally spend hundreds of hours learning and getting better at.

And I wonder how Mizuguchi got there with his design. I can see coming up with the timeline idea that Lumines uses and the idea to integrate music into this. But the gameplay is incredibly subtle and I just don't think someone could come up with something that subtle through sheer genius. I am guessing that the answer is that he just tried a lot of things on top of his timeline idea and finally noticed some patterns or got lucky and found one idea that stuck, and thus Lumines was born. Or it could be that he's just a genius, and I'm not. In the meanwhile, I'm having fun and I'll hope that trying out lots of different ideas is the way to go for me.

Using Flash
So, Flash was ... ok. I'm certainly not ecstatic about the experience.

Things I strongly dislike:

• No type system. Type systems are good. While coding for work I rely heavily on them to point out my stupid typos. Flash programs happily run when I misspell a variable name and I have to do a lot of line-by-line proofreads to catch my mistakes.
• The IDE is horrible. I'm using Flash MX 2004 (anyone used the newer one? is it any better?). It is completely non-intuitive. Even the graphics drawing functions, for the vector graphics, are often a pain to use. And I can't seem to use my own editor for the code. Given that their editor is almost as bad as the rest of the program this is a big issue for me.
• The documentation is written for animators. All I needed was a "here's Flash for programmers" intro to get me started. Nope. I couldn't find any good online documentation either (although I found these two essays which discuss flash as a platform for developing games)
  

These made the whole process a lot more difficult than it could have been. Everything felt like a hack. I couldn't find good ways to organize my code. I spent far too long debugging problems that were simple typos. All in all I felt like a lot of my energy went to fighting Flash.

Things I did like:

• The vector graphics are nice, apart from the IDE. I could use another program to generate art, but I did find it very useful to just switch panes click a few times, and voila, my art had a new prettier gradient on it. And using simple gradients and vectors I can make semi-ok programmer art.
  
• The GUI API was quite painless to use. Getting the mouse location, hiding the mouse, getting keys, etc., was a snap.
• I could see that that there was a lot of functionality that, were I to master, could make some simple effects very easy to implement.

Despite severe dislike of certain bits, I think I am going to stick with it for now. I think I need to learn a bit more about how to create classes in Flash, learn a few more tricks, and maybe develop some techniques for organizing Flash code. And if that doesn't work, I'll move on to Java which at least I'm quite familiar with.

Performance-wise, the results were also a toss-up. With a physics engines and lots of pixels moving, I thought this was a good game to test out Flash with. It runs ok on my machine but it slows down a bit in the browser (not sure why). I tried it on my fiance's older laptop and it also ran ok on there although I did notice that it started to chug a bit after playing a while. I think as long as I stay away from really flashy stuff I should be fine, which is my intention for now anyway.


Conclusion
Anyway, can I work on a new project yet? I've been chomping at the bit to work on my next idea, which at the moment I think has more promise. More on that .... soon I hope.

Flashing it Up

Just to keep this page updated: Flash development is commencing. It's messy but I'm making progress. I severely dislike Flash MX 2004. And I'm not too keen on working with a scripting language instead of a programming language (when I typo a variable name, and don't get a compiler error, that's a very bad thing). But I like the vector graphics and I hope to have a working game sometime next week.

Update on Enlighten

A new version is up.

The change is that there are three difficulty settings. The change took about 10 lines of code and a couple search/replaces which I'm happy with. :)

My original post could have done with a better discussion of what Lumines is for those who haven't played the original.

Lumines is a very cool Tetris-like game. The real game utilizes looped music clips and gameplay sounds that naturally fit in with the music, so that while playing you feel you are playing "with" the music. The goal is just to stay alive and delete blocks as quickly as possible. Blocks delete, in groups of 4, when you have dropped 4 same color blocks so that they form a square. Upon creating a square, that square is only "marked" for deletion and actually disappears when the timeline crosses over it. I haven't really captured a lot of what makes the game great because I didn't come up with music for it.

Also, I decided that I might as well put up the code I used for this. You can find it here. I developed the game using DEVCPP, a free IDE for Windows. I believe you can actually download the SDL library from within DEVCPP (as a package) and it will automagically create templates for SDL projects. I was lazy and did the whole game in one C file. You can just throw that into an SDL project and it should compile fine. See SDL for the licensing information. It contains a simple, small game engine along with some drawing routines (blitting, and other primitives, and simple string drawing).

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).

Greetings

Let me introduce myself. I'm Steven Gabriel. I'm a programmer, and I make video games. I programmed my first game 20 years ago, on an Atari 800 at age 8, and I've been hooked ever since. After bumping around academia for a while I've ended up in LA, where I've been lead programmer for several cell phone games developed by a company called Sennari.

The purpose of this blog is to be a place for me to play around with ideas and hone my skills as a programmer and a designer of gamers. Being a rank amateur photographer and an only slightly better writer, I've noticed that you just have to take a lot of photos or write a lot before you get a few good pictures or stories. I think the same applies to making games. A lot of ideas sound really great on paper. And I think a lot of people expect their first great idea to strike gold. But having gone through the process a few times, I think I can say that there is a whole lot of change between first concepts and the actual game after development. And I'd like to explore that area and maybe find some decent ideas along the way.

I'm going to try to come up with fairly simple, casual ideas for games, prototype/develop at ludicrous speed, and just see how they come out. The emphasis will be on speed, coming up with ideas and spitting them out, and not on production quality or art (unless I happen to be interested in a certain graphical effect). My goal with any project will be to document where the idea came from, how development went, and how good the final product was. If the idea works, then great! If not, then hopefully I can learn just as much or more from why it didn't. I'd like to add games at a fairly regular rate, probably bi-weekly or so. At the beginning I may be trying out a few different development platforms which will take some time.

And I welcome feedback. As long as it's clear that these aren't supposed to be finished products or even necessarily good. :)

To start things off, I'll post in a bit about a clone of the popular PSP game Lumines that I've been working on in order to evaluate the SDL platform.