I've got about 5 projects that I want to work on, but it's probably going to be a while before I make any progress on them: babies take up a lot of what used to be free time. But they're awfully cute...

This morning, Omega finally made it to the "catalog"--the online list of games available for sale on my cell phone:



The game is available through all the major Hiptop resellers: T-Mobile, SunCom and Fido. :)

We're heading out in about half an hour to finally meet our newly adopted son Michael, who has just arrived in San Francisco and will be arriving in Philadelphia late tonight. Baby pictures will follow as soon as they're available. :)

-- Update --

My wife is sick of hearing about these, but I can't stop laughing. I stumbled across this site earlier, and have selected some of my favorites for your reading enjoyment:

• The Great Wall of China was originally created to keep Chuck Norris out. It failed miserably.
  
  
• Most people have 23 pairs of chromosomes. Chuck Norris has 72... and they're all poisonous.
  
  
• Chuck Norris can win a game of Connect Four in only three moves.
  
  
• Chuck Norris once shot down a German fighter plane with his finger, by yelling, "Bang!"
  
  
• Chuck Norris once bet NASA he could survive re-entry without a spacesuit. On July 19th, 1999, a naked Chuck Norris re-entered the earth's atmosphere, streaking over 14 states and reaching a temperature of 3000 degrees. An embarrassed NASA publically claimed it was a meteor, and still owes him a beer.
  
  
• Chuck Norris can hit you so hard that he can actually alter your DNA. Decades from now your descendants will occasionally clutch their heads and yell "What the hell was that?"
  
  
• Time waits for no man. Unless that man is Chuck Norris.
  
  
• When Chuck Norris falls in water, Chuck Norris doesn't get wet. Water gets Chuck Norris.
  
  
• Chuck Norris can believe it's not butter.
  
  
• Chuck Norris can divide by zero.
  
  
• While urinating, Chuck Norris is easily capable of welding titanium.
  
  
• Chuck Norris knows the EXACT location of Carmen SanDiego.
  
  
• Chuck Norris ordered a Big Mac at Burger King, and got one.
  
  
• It takes Chuck Norris 20 minutes to watch 60 Minutes.
  
  
• Chuck Norris doesn't believe in Germany.
  
  
• Chuck Norris played Russian Roulette with a fully loaded gun and won.
  
  
• Chuck Norris can sneeze with his eyes open.
  
  
• Chuck Norris let the dogs out.
  
  
• Chuck Norris once bench-pressed the entire state of Ohio.
  
  
• Chuck Norris can cook minute rice in 30 seconds.
  
  
• When Chuck Norris cuts an onion, the onion cries.
  
  
• Chuck Norris once ordered a steak in a restaurant. The steak did what it was told.
  
  
• Chuck Norris qualified with a top speed of 324 mph at the Daytona 500 without a car.
  
  
• Chuck Norris throws out the gum and chews the tin foil.
  
  
• Chuck Norris does not style his hair; it lays perfectly in place out of sheer terror.
  
  

I've finished a rough breakdown of how the game will be put together. This is really the last step in the high-level design phase; from here the designs get much more detailed and cryptic.

( Read more... )

I've also got short summary of how the game sequencing should work. This is less fancy stuff--but it's something that I typically slap on at the last minute and therefore botch horribly. "Sequencing" means, at least in this sense, all the messy menuing stuff that lets the user start a game, pause a game, load and save games, switch away, advance levels and generally just do everything else in the application except simply play the game. Because Hero has a lot of potential to be played as a correspondence-style game, I wanted to make sure I got this part right.

( Read more... )

One of the most difficult design aspects of this game involves its special actions. For variety and strategy, it's essential that these things have a very wide flexilibity, encompassing most aspects of the game. And yet, that very flexibility makes them hard to implement.

I've been working on a specification that describes how special actions can be broken down into specific properties, and thereby made programmatically tractable.

( Read more... )

As I've been working on the game's design, I've found a few things about the game summary that displease me. So I'm changing this and that. ( Read more... )

I've got about six pages of the next design document ready, but instead of posting that content today I thought I should probably back up a bit and explain (hey, it's Game Programming 101, right?) the overall theory on what's going on here.

( Read more... )

I mentioned in my last post that I'm working on the design for a new CCG-type game. Here's the formal game summary--which is just about everything I've got whipped up so far, this early in the design process.

Since this is "Game Programming 101", I should probably mention that this is actually an essential first step in the game design process. Having the outline for the game written out this way gives me several things:

