Once upon a time, I was told that I was going to be working on a neat project involving dragons, and a “create a block, destroy a block” mechanic similar to Solomon’s key.
Dragon Game Prototype
Read on, for the full accounting of how I got here from there, as well as such instruction as is necessary in learning “how to play”.
So. Solomon’s key, but with dragons. Could be great fun! I like dragons! And I like creating and destroying blocks! This could work!
Full of hopes and dreams, I went home for the weekend, and figured I’d give a shot at prototyping what I thought would be a neat way to represent it. “Well,” I reasoned, “Solomon’s key had some limitations about how things had to look. Everything looked square due to hardware constraints. But that was then. Why should I be similarly constrained?”
Thinking thusly, I started trying to make a dragon with some other features. I started with trying to make a tail that actually looked nice.
Several hours later, I had something pretty neat. Problem was, it was too short. So I made it longer. And longer. And longer still. Eventually, I realized that the tail was by far the coolest part of what I had done. But happily, dragons come in many shapes and sizes, at least one of which is pretty much all tail.
So. Slinky, oriental dragons it was!
This was going to be so neat, I figured. We were going to push the boundaries of what a side scroller could be. Why should the main character always fit in a bounding rect? Maybe when CPU load was a problem, but no longer! Now we’re living in the future! Even if I don’t have a flying car, I can still have an irregularly shaped protagonist!
Unfortunately, when I showed the producers in question what I hath wrought, on the following Monday, their reaction was not quite what I was hoping for. When I heard "dragons", I envisioned "slinky oriental serpents, maybe we can push the boundaries of what a side-scroller character is!", and they envisioned "square sprites that spit fire sometimes".
Oh well. They basically said “yeah, that’s kind of neat, but we would really rather just recreate Solomon’s Key…” (They went with square sprites.) Later the whole project was canceled, so it became a moot point. Oh well!
Still, I'm very happy with the effect. (You have to click through the customization screen to see the actual game. It's pretty rudimentary - Arrow keys move left, right, up. Space creates blocks. Holding down space breathes fire or something, which destroys blocks.)
It is very clearly just a prototype at the moment, mostly showing off the fluid snakey motion. I was, however, fairly proud of said motion, so that's mostly ok.
You have to click through the customization screen to see the actual game. It's pretty rudimentary - Arrow keys move left, right, up. Space creates blocks. Holding down space breathes fire or something, which destroys blocks. Having the same button breathe fire and create blocks was in response to a design request that we not go beyond d-pad + 1 button, for controls. It makes it a little cumbersome now, but it still works.
Someday, I'd like to revisit this, since I think it would make an awfully cool side scroller.
Tuesday, February 19, 2008
On ye Creation of Dragones
More of my Handiwork
Digging around through some old projects, and found this little gem.
Handwriting Recognition Demo
Working (mostly) handwriting recognition, in flash, using a fairly novel approach! (As far as I know at least.) Read on for more explanation!
Recently rediscovered this old prototype while dredging the depths of my "projects" directory. Funny story about it, actually. It came about, (as with so many good things) over a dare and subsequent bet. I was working on Leapster at the time, which was an embedded system that ran Flash. The neat thing about it was the stylus input, which, since the Nintendo DS was still new on the scene, was fairly fresh and neat.
We (myself and several other engineers) were musing over the possibility of using the stylus as a text input device, but the general consensus was that that wouldn’t be something that was possible with our CPU available, much less making it work in Flash.
Long story short, after insisting that it was probably possible, at least in a general sense, a friend wagered a candy bar that I was full of it.
As fate would have it though, what I was actually full of was flu virus, and I spent the next day (a Friday) home sick. With nothing better to do, I did some digging into the problem, and came up with this neat little prototype, which I proudly displayed the following Monday. (And yes, I got a candy-bar out of it.)
Sadly, LeapFrog was never terribly interested in going this direction, so it remains a fun curiosity that time forgot. Still, it’s a neat approach. It’s not perfectly accurate, but it does have the significant advantage that it runs at acceptable speeds on our poor, embedded flash system.
I’ve also uploaded this document, describing how it works, for anyone curious about the technical details. The short of it is, it basically uses a transformation, which converts the user’s glyph into a unique number which contains some topographic information, and then checks a giant, sorted list, to see if the number matches with anything known. Since the transformation is fairly fast at runtime, lookups are fairly quick.
Anyway. Neat, old stuff! Fond memories! I can still taste the candy bar! (It tasted like Science! And also like Victory!)
Saturday, February 9, 2008
I cast "Magic Missile"!
Missile command. One of my favorite games from "back in the day". This is my attempt to remake it later, and to apply some variations to it. Yet another piece of work done in Flash, which makes it easy to link to.
Missile Commander
Since this is one of the few games that I've actually written to a point that I feel is finished, I can actually do a realistic post mortem on it now.
Overview:
This was intended to be sort of almost a "journeyman" project in game design and programming for me. I basically set two challenges for myself: "Can I come up with enough variations to populate a reasonable number of levels with new mechanics?" and "Can I convince myself to sit down and start, continue and complete a full-scale project like this?" It feels like a success on both counts, so yay!
Specifics:
The basic idea is standard missile command. You protect things on the bottom, by blowing up attackers from the top. Your shots create explosions, and chain reactions can be used to wipe out several things at once. So far, all of this is pretty faithful to the original. What I did to try to spice it up was introduce the concept of "cities".
The player controls up to 4 of them, and switches between them with the keyboard, while targeting missiles with the mouse. While the basic cities are all standard missile launchers, this gave me some neat design freedom to make cities that did rather unique things, in addition to merely launching standard attacks.
I also introduced the idea of each city having its own recharge bar. This worked as an excellent balancing mechanism, since then I could make some cities that did some truly crazy things, but balance them by giving it a long recharge, and forcing the player to cover for it with other cities in the mean time.
The main other direction that I introduced new and neat things, was in the selection of things that would fly down from the top of the screen to harass the player. While I was a bit more creative with player verbs than I was with enemies, I still managed a reasonable number of annoyances. And I was extremely proud of managing an actual, honest-to-goodness boss at the end.
The only other place I did much of interest was in breaking the game into discrete levels, and giving them various goals. I didn't do as much as I could have with this, however, and most levels were basically some variation on "save at least X cities".
One rule I did stick with for levels however, was "one new mechanic per level". I made sure that every level in the game either introduced a new type of enemy, or a new building for the player to enjoy. I think this may have been one of the single best design decisions I made on the project, since it allowed me to ease the player in to new mechanics over the course of several stages. (For example, the game had a theme of "force fields protect you, but are destroyed by electricity" that was built up over several levels of progression.)
General things I think I did well:
General things I think I could have done better:
I like cake!
A postmortem and quick review of some work I did earlier this year.
Birthday Cake
It's neat! It's candle flames! Watch them flicker! It's... one day of work, so don't be too disappointed if it's little more than an effect showcase.
This was a 1-day flash project I did, as part of a birthday for a family member. (I have at least one family member tolerant enough to let me get away with making flash birthday cards for holidays, which works fine for me, being the consummate procrastinator, since they can be emailed...)
It's basically a birthday cake. It's not even much of a "game". Most of the fun is moving the mouse around and watching the candles blow and flicker. The whole thing really is a lot of me experimenting with trying to make things look luminous, while trying to guestimate how candle flames flicker.
As a post-mortum-y thing, this version would probably look quite a bit nicer if smoke or something came up from the candles after they had been blown out. Also, as at least one friend has pointed out, it's thoroughly unsatisfying being unable to blow out the last, big candle.
(Both of these were not problems in the original. In the original, however, every candle blown out released a sappy, birthday wish. This is the de-sappified version.)