Courtesy of the Microsoft XDK documentation:

"While the flexibility of an audio pipeline fully implemented in software provides the ability to arbitrarily route data to multiple destinations with independent volume control, it does lead to a potentially dizzying array of... well, arrays, as well as pointers and structures. Initializing an XAudio source voice via XAudioCreateSourceVoice requires no fewer than 5 levels of indirection."

I've been reading a lot about cellular automata, which is a fancy name for pretty squares that change color. Each frame, the color of a square is determined by a simple rule based on the previous colors of itself and its neighbors. Certain rulesets create really complex and fractal-like patterns.

I started playing around with rendering some in Flash. Here's the result:

cylic cellular automaton (click to start a new pattern)
source

Reminds me of those early 90's screen savers. :)

The interesting thing about these automata is that they are actually carrying out computation. The rule by which the cells change can be viewed as hardware, and the initial state of the cells is software. For example, Rule 184 can be used to describe traffic flow. Rule 110 is even a universal Turing machine, meaning it can be functionally equivalent to any computer! Some of them can even self-replicate.

If this sounds interesting to you, you should take a look at Stephen Wolfram's A New Kind of Science, which is free to read online. He's spent years researching cellular automata, and has discovered tons of interesting properties about them. He even proposes that the laws of physics could be based on cellular automata -- that the fundamental basis of physics is not matter and energy, but computation and operations on information!

I've been pretty busy lately, chugging away at Castle Crashers. It's finally starting to shape up, thanks to Tom's awesome gameplay and Dan's crazy art. Check out the shot I've attached -- it's only a tiny bit of the world map!

I came across this today, and I thought I'd pass it around. If you're a student, check this out:

Microsoft DreamSpark

Free and legit Microsoft development software, including Visual Studio! I hope some of you programmers out there will find this really useful. It also includes a subscription to the XNA Creators Club, which lets you build games onto your Xbox 360.

It's a shame that Office isn't included. Of course, Office + college students is probably one of Microsoft's biggest cash cows.

Easy depth sorting was one of the nice features of ActionScript 2.0. It was great to throw something onto depth 999999999 and forget about it. Isometric games had it easy -- just set each sprite's depth to its y position (or some function of it), and, woo, perfectly sorted sprites!

Sadly, Adobe strips this away from us in ActionScript 3. Depths are gone. Now your Sprites and MovieClips only get a list of children. The order of this list determines the order in which the children are drawn. You still get functions like swapChildrenAt(i, j) and setChildIndex( child, i ) to change the position of an object in the display list. Unfortunately, you can't supply any arbitrary value for i or j. You can only pass an index from 0 to numChildren-1 -- no more absent-mindedly throwing something to 99999, and no more setting depth simply to an object's y position.

The burden of sorting the display list is now the programmer's. Sure, it's a pain in the ass -- but here's where the magic of object oriented programming comes in! You can make a subclass of Sprite or MovieClip and add your own depth property to it:

class DepthSprite extends Sprite
{
private var _depth:Number;
private var _needsSorting:Boolean = false;

public function get depth():Number { return _depth; }
public function set depth(n:Number):void
{
_depth = n;
if(parent is DepthSprite) DepthSprite(parent)._needsSorting = true;
}
}

Now you can sort the display list based on the depths of the children, using any sorting algorithm you please! In my example, I use bubble sort.

protected function sortDisplayList():void
{
// sort my children based on their depths
// (bubble sort)
var len:uint = numChildren;
for (i=0; i < len-1; i++)
for (j=i+1; j < len; j++)
if ( DepthSprite( getChildAt(i) )._depth > DepthSprite( getChildAt(j) )._depth )
swapChildrenAt( i, j );
}

This homebrew depth system also has some big benefits over the old ActionScript 2 depths. For one, you can use floating point numbers for depths instead of integers. Also, you can safely assign two sprites to the same depth, and there will be no flickering (assuming that your sort is stable).

For the sake of clarity, I made the code as simple as possible. But it's slow -- crank the number of particles up to 200, and it starts to chug. There's a lot of room for improvement. Here are some big optimizations:

1. The example code uses a simple bubble sort. This is bad -- it's a slow and unstable sort. More efficient sorting algorithms, like merge sort, would be better.

2. There are lots of calls to getChildAt() and swapChildrenAt(). This actually causes a lot more overhead than you might think! You could store all the children DepthSprites in your own Array, sort the Array, and then rearrange the display list based on the Array. Even better, use a linked list!

3. There are lots of typecasts to DepthSprite. Not only does this cause a ton of runtime type checks, it assumes that all of the children will be a DepthSprite, which might not be true. This goes along with the above idea -- if you use a strictly typed linked list, you avoid the typecasts and you only work with DepthSprites.

see it in action
source

God Hand is truly something special. It is one of the stupidest, most ridiculous, most infuriating games I have ever had the (mis)pleasure of playing. The game oscillates between bad and astoundingly ultra-terrible, at which point it becomes so bad that it wraps back around to amazing. Sometimes.