• It's a relatively concise summary of how the game will work, so everyone else who works on the game can easily get The Big Picture
  


• It gives the reader a quick preview of how the game will play, which is essential (especially for a relatively novel combination like this) to ensure that the game is adequate in scope and without major gaps
  


• It provides the first warning if the game is too simplistic or over-complicated. If you can't picture yourself actually playing by the time you've read it all, then something fundamental is wrong.
  


• It's a concrete foundation that I can refer to later, to ensure the basic game doesn't drift during the rest of the design steps.
  

( Lengthy Game Summary )

Ah, it feels so good to finish a project! I have somewhere around a 10:1 ratio of apps started to finished; the majority of my projects get pushed aside as something more interesting comes up. But Omega is now complete--I've submitted it to the cell phone QA people who are giving it the once-over before offering it to T-mobile et al for sale--and so I'm ready to move on to the next project.

<arrogance>But first, I'd like to say that Omega shows a lot of promise. It's the first true-3D game available for this entire line of cell phones (heck, one of the first for any cell phone I'd wager: the Hiptop has more CPU than almost any other phone, and without a lot of CPU you just can't do true 3D). It's energetic, it's immersive and it's fun enough to give you a good case of Atari Thumb.</arrogance>

Anyway, what's next?

A few months ago I started thinking about trying to put some kind of collectible card game ("CCG"--think Magic the Gathering, Yu-Gi-Oh etc) onto a cell phone. Aside from the fact that the genre has proven its playability, I was struck by how well it would work with Danger's relatively closed development platform.

The basic premise would be, you purchase a "deck" from the cell phone catalog, and now you can play the game. Someone else might have purchased a different deck, but you can still play against each other live--or you can play against a computer. And in time you might decide you want to buy more than one deck in order to enjoy the variety--that works for me too. My sister even suggested that the game could offer to let you buy some kind of "customization pack" that lets you design and play with your own cards. Truly sounds like it could be the foundation of a significant game suite.

But I also wanted something that would help distinguish this new game from Magic (which I, being old skool, still think of as the canonical CCG). After chewing on it for a while, I decided to try to marry a collectible card game with a board game--so that your spells augment creatures that actually move around on a playing board.

I played around with that long enough to come up with a rough framework for a game that I think fits the bill. It's proceeding under the working title Hero, and later tonight I'll post the summary that I have so far. I'll try to be a little more verbose on LJ this time about the design and development process; this is a really BIG game--far bigger in scope than Omega was--so it really needs a formal development treatment. Stay tuned; this should be a lot of fun.

Danger is about to release the Sidekick 3--the next version of my cell phone!

Okay, that's probably not too exciting. But as you know I'm currently working on writing a new game for the Sidekick, and this new device has WAY more power for drawing pretty graphics. It's even got a primitive (a built-in, super-fast routine) for drawing textured polygons--which means I can texture-map Omega's models. Here's a sample of my proof-of-concept run:



See how the main object isn't just a solid color, but instead has some patterning to it? That's a demonstration of texture mapping, and it means I can really improve the graphics on Omega. With all this extra CPU power, I'm also hoping to be able to make the game's models more complex--more detail, better curves, and so on. (Users of the older Sidekick 2 will still get the solid-color models with simplified geometry.)

I tested successfully for first gup yesterday: nine patterns, a 3" break, sparring, terminology, and the ability to sit cross-legged for an hour. After all this time, the next steps for me are pre- black-belt tests (two of them), then testing for black in a little under a year.

Here's my new belt:    


In other news, I've posted Omega for its beta test. The game is nearly complete, needing only two more baddie AI algorithms and a bunch of new levels; everything else (right down to the sound effects) is finished. Here's a brief animated short of the game:

Since I mostly spend my time talking about Tae Kwon Do and stomach problems (a la GERD), I was thinking of changing my LJ's title. How about, "Reflex and Reflux"?

