Eye Sees You

Recently I’ve been sidetracked with a project (which I will go into more detail about later). That project was sidetracked briefly to answer the question: how does one orient a 3D model to point at something? You might need to use this should you want to point a ship at a specific star, or have a moon tidally locked to its planet so that one side of the moon is always facing it. For my case specifically, it was how to orient eyes on a model to track the mouse. It has a deceptively simple premise, but a non-obvious answer.

[World]

By now, if you’ve read any 3d tutorials on the Internet, you’re familiar with the world/view/projection matrices. A model in model-space has its coordinates run through a series of transforms which first is moved to world space, then modified to be what the camera sees, then projected onto the screen. The only matrix we need to worry about changing is the world matrix, although all three are eventually used to make this work.

[Eye Spy Axis Angles: X-eYe-Zed]

When I first approached this problem, I assumed it was a simple matter of rotation. Basically one should be able to work out the angle difference between the object’s forward face and the point to look at, and then you rotate around the relevant axes.

Axis Angles between two 3-dimensional coordinates

My first attempt at working this out involved using the atan2 method to figure out the angles for two of the axes. The atan2 function will compute the angle in radians between the positive x-axis of a plane and the point given by the coordinates (x, y) on it. I figured that you could compute the angle difference in the X-Y plane, and the angle difference in the Y-Z plane those would give you the amount of rotation required to orient your model.

Why using atan2 only on each plane individually doesn't work

It turns out that you cannot compute them individually, and the figure on the left demonstrates why. You can work out the angle in one axis, but then you also need to rotate the coordinates before working out the second angle.

Once you do have the proper angles, you can either create a series of rotations using Matrix.CreateRotationX/Y, or you can use Matrix.CreateFromYawPitchRoll. There are example of how to do both in the sample source code provided (see below).

There’s also a third solution available, which is to use an inverted Matrix.CreateLookAt. The pertinent information came from a post on gamedev.net by MJP:

“…but a view matrix is just the inverse of a “world” transformation. If you think about it makes sense: a world matrix takes something and transforms it from its local space to it’s actual world position and orientation. A view matrix takes things that are in their world position and orientation, and transforms them to a coordinate space local to the camera.”

[Where Am Eye?]

A mouse cursor on the screen, by definition, exists solely on a plane in the projected scene. Which plane you want it to exist in depends on many factors, including your camera’s field of view, your aspect ratio, near/far plane distance, et al. One of the problems I encountered early on was that my model just didn’t appear to be looking at the mouse cursor. To figure out what was going wrong, I wrote a very simple program to reduce all possible variables involved in orientation. It’s an eyeball model at (0,0,0) set to point at the mouse. When trying to figure out what the Z value should be, I got wild variations on orientation. For example:

Eye pointing at mouse in lower left corner with Z = 0. Doesn't look right.

Eye pointing at mouse in lower left corner with Z = 0.5. Looks better, but still not quite right.

Eye pointing at mouse in lower left corner with Z = 0.8. Looks pretty good.

Eye pointing at mouse in lower left corner with Z = 1. Too much? Sometimes more isn't better.

By placing the mouse at Z = 0.8, it “looks” realistic. Choosing a proper Z value only matters if you’re orienting something towards the mouse. If you’re doing mouse picking in 3d then you’ll just cast a ray from the near plane to the far plane.