Here's an accurate recreation of how God Hand came to be:

Clover Studios Game Designer: Hey, guys! Let's make another critically acclaimed, original, and artistic game like Viewtiful Joe and Okami!
Programmers + Artists: Yea!!

Capcom Executive walks in
Capcom Exec: Sorry everyone, making original and interesting games isn't profitable. Clover Studios is now dead, and you will all be reassigned to work on Mega Man Battle Network 9. Bye!
Capcom Executive exits

Clover Studios Game Designer: fuck. Let's all get wasted tonight and make the shittiest game ever.

IGN gave the game a 3.0 out of 10. A 3.0! You know a game is truly in its own class if it can garner a 3.0 from a major reviewer. From the awkward controls, to the weird camera angle, to the hilariously bad dialogue, something went terribly wrong. Every second playing the game will be spent questioning, "Why? What substances must one ingest to produce and/or play this game? What utter contempt for humanity caused this abomination to be unleashed upon the universe?"

And let me emphasize that God Hand is hard. Unfortunately, hard isn't an extreme enough phrase to adequately convey the difficulty of the game. Therefore, the designers summarize the game as ball-bustingly hard. I found this description especially apt -- particularly after I died for the four hundred fifty-sixth time whilst throwing the controller at the wall, thanks to one of the many bullshit enemies.

And the enemies truly redefine "bullshit". Even a single punch will decimate your life bar, sending you futilely searching for one of the random Pac-Man fruit that "reward" you a few pixels of health. In the unlikely scenario that you manage to scrape by and defeat the last enemy, the game flips you off and randomly spawns a demon enemy simply to crush any hopes and dreams of victory.

In fact, the enemies are so unforgiving that they constantly spout obscure Mike Tyson quotes. Not even the funny quotes -- just random, out-of-context ones, leaving you with no clue what the hell anyone is talking about.

For as horrendously difficult and utterly bad as God Hand is, it has one thing going for it:

It is awesome.

In today's world of 16:9 and 1080p, it's becoming more and more important to make sure a game supports a variety of resolutions. A person could be playing on a computer monitor, a 10-inch standard def TV, or the latest and greatest 1080p widescreen. Deciding how to handle widescreen has been a stumbling block in Castle Crashers.

Why is this such a big deal? If we're on a widescreen TV, can't the game just display the extra graphics? Sadly, life isn't that easy -- there are lots of subtle nuances that can have a negative effect on the game.

Unchanging Destiny: Determinism

Determinism means that each event is a direct and inevitable result of everything that has happened in the past. In computer science terms, determinism means that given the same inputs, you'll always get the same output. For a game, the inputs are the player's buttons presses, and the output is the game on the screen. Determinism is a necessary property for a game to have.

Why is determinism so important? The big reason is that all players should have the same, consistent game experience, regardless of what hardware they are playing on. How can differing screen size affect determinism?

In a 2D sidescroller like Castle Crashers, the game logic is tied closely to the size of the screen. The screen stops scrolling when the edge of the screen reaches a certain point. Players and enemies can't move past the edges of the screen. Enemies swing in from just offscreen. The camera zooms out to keep all the players in view. These are just a few of the gameplay elements that are affected by the aspect ratio of the screen. Change the aspect ratio, and the game itself changes.

Ensuring Determinism

It seems like these changes might be small and unnoticeable, but they easily snowball into big problems. Let's look at how to ensure gameplay is unaffected when the screen size changes.

1. Decouple game logic from the display.

A game should be viewed as a state machine, ticking from one state to the next without regard for how it's being displayed. The display is just a "camera" that shows a picture of the game, but should have absolutely no effect on it -- your game will still run just the same if you change cameras, or even if you have no camera at all. This fits in nicely with the Model-view-controller design pattern.

To ensure your game logic is decoupled from your display, avoid writing code like:

spawnNewEnemy( SCREEN_WIDTH+100, SCREEN_HEIGHT+100 );
if( player.x > camera.x + SCREEN_WIDTH/2 ) player.x = camera.x + SCREEN_WIDTH/2;

The enemy's position will vary depending on the size of the screen. The maximum position the player can reach will vary similarly. This violates determinism.

You CAN write code like:

playerHud.x = 10;
playerHud.y = SCREEN_HEIGHT-100;

Naturally, you want the HUD to position itself nicely on the edges on the screen. The HUD will have no effect on the actual gameplay, so doing this is fine!

Unfortunately, decoupling the display in this way is difficult for some types of games. Generally, 3D games are automatically decoupled from the display. On the other hand, many 2D game types rely heavily on the dimensions of the screen -- particularly sidescrollers, where the edges of the screen can play a big role in collision and enemy spawning. This leads to the alternative...

2. Force the game to always use the same size, and letterbox or crop the display.