Right now, at this moment, I am very very scared. No way should a stupid quiz be this accurate. :(

Take the quiz at dicepool.com

Ah, the d10! While you aren't actually a true regular polyhedron, you are the only die that makes logical sense--metrically speaking. Chances are, others see you as over-analytical or a goody-goody. While that may be true, you also have a gift for patience and tolerance. Growing up you probably had a calculator wristwatch that you never really needed to use (since you were faster on your own), and you probably aced all your classes (except for gym). You use the metric system almost exclusively, but are able to quickly convert in mid-conversation for the sake of your backwards Imperalist friends. You've coded in at least two different programming languages, and have created more original gaming systems than you'll ever admit. You're generally not a show-off, but you do take pride in being called either a geek or a nerd.

I'm making some nice progress on the cell phone video game, now titled Omega. The first few tutorial panels read:

Bad news, trooper: Earth has been invaded, and all of our defenses have been wiped out. Humanity is just days from turning into alien chow. We've got only one ace left up our sleeve: the Omega tank. Now here's the really bad news: you're our last qualified operator. The Dolrikij invaders are tough and have technologies that we don't. But they're ultimately cowards, and that's what we're going to exploit. What we need from you is a show of force: face them on their terms and defeat their best forces, and they'll flee. We hope. You know this part already, but I'm supposed to remind you anyway. Your Omega tank has superb armor, which you can repair in the field. And it has shields to absorb energy-based attacks. But armor can be damaged, and shields deplete your power cells when they activate.

As an apology for the short and choppy phrasing, please remember that this text goes onto a tiny 240x160 cell phone display: I find brevity difficult in the best of times, and it's hard for me to convey a storyline in less than 150 words.

Some screenshots:


The menu system is complete, right down to the animated alien ships that fly towards the planet while you're looking at the main menu. For the game itself, the engine is finished and you can drive around the world and bump into obstacles--even jump short ones if your timing is good. But I don't have powerups working yet, or the baddies, or a plot. So there's still a lot left to go.

I've also whipped up a level editor, for use by beta testers:


The editor lets you place obstacles, baddies, generators, powerups and whatever in little playable levels. Beta testers will be able to build their own levels, upload them to the phone to test them, and mail me any completed level files so that I can put them into the final game. Fun stuff.

Tara and Isaac both tested for 9th gup this morning, and I tested for 3rd this afternoon. We were all successful. :)

9th gup testing doesn't require breaking; 3rd does though, so I broke three inch-thick boards with a right elbow strike. Kind of fun, but I think my favorite break so far is a forearm strike. We also all had a round of sparring, patterns, self defense techniques, terminology and so on.

The next step for me is 2nd gup (red belt; April), then 1st gup (black stripe; June). From there it's six months to a year until 1st dan (black belt).

And the winner is... BattleZone! Or, at least, a variant thereof.

This game seems particularly attractive for several reasons:

* There's not a lot of 3D on the screen at any given time: some geometric obstacles, an enemy tank, and that's it. The background, sky, ground, powerups etc can all be 2D decals.

* Nonetheless, the game play emphasizes the 3D aspect of the world: you're seeing a first-person perspective as you wander around this environment. No way could you cheat and write this game without some kind of 3D engine.

* The mechanics are very simple: easy ballistics, straight-forward collision detection, simple computer AI. No real surprises in there.

* The original game was extremely primitive, both in appearance and gameplay. There's lots of room for improvement, to help make the game original. (BattleZone capture-the-flag, anyone? Armor and engine powerups? Missles?)

I've started the app itself, by beginning with the background. This is purely 2D, which is important since 2D is a lot faster to draw than 3D and performance is critical: the cell phone just doesn't have a lot of horsepower to work with. The basic background looks like this (live shot):



As you move around in the world, the background is interactive: the stars and mountain slide to the side when you turn, and the rocks on the ground advance and draw away as you move forward and back, left and right. The overall impression is one of actually moving around on a flat surface--even though there's no 3D work yet.

Once I've gotten some 3D objects in there, I'll have to tune the background's constants to make the 2D background move at the same rate as the 3D world. When that's complete, it will be hard to tell where the 2D engine leaves off and the 3D engine begins.

Popped in a few more improvements to the cell phone 3D engine today:
1- Unrolled the arrays in the Matrix class; that gave about a 50% performance boost during matrix multiplication
2- Added fast-paths (special-purpose, highly optimized code for common cases) for some aspects of rendering and triangle sorting
3- Disabled backface culling by default, since the renderer is far faster than the position calculator

Overall, the engine is up to ~2650 tris per second unlit, and ~2370 lit. That should be plenty for a 100-triangle scene at 20 frames per second, so I'm going to declare success and move along.

The next step is the fun part: selecting a game, and designing how it should look. Some of the top ideas at the moment, in no particular order:

Stun Runner - Kind of like the luge in winter olympics: you're flying a car that's stuck to the inside of a pipe. As the pipe twists and turns, you have to dodge obstacles and catch powerups, while trying to stick to the outside of the curves so that you can stay as fast as possible. This was one of the first 1st-person 3D games to hit the arcades: it didn't use any lighting or texture mapping and the scenes were always simple, so I could actually recreate the graphics pretty accurately.