[But There Aren't Any Bones In An Eyeball]

Before this project I had never attempted to load a model with XNA and seriously do anything with it. So, in attempting to do something so simple I ended up learning a great deal. First, though, a little about the model.

Early attempt at eye tracking. I unprojected the mouse based on a world matrix that didn't take into account the bone transform of each eye.

The model consists of 7 pieces: the mesh for the M; left/right eyeballs; and upper/lower eyelids for each eye. The FBX format allows you retain the names of individual meshes. So, for example, I have names like EyeballLeft and EyelidRightTop. This allows me to see which mesh I’m dealing with in the foreach loop one uses to draw a model.

However, unlike the AxisTest demo where the eyeball resides at the origin with no transforms, the eyeballs on the logo are slightly offset. The mouse coordinate needs to be unprojected for each eye using the current world matrix and their absolute bone transform. To get access to that information we have to snag some extra info from the model.

Inside the model is a Matrix[] of transforms, and you can get at this array using Model.CopyAbsoluteBoneTransformsTo() which allows access to the matrix representing the location of a specific mesh. It is useful to know this information if, say, you wanted to know where an eyeball was. In the example, I have drawn XYZ orientation of each eyeball based on the center of that eye. To get the actual location, you would use
location = Vector3.Transform(Vector3.Zero, transforms[mesh.ParentBone.Index]);
That is, you transform (0,0,0) against the bone matrix of the indexed parent bone and this will give you the relative offset in model coordinates.

[You're Not Being Helpful. Eye Just Need Code]

Alright, alright. So there are [at least] four ways to easily construct a matrix to orient a model towards a position in space. If you use them and your mesh doesn’t orient properly, go reread the above for more information as to why.

public Matrix LookAt(Vector3 position, Vector3 lookAt)
{
    return Matrix.Invert(Matrix.CreateLookAt(position, -lookAt, Vector3.Up));
} // Matrix LookAt()

public Matrix LookAt2(Vector3 position, Vector3 lookAt)
{
    Matrix rotation;
    Vector3 diff = lookAt - position;
    // Calculate the angle for rotation around the y axis
    float angleY = (float)Math.Atan2(diff.X, diff.Z);
    rotation = Matrix.CreateRotationY(angleY);
    // Calculate new forward vector so that we can
    // construct our own virtual coordinate system
    Vector3 newForward = Vector3.Transform(Vector3.Backward, rotation);
    newForward.Normalize();
    // Calculate rotation around x axis from virtual coordinate system
    float angleX = (float)Math.Atan2(-diff.Y, Vector3.Dot(newForward, diff));
    // Calculate proper rotation matrix
    rotation = Matrix.CreateRotationX(angleX) * Matrix.CreateRotationY(angleY);
    return rotation;
} // Matrix LookAt2()

public Matrix LookAt3(Vector3 position, Vector3 lookAt)
{
    Matrix rotation;
    Vector3 diff = lookAt - position;
    // Calculate the angle for rotation around the y axis
    float yaw = (float)Math.Atan2(diff.X, diff.Z);
    rotation = Matrix.CreateRotationY(yaw);
    // Calculate new forward vector so that we can
    // construct our own virtual coordinate system
    Vector3 newForward = Vector3.Transform(Vector3.Backward, rotation);
    newForward.Normalize();
    // Calculate rotation around x axis from virtual coordinate system
    float pitch = (float)Math.Atan2(-diff.Y, Vector3.Dot(newForward, diff));
    // Calculate proper rotation matrix
    rotation = Matrix.CreateFromYawPitchRoll(yaw, pitch, 0);
    return rotation;
} // Matrix LookAt3()

public Matrix LookAt4(Vector3 position, Vector3 lookAt)
{
    Vector3 diff = lookAt - position;
    // Calculate the length of the vector along the X-Z axis
    double xzLength = Math.Sqrt(diff.X * diff.X + diff.Z * diff.Z);
    // Calculate the angle along the y axis
    double yAngle = Math.Acos(diff.Z / xzLength);
    double vecLength = Math.Sqrt(diff.X * diff.X + diff.Y * diff.Y + diff.Z * diff.Z);
    double xAngle = Math.Acos(xzLength / vecLength);

    // Check to see if there is no rotation whatsoever for one axis
    if (xzLength == 0)
    {
        yAngle = (diff.X > 0) ? MathHelper.ToRadians(90) : MathHelper.ToRadians(-90);
    }
    else
    {
        yAngle = Math.Acos(diff.Z / xzLength);
    }

    xAngle = Math.Acos(xzLength / vecLength);

    // Determine which quandrant it actually falls into
    if (diff.Y > 0) xAngle = -xAngle;
    if (diff.X <= 0) yAngle = -yAngle;

    return Matrix.CreateRotationX((float)xAngle)
           * Matrix.CreateRotationY((float)yAngle);
} // Matrix LookAt4()

All of these assume your model’s front is +Z.

Many thanks to Firzen for working out the math on the LookAt2() and LookAt3() method. Also, many thanks to Malcolm Kesson for the LookAt4() method. There are probably other ways to implement this using quanternions, but that will be the subject of another post. All of the above methods can be seen in action in the AxisTest demo.

[The Eyes Have It]

One last note: to actually render realistic eyeballs is relatively complicated. The eyeballs rendered for the M are neither complicated nor accurate. They’re basically squashed spheres with part of it coloured black. The eyeball used in the AxisTest is one of the ones used in the M logo, but subsurfed. Unfortunately, this extruded the iris/pupil area and I’m currently not well enough versed in Blender to fix it.

[Summary: Eye Puns Result In Terrible Grammar]

To summarize how to make an object track the mouse:

1. unproject the mouse cursor using the view/projection matrices and the world matrix relevant to your frame of reference (including bone transforms if applicable), paying close attention to which plane the mouse is in
2. adjust that world matrix with another matrix that orients the object to the 3-d coordinate returned by the unprojected mouse
   
3. ???
4. Profit.

[References]

http://rbwhitaker.wikidot.com/basic-matrices

http://www.fundza.com/mel/axis_to_vector/align_axis_to_vector.html

http://www.gamedev.net/topic/539045-xna-matrixcreatelookat-not-behaving-as-expected-when-changing-the-up-vector/

http://www.enchantedage.com/xna-picking

http://elenilib.firzen.de/

http://www.3dluvr.com/rogueldr/tutorials/eye/eyes.html

http://www.andrew-whitehurst.net/eyeTut.html

http://wiki.blender.org/index.php/Doc:Manual/Modifiers/Mesh/Subsurf

http://en.wikipedia.org/wiki/Atan2

http://msdn.microsoft.com/en-us/library/system.math.atan2.aspx

http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.model.copyabsolutebonetransformsto(v=XNAGameStudio.40).aspx

http://joestevens.net/xna/alternate-view-matrix-construction/

[Downloads]

http://www.monstersoft.com/download/AxisTest.zip (359000 bytes) (C#/XNA 4.0 Source; Public Domain)

http://www.monstersoft.com/download/AxisTestDemo.zip (39104 bytes) (Binary only)

[The Elegant Uni...List]

A fellow denizen in the ##XNA channel on FreeNode had an inquiry involving a foreach() loop and deleting items.

The general idea is that you have a list of items, and some of those items you may want to delete out of the list as you’re traversing it. You can do this with multiple lists, using a queue where you requeue items, tagging what should be deleted, etc. But none of those are elegant.

So, let’s say you only want a single list, you don’t care about the order of the items in said list, and you want to iterate over it exactly once. For all the elements in the list: if you find one you want to delete then you swap it with the “last” element, recheck the current index, and decrease the total count of items in the list. Generically it would look like:

lastIndex <- list.Count
for index <- 0 to lastIndex
   do if list[index] is to be deleted
      then
         swap(list[index], list[lastIndex])
         index <- index - 1
         lastIndex <- lastIndex - 1

list <- { list[0] .. list[lastIndex] }

Voilà.

[Sample Code]

Here’s an example that will check if elements in a List are even, and remove them. Note that the ending order won’t necessarily be the same as the starting order. Also, this system works for reference types.

using System;
using System.Collections.Generic;

namespace ListDelete
{
    class Program
    {
        static void Main()
        {
            List<int> MyList = new List<int>() { 1, 2, 7, 3, 4, 4, 5, 5, 6, 7 };

            int lastIndex = MyList.Count;
            int index = 0;
            for (index = 0; index < lastIndex; index++)
            {
                if (MyList[index] % 2 == 0)
                {
                    // swap this element with the last element
                    var x = MyList[index];
                    MyList[index] = MyList[lastIndex-1];
                    MyList[lastIndex - 1] = x;

                    // recheck this index
                    --index;

                    // decrease our total number of elements to be worked on
                    --lastIndex;
                } // if
            } // for index

            // remove the elements we no longer wanted
            MyList.RemoveRange(index, MyList.Count - lastIndex);

            // Display the remaining elements in the list
            foreach (var item in MyList)
            {
                Console.WriteLine(item);
            } // foreach

            Console.WriteLine("Press any key to continue...");
            Console.ReadKey(); // Wait for user input to exit
        } // void Main()
    } // class Program
} // namespace

The output of the above is:

1
7
7
3
5
5
Press any key to continue...

[Links]

http://blog.zachfogg.com/

[The Mouse]

Add the following to your using statements:

using System.Runtime.InteropServices;

Inside your Game class, add the following:

[DllImport("user32.dll")]
static extern void ClipCursor(ref Rectangle rect);
[DllImport("user32.dll")]
static extern void ClipCursor(IntPtr rect);

Add the following code to your game’s Initialize() method:

this.IsMouseVisible = true;

Rectangle rect = Window.ClientBounds;
rect.Width += rect.X;
rect.Height += rect.Y;

ClipCursor(ref rect);

Finally, inside your game’s Update() method add:

if (IsActive)
{
     Rectangle rect = Window.ClientBounds;
     rect.Width += rect.X;
     rect.Height += rect.Y;

     ClipCursor(ref rect);
}

[The Trap]

A few things to note about the above. The ClipCursor() function expects a pointer to a Rectangle, so we pass in a reference. To allow the cursor to move freely anywhere on the screen again, one has to pass null instead of a rectangle. Since you can’t pass in a null reference in C#, we have to overload the ClipCursor() function with a second one that allows for a null parameter (IntPtr rect).

ClipCursor() assumes that the rectangle contains the coordinates of the bounding area. Window.ClientBounds contains an XNA/C# style rectangle, which is defined by (X, Y, Width, Height). To get the actual bounding area, one has to adjust the Width/Height with the X/Y.

There is some debate over whether keeping the mouse inside the window border is a good idea or not. Situations where it’s required are probably pretty rare, but there are some high-profile games that do it (e.g. Minecraft).

[References]

http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.input.mouse.aspx

http://msdn.microsoft.com/en-us/library/ms648383(v=vs.85).aspx

http://forums.create.msdn.com/forums/p/3553/18364.aspx

I encountered a fair amount of pain trying to get various forms of serialization working. There’s a nice long article which may or may not ever see the light of day about that. Regardless, this post is specifically about how fast certain serialization techniques.

[The Techniques]

So, what forms of serialization are there? The main ones covered with any depth here will be:

[The Gotchas]

Here’s the thing: every form of serialization has some form of drawback.

There is a more in-depth writeup about the pros and cons of serialization techniques by Iván Loire.

[It's a Big, Big, Big World Out There]

When creating a Hextille<> data structure, you pass in a radius which represents how many cells you can go between the origin and the edge of the “map”. The formula for determining how many cells there are is as follows:

Each cell (vertex) contains path information (edges) to adjacent cells, including the destination, a cost and whether the path is open. For a Hextille<> with a radius of 1000, you’re looking at 3003001 vertices (the center cell is the odd one out) and 18006000 edges. The benefits (or at least the detriments) of this implementation are moderately clear. On the one hand, since this isn’t implemented using flat arrays, you need to have some contextual information about your location and the destination location. That adds a little bit of overhead to each cell and each path. On the other hand, you are given the ability to have a true graph structure and quick lookups, not to mention the ability to have a path to non-adjacent nodes. Since I’m also storing references to adjacent nodes, that creates a situation where memory becomes an issue at about R=1200. One positive aspect of this system is that extensions to the HexNode class don’t proportionally add much more to the map sizes.

For most potential games using this system, I don’t foresee needing more than R=100 for any individual map (and maps can be stitched together regardless).

[I Feel The Need... The Need For Speed]

So, given the above list of serialization options, how did they fare?

Horribly.

The first thing I did was to try out [Serializable]. The speed was poor, and every subsequent test just produced worse results:

Serialization Saving Time (Click for larger image)

The methodology employed was to create a Hextille<> of radius R (0 to 99), save it and then reload it. Since there was some overhead involved in creating the file, and saving a single cell time was so small, I tossed out all the 0-radius times. I used a binary formatter to serialize.

From the above it becomes obvious that the best “serialization” technique is to simply use the default [Serializable] attribute tag. For raw speed though, nothing beat simply outputting the data as binary. More on that below. The worst result — the IXmlSerializable Interface — took nearly 10 seconds to save a Hextille<> of radius=100. One might be able to get away with that in a map editor, but for anything real-time that just won’t work.

Loading times produced interesting results:

Serialization Loading Time (Click for larger image)

Here, again, we see [Serializable] as the best choice for “serialization”. What I found surprising was that the loading times for using either interface method came out about the same. Still, the loading time for a Hextille<> with R=99 took nearly 25 seconds to load. That’s simply unacceptable for a game.

However, the BinaryReader was blazingly fast. So fast that I quadruple-checked to ensure it was working properly. Want to know how fast it is? When creating a Hextille<>, the constructor will link the cells together with proper path information, which also contains a reference to the destination node. Obviously you cannot serialize a reference to an object in memory, so that information is lost when saving. To fix this, one has to re-link the references at load time. This re-linking isn’t included in the timing for [Serializable], ISerializable, or IXmlSerializable. Only the BinaryReader loading technique implemented the re-linking (so I could check it was importing properly). The time above for BinaryReader includes the re-linking. It’s that fast.

["All Programming Is An Exercise In Caching" -- Terje Mathisen]

“Okay”, I hear you think, “But what if the data is fitting nicely into the file cache when using the BinaryReader?” Well, that’s a good point. Outputting just the binary loses all type information, and everything is nicely aligned and small. What about that?

BinaryReader/Writer Times for Hextille<> Radius = 1 .. 250 (Click for larger image)

That’s obviously not the issue. A Hextille<> with a radius=250 has 188251 vertices and 1126500 edges and still it only took about 2.5 seconds to handle.

[Conclusions]

Even with the BinaryReader/Writer being the clear winner for storing or transmitting data, I still see uses for going with the [Serialization] attribute method. Losing type information is a big deal in situations where you may not know how the object was originally stored. It’s also ridiculously simple to add support to a project. I am a big fan of the fire-and-forget methodology, and so I will be revisiting using [Serialization] in the future.

Using XML to store data that doesn’t need to be edited by a human with a text-editor is a bad idea. There’s very little benefit, and if you’re going to go that route you might as well use something like JSON, provided you don’t need to store dictionaries that aren’t <string,object>. (There may be a fix for that, I’m still looking and will report back when I know with any certainty).

Overall, the most surprising thing was that using the ISerializable Interface turned out to be slower than the built-in method. I would have figured it to be faster since you control exactly how the object gets serialized. In a future post I’ll track down exactly why this is the case.

[References]

http://www.diranieh.com/NETSerialization/XMLSerialization.htm

http://weblogs.asp.net/pwelter34/archive/2006/05/03/444961.aspx

http://www.dotneat.net/2009/03/22/NETSerializationUsingBinaryFormaterSoapFormatterAndXmlSerializer.aspx

(Those are in separate videos).

Recommended For You: Kinessiology for Kids workshop from Touch for Health

Recommended For You: S 036 Tastsinn / sensory cells in skin for touch

Today we get:

Recommended for you: “Einkaufen in St. Martin” because you watched “Martin Ebner – NULLPANORAMA”

[Shiny Things]

As geeky as this is to admit, I really like the symmetry of hexagonal shapes. I do chainmaille as a hobby and several of my favourite weaves are 6-in-1 European and 12-in-2 Japanese.

12-in-2 Hexagonal Weave by Sara Richardson

(I’m also a big fan of Fieldstone, which are 3 parallel rings interlocked with a second set of 3 parallel rings with a dihedral angle of 90°).

Interestingly, the image demonstrates the relationship between hexagonal shapes and circles, and is called circle packing. A hexagon is the densest arrangement of equal sized circles on a 2-dimensional plane. Each cell is connected to other cells by links in increments of 60°. The above picture also foreshadows some additional features our hexagonal map will require, as represented by the purple rings. More on that in a moment.

[Hextille. Rhymes with style or steel?]

The first thing to define is what a grid is. In the context of a game, a grid generally represents a logical arrangement and subdivision of a playing field, and each individual location on a grid is known as a tile. Take, for example, a chessboard. The board itself is broken up into an 8×8 grid of individual tiles.

2D Chessboard (left); 3D Chessboard by Ji Lee (right)

A group of tiles is called a grid and a group of hexagonal tiles is called a hextille. I’m still unsure if it rhymes with “style” or “steel”, and it’s printed as both “hextille” and “hextile” on Wikipedia.

Even though they look different, the board on the left and the board on the right can be represented by the same data structure. Only the visualization of the data would need the additional information of height, which can be stored separately. From a programming perspective, this sort of grid can be easily represented by a 1- or 2-dimensional array, with the latter being more common.

Ok, so you could use an array to represent the grid. But, an array of what? For a grid as basic as chess or checkers, you might store what piece is present as an integer. That information is contained to a single tile, and it would be the equivalent of the larger chrome coloured rings above.

But what if you need to store more information? E.g., a maze where moving into some adjacent squares isn’t allowed, or there is some sort of cost associated with moving onto another tile. This sort of information would be akin to the purple rings in the chainmaille example above. The information is only relevant if there is an adjacent tile. We’ll need some sort of record that holds all the relevant information. In graph theory, that sort of record is called a node. Since we’re working with hexagonal shapes, naming it HexNode seems apt.

[Pointy Side Up]

If you are looking from above on a normal rectangular grid then each tile will have 4 adjacent neighbors (one every 90°) in the directions of left, right, down, and up. When dealing with a hextille, you end up being able to move in 6 directions (every 60°): upper-left, upper-right, lower-left, lower-right, and… well, now you have two options. You can either orient the map so you get up/down, or left/right (henceforth known as “pointy side up”). The orientation may not make much difference to an observer of the grid, as they are simply the same thing rotated 90°. However, it somewhat does matter internally because it may affect things like naming and the coordinate system.

Hextille with Left/Right (left); Hextille with Up/Down (right)

It may also matter depending on how you store each node. If you were using an array, the map with the pointy side up would make more logical sense, since it’s almost the equivalent of a rectangular array with every other row shifted by 1/2 of a unit. I’ve opted for the pointy side up version for a couple of reasons. One is because it reminds me of Q*Bert. The other is because of where (0,0) is.

[Where Am I?]

So far we know that hexagons have a close relationship to circles. So, if you needed to decide where the origin of a circle would be, what would be the logical choice? The center.

Hexagonal Coordinates from Overhead (left); Right-handed Cartesian Coordinate System (right)

The image on the left (original concept was from Juha-Mikko’s blog) places the origin in the center and shows the X- and Y-axis. Placing the origin in the center does several things to the implementation of the maps. The first is to make the maps definable by a radius. The second is the need to use an implementation that doesn’t mind negative coordinates. If you were using an array (or, specifically a jagged array), you would need to do some sort of translation from hextille coordinates to array coordinates. There’s actually an elegant solution for the negative array coordinates problem that doesn’t involve shooting yourself in the foot. Obviously using pascal (with its definable array subscript ranges) would be a solution, but I’m going to be writing this in C#. I’ll get to the actual implementation in the next post.

As for the axes, we’re using a right-handed coordinate system. The X value increases as you travel down and left. The Y value increases as you travel down and right. If we’re working with 3d points, the Z value would increase as you come towards the viewer. This is somewhat arbitrary and left up to personal preference.

[Plan For Today, Prepare For Tomorrow]

It is common knowledge that one should start small and work up. Well-designed software rarely congeals into existence after an evening of hacking it together. At this point I have a rough starting point with which to put something together and experiment with it. While hindsight is 20/20, I’m writing this without that luxury. So, I need to think ahead.

Here’s a list of items that I think I’ll need at some point in the future:

• Saving to disk (serialization)
• Flexible data nodes for future projects
• Path traversal including movement costs
• Gluing hextilles together
• Stacking hextilles on top of each other (layers)
• Higher resolution coordinates for movement within an individual cell
• The ability to iterate over each node

Of all those, only the last two are tricky. With all this in mind, I’ll cover implementation as I go along starting in the next post.

[Summary]

Chainmaille is shiny. Hexagons are a dense packing of circles. Rectangular packing of tiles is called a grid. Hexagonal packing of tiles is called a hextille. Only store needed info. Pointy side is up. Origin is in the middle. No need to use arrays. Think ahead.

[References]

http://www.jewelrymakingdaily.com/blogs/daily/archive/2011/01/17/learn-japanese-12-in-2-chain-maille-weave-in-6-steps.aspx

http://en.wikipedia.org/wiki/Circle_packing

http://pleaseenjoy.com/project.php?cat=1&subcat=&pid=16

http://en.wikipedia.org/wiki/Hexagonal_tiling

http://www-cs-students.stanford.edu/~amitp/Articles/HexLOS.html

http://jmz.iki.fi/blog/programming/hexagonal_maps (Dead link at the time of this writing)

http://www.dev102.com/2008/11/10/10-ways-to-shoot-yourself-in-the-foot-part-a/

The first time I noticed this was when I watched a Blender 2.5 Tutorial For Beginners. What — in its infinitely confusing wisdom — did it recommend for me based on that video?

It recommended “Minecraft Lets Play Special”. Alright, I guess that’s not entirely unreasonable. I’ve watched a Minecraft Let’s Play in the past. Perhaps it was just a fluke.

A few days later a discussion arose in the ##XNA channel on FreeNode about an alien abduction game. I eventually stumbled across a video on youtube. The next day it happened again.

Recommended for You: “Twitter und Kompetenzentwicklung” because you watched “Cows vs Aliens”.

What?

And then again a few days later:

Recommended for You: “Martin Ebner – NULLPANORAMA” because you watched “Twitter und Kompetenzentwicklung”.

What? What?

I’m going to follow this to see just how deep the rabbit hole goes.

Nuclear Insanity

Many moons ago a small team of highly motivated and extremely talented people got together to make a game: a tetris clone based on another tetris clone called Atomic Tetris by Jared Tarbell. Initially we had named ours Nuclear Tetris and then to Nuclear Insanity (for trademark reasons). The program was a 16-bit real mode application written in a mix of assembler and pascal. It was filled with many unknown bugs, nightmarish and completely unmaintainable code, all of which relied heavily on a global variable named “q”.

Fast forward to the beginning of 2011 when I decided to learn XNA and C#. I figured the best way to do so would be to port something familiar, and seeing as how Nuclear Insanity no longer ran on modern hardware, it was the ideal choice.

There were a few technical challenges in porting a 20 year old game. I somewhat regret not keeping an active journal of the effort, as it surely would have helped others. It’s one reason I’ve started this blog.

[Then]

Nuclear Insanity was originally worked on by 8-10 people under the banner of Ashgon Inc. circa 1992 and was later published in April of 1993. A majority of the game code was written by me. The graphics were done by several people, most notably Ken Nichols and Payton Whitaker.

The Original Nuclear Insanity

[Slightly After Then]

After the commercial release of Nuclear Insanity, Justin Harker went back into the code and added proper music support. By this time we had formed the New Order Demo Group and re-released under that moniker. There were some minor modifications to the graphics and a few bugs were fixed.

[Slightly Before Now]

The Nuclear Insanity Project (henceforth known as NI) began in mid-January of 2011. The first priority was tracking down all the assets for the game, which included the source code, music, graphics, file formats, and tools. None of the original programs used in the making of the game still worked. Because we wrote the custom tools to make the graphics — including DannyPaint with its own clever RLE compression scheme called MOOISHI! — I had to write a custom content processor to decompress the .msh files.

My intent was to make the modern NI port fairly faithful to the original game. Most of the graphics made it back in, even some that primarily went unused. I was quite torn on whether or not to use Joel’s first graphics set, as he put a lot of effort into them. In the end I decided it better to have a near-identical clone than try to fit the older work in. However, what he did was truly a work of art considering the tools available at the time and they are worthy of inclusion here:

Akira Inspired NukeTet Title

Nuclear Tetris Title and Setup Screen

Keep in mind that neither DannyPaint nor the icon editor (MyIcon IV) had mouse support. Save for a few rendered items and procedurally generated graphics, the bitmap graphics drawn for the blocks, fonts, and the screens were all done by hand. Pixel by painstaking pixel with the occasional flood-fill, all in 256 colours.

At some point in the future I may go into more details about some design decisions made in porting the code. The only major change I made was the option screen. The original was a nightmare and since some of the original limitations were no longer present (e.g. being able to use any key on the keyboard) I had to redesign it.

Original Option Screen (Left) and New Option Screen (Right)

Some of the module system will be reused in upcoming projects, so I will go over those in more detail as they come up.

[Now]

So, that brings us to where the game is at today. It took almost exactly 2 months from start to finish, with an additional month dragging my heels on moving from IsolatedStorage to using StorageDevice. I’ve decided to release the code into the Public Domain, so that others may learn and use what we’ve done. You can download the Nuclear Insanity C#/XNA source or just the Nuclear Insanity binaries.

One Player Mode (Left) and Two Player Mode (Right)

[Epilogue: Wisdom +1]

What have I learned from NI? Beyond the mostly pleasant experience of using C#/XNA, I found that the game itself is nothing special. It’s a highly polished copy of another game, which in-and-of itself is a copy of the original Tetris (doesn’t everybody make a Tetris clone at some point?). The experience, however, was something special. What made it so were the people working on it, from the talented artists to the awesome coders and musicians. I was lucky to be around them and inspired by them. Reaching the destination of finishing a game is very rewarding, but the journey itself is far more meaningful.

[Downloads]

http://www.monstersoft.com/games/NuclearInsanity/NuclearInsanitySource.zip (47168095 bytes)

http://www.monstersoft.com/games/NuclearInsanity/NuclearInsanity.zip (35041891 bytes)