If your game logic always uses the same size regardless of display type, you have no problem. Unfortunately, you then have to put some blacks bars or other ugly nonsense on the edges of your screen.

Castle Crashers is taking this route. The game itself always runs in a widescreen aspect ratio. On a standard TV, we letterbox the game. Instead of some ugly dead space, we use the extra area to display a nice HUD panel, similar to what Gauntlet does. In widescreen, the game fills the entire screen, and the health bars float on top of the game.

3. Screw it

If you want, you can totally ignore the fact that your game plays differently on one TV than it does on another. Your game is still mostly deterministic, only varying between widescreen and standard televisions. Regardless, this is a Bad Thing -- do you really want your game to play differently for some people than it does for others? It might be slightly harder or slightly easier.

Determinism is also necessary for other aspects of the game. Take multiplayer: say one player is on a standard TV and the other on widescreen. If your game plays differently on the different TVs, how will you possibly be able to keep the two players in sync? Making sure your game plays the same across different hardware will avoid these problems.

Always try to make game logic run exactly the same, regardless of the hardware it is running on.

Check out these videos from the Adobe MAX conference in Chicago:
http://www.peterelst.com/blog/2007/10/
03/adobe-max-chicago-sneak-peeks/

The first video, Flash Next, shows some nice features coming in the next iteration of Flash. But the real gem is the second video, Flash on C/C++. Particularly the demo near the end. I had to pick up my jaw off the ground after that one! Quake in Flash!?

The presentation is unclear on what the technology is actually doing. Is it compiling C source into AS3 bytecode? This is what the video says, but that seems pretty crazy to me, especially after the Quake demo. If you squint at some of the slides in the video, you can see some blurry code: (~02:20 in the video)

var machineC:Class = Class(loader.contentLoaderInfo.applica tionDomain.getDefinition( ... ) );
var xmlPtr:int = __allocString( xml.toString() );
var xslPtr:int = __allocString( xsl.toString() );
var resPtr:int = __call(machineC, xmlPtr, 0 );
var retStr:String = __stringFromMem( resPtr );

This code shows us a lot more about what's really going on. It seems like the machine code is actually being embedded inside the Flash. Some native hooks are provided to place AS3 primitives in memory (__allocString), run the machine code (__call), and grab the result from memory (__stringFromMem).

This is somewhat less practical -- for one, I would imagine that you're losing platform independence if you staple some machine language with your Flash app. Second, it seems potentially insecure -- letting a developer grab pointers to memory is totally contrary to the Flash's draconian security policies! :)

Nonetheless, it's cool stuff! Most interesting to me, though, is that Flash is displaying Quake's framebuffer and playing Quake's dynamically generated sounds. Writing pixels to a BitmapData is still heinously slow in AS3, and there's no built-in way to generate sound from code, aside from the clever audio hack. I suspect functions like __bitmapDataFromMem were added to grab Quake's frame buffer. Something similar that would allow a quick way to draw to the screen would be a great addition to ActionScript.

More games should be the same length as Portal: too short!

Over the past few weeks, I finished up Super Paper Mario and Metroid Prime 3. I had a really long post typed up detailing my opinions on each -- but then I realized that no one wants to read that garbage when they can just go to IGN.

So instead of the long-winded approach, here are some Review Haiku.

Super Paper Mario
cute begets vomit
orthographic, perspective,
jokes beget laughter!

Metroid Prime 3
shaders and wiimotes
polished samus battles bosses
the wii lacks HD

If you're looking for a "real" game experience on the Wii, pick up these two games!

comic-con was totally exhausting, but also a blast!

The sheer amount of awesome Newgrounds users there was astounding. It's really humbling to be surrounded by ultra-talented people! Shout outs to everyone I met, it was great meeting all of you. I'm not even going to attempt to list everyone because I'll definitely forget someone and then they will hate me forever and vow to kill my firstborn child

I didn't hang around the booth too often, because it got pretty crowded with all of us there, and no one particularly cares about a lowly programmer like myself. I spent a lot of my time going to different panels.

Probably the coolest panel I went to were the Cartoon Voices panels. They had all kinds of crazy voice talent, like Rob Paulsen and Tom Kenny. These guys can do such a huge range of crazy voices with such ease and consistency, it's awe inspiring. And nothing beats hearing Yakko's World live, in person, sung totally from memory. :D

Another interesting panel was the Episodic Comics and Games panel. It had the guys from Telltale Games and Hothead Games, who are doing the Sam & Max and Penny-Arcade games, respectively. During the Q&A I asked them what they thought about using a web-based medium such as Flash for episodic games. Their answer was, more or less: "no, flash sucks, you can't get the same experience as you can with a native executable." -- with which I both agree and disagree. I'd be curious to hear any of your opinions on this!

I was at Otakon the week before Comic-con, so I was all conned out by the time we got back on Monday. so I'll leave you guys with this rocking plush boob I purchased from some random vendor in the exhibitor's hall. It's called a "Milk-Chan":