Moon Patrol 3D - You're driving a vehicle in 1st- or 3rd-person 3D, probably on the surface of the moon or something. You can steer around some obstacles, jump over others, and fire at baddies that come swooping down on you.

Battlezone - A 1st-person 3D tank game. Probably the first 3D first-person game--so old it only used vector graphics (the 3D scene was drawn in wireframe--fortunately, with culling by occlusion). This game's novelty was partially due to its twin controllers, but it was still a lot of fun.

As-Yet-Unnamed 3D RPG - A much more ambitious project, which I'd love to do but probably should sit on for a while. Think of a recent Zelda game and we'll be on the same page here.

Any suggestions?

The second round of performance tuning is done, and the performance numbers have climbed up to 2519 triangles per second unlit, and 1943 per second with lighting. Having reached ~2000 puts the engine in the range where it can draw a 100-triangles scene at 20 frames per second, which means I should be able to put together some rudimentary 3D games for this platform! I'll still have to be clever about mixing 2D and 3D, and I'll have to be very careful to keep the models simplistic, but it's looking feasible now.

On the other hand, I don't think I'll be able to squeeze too much more performance out of this engine. At the least, though, it's been an interesting exercise in optimizing embedded Java. The biggest optimizations I've found so far have been:

1- Getting rid of *all* object allocation in the primary deformation and rendering paths. This is essential, as it keeps the Java garbage collector from having to poke its little head in every N frames. (When the collector runs, your game pauses for a brief moment--feels horrible.)

2- Discarding specular lighting, since specular lighting requires extra calculations. By sticking with just ambient and diffuse lighting components, I was able to skip performing a lot of extra normal vector computations.

3- Eliminating use of java.util.LinkedList, and embedding my own equivalents. How on earth could the Java runtime screw up a basic linked list? This one step gave me a 20% performance boost across the board.

4- Discarding my home-brewed integer squareroot function and using the Java runtime's equivalent instead. Turns out that, even with no floating point support built in on the device, the onboard JRE has a better squareroot function than I do, and it's about twice as fast. (3D math uses squareroot a lot: helps in normalizing vectors.)


Here's the latest results. This screenshot was taken directly from the cell phone:



The blue and red tinges are caused by two freestanding, colored point lights in 3D space. Compare this to the pure-white image in the last post, and you can see why I'm pretty excited about getting this thing fast enough to use lighting effects.

So, what's new in Game Programming 101? Honestly, I haven't quit programming--it's just been a while since I had time or reason to update the journal.

Lately I've been playing with the idea of writing another game for my cell phone. To that end, I've been tinkering around with several throw-away applications, just to get my feet wet with the development environment again. When you write a program, you make use of some built-in functions; the collection of functions that's available is termed an "API" (Application Programming Interface), and it varies wildly from platform to platform. Thus, code to accomplish something on a Linux machine is going to look very different from code that will accomplish a similar task on a Nokia phone.

My phone is a Danger Hiptop, and to program for it one must write in Java. This in itself I find unfortunate: I dislike writing in Java, and would far prefer C++. And because of that distaste, my Java skills slowly slide over time. Between that and the fact that the Hiptop's API is very unusual, there's a small learning curve each time I sit down to work with the cell phone.

But enough griping. Here's what I'm doing now:



On the left is a shrunken copy of the 3D test program I wrote for my normal C++ game library... and on the right is the utterly stripped-down version that I've ported to Java for my cell phone. There's no texturing and I've temporarily disabled lighting in favor of speed--and even so, it's only rendering this 300-triangle scene at about 4 frames per second. That's not nearly fast enough for use in a game: I'm looking for something closer to 500 triangles, preferably with colored lighting included (unlikely), at a minimum of 20 frames per second. That means I need to make this code at least 8 times faster if I want to actually use it for a game.

An improvement of 8x is pretty unlikely, but I'll see what I can do. :)

Update...

The first round of performance tuning has boosted the fundamental performance from 1200 triangles per second to 2000. That's fast enough to do a 100-triangle scene at 20 frames per second--but 100 triangles is *very* rudimentary for any sort of 3D game, even if used creatively, and this benchmark is done without lighting. With colored lighting (which makes a huge difference in quality), the rate drops to 635 triangles per second--three times what it was this morning, but not fast enough. I'll keep working.