As a small diversion from final exams and Sins of a Solar Empire, I’ve started the analysis for a simple predator-prey system.  I’ve been wanting to code a simulation like this for years; I’m still not sure why I’ve put it off until now.

Take a look at my documentation so far, under a new tab at the top: Predation.  Any feedback, criticism, and commentary is welcome.

I recently picked up Sins of a Solar Empire, a 4XRTS. It’s a great game – well balanced, addictive, fun – the only con is the amount of time it takes to play. A small sized map takes around 4 hours to conquer, and being an addictive game, I don’t want to put it down until I’ve wiped the interstellar phase lanes with the corpses of my enemies.

From a developer perspective, they did a lot of things right with this game. The UI isn’t cluttered (and the empire tree is a fantastic addition), the graphics are great (but not top-of-the-line), the performance is great, and most importantly, it’s fun. I’ve already wasted quite a bit of time taking over star systems, but I keep telling myself that I’m learning from it. We’ll see.

Earlier today, I was sitting outside of Starbucks enjoying a warm cup of tea and a majestic clove, as I often do during the evenings.  This time, however, it was not the usual Barnes and Noble Starbucks – I went to the mall Starbucks.  Anyway, there’s a tree in the parking lot not far from the table I was sitting at, and since I was alone, I had a lot of time to think.  I noticed that there were nearly thirty birds in the tree.

I saw a binary tree with the birds as nodes and the branches as strange, nonlinear edges.  I became curious at that point about whether this binary bird tree was self-balancing or not, and whether it pruned from top-down or bottom-up.  After all, birds are known to exhibit certain emergent phenomena while flocking – is it really so crazy to think that they balance their weight in a tree as well?

. . .

I added a few new features to SpriteViewer.  I’ve also created a dedicated page for it, so I won’t be littering the main page with updates about it henceforth. Check back every so at the Sprite Viewer page at the top.

I made quite a few bug fixes and updates to the Sprite Viewer today. The sprites are now bounded within the Panel in which they are rendered, and they can’t be dragged behind the form controls any longer. Also, the FPS at which animated sprites are rendered can be changed.

Download it here.

I’ve teamed up with the artist over at Stalked by Ninjas to make a 2D side-scrolling platformer with very 8-bit inspired graphics. We’ve been discussing ideas the last few days, and the project is merely in its infancy, but we’re starting to get to work on it. Cole is working on some of the early animated sprites and I’ve been pouring my time (or at least that which hasn’t already been allocated to relationships and school) into creating our first tool. I’ve made a sprite viewer that loads static and animated sprites from their TGA, PNG, or BMP files and displays them for viewing on a variety of background colors. It’s a fairly simple tool, but it has been interesting to write. Download it here (requires framework files found in “About” section of this blog).

Prime numbers are one of the most interesting subsets of the integers. Today, I was asked to provide an algorithmic primality test in my Probability class, and I fought with the problem for several minutes. I of course thought of a naive algorithm to check each number between 2 and n – 1 for divisibility with n, but that just isn’t satisfying (or fast) enough. This really stimulated my thinking, and may have started a new obsession with primes.

One of the solutions presented by my professor was Wilson’s Theorem for testing primality:

if (n – 1)! + 1 % n = 0, then n is prime. However, the obvious problem with this is the factorial operator. That’s going to generate an extremely large number, extremely fast. It’s obviously ridiculously inefficient.

Another method presented was a probabilistic function attributed to Gauss for determining the probability that a given number is prime. I didn’t see it as being very useful, so I’ve forgotten it to make room for more important things.

I was incorrectly under the impression that finding primes was an unsolved problem, however, a little research showed that it was solved in 2002 by three brilliant Indian computer scientists.  Their algorithm builds upon Fermat’s Little Theorem.  I’m considering implementing it for use in my Probability class, since we seem to be finding primes and relative primes frequently.

Well, since that’s a solved problem, I’ve become interested in the ordering of the primes.  I saw a neat gif image showing the Sieve of Eratosthenes in action; perhaps I’ll expand that into a Java applet to start.  It will at least be entertaining.

Artificial intelligence has always interested me. Granted, the beginnings of my foray into pathfinding algorithms doesn’t surpass the tip of the great iceburg of artificial intelligence – in fact, it is more akin to an ice cube floating in a vast, slushy sea of knowledge – but this foray and its implications are important enough that I have chosen to document my findings here.

Pathfinding is a very small bay in the aforementioned vast sea that is artificial intelligence. The purpose of many of the algorithms is to find, as the name implies, the path from here to there in the most spatially and temporally efficient manner possible. Oftentimes it is not possible to be both spatially efficient, i.e. finding the shortest path, and temporally efficient – small big-O complexity.

To start this learning adventure, I decided to code up a quick little application in C# to test basic straight-line pathfinding using a queue of waypoints. This is extremely simple from a programming standpoint, and hardly uses any “artificial intelligence” whatsoever. It is significant in that it provides the basic framework that I can expand upon easily for more complicated algorithms.

Consider two points in the plane. The shortest path between those two points is a vector – let’s call it v. This vector is, inherently, a straight line connecting those two points. The simplest way to calculate this vector is to simply subtract the two points. E.g., in the following figure, the vector v that happens to connect the points a and b is defined as [4-1, 5-2] = [3, 3].

Figure 1.

What purpose does this vector serve? It can be used as a guide to get from point a to point b. Consider any sort of animation framework. It consists of a series of still images being cycled rapidly (commonly between 30 and 60 frames per second) to create the illusion of motion. Thus, to cause a unit at a to move to b, we simply add v to the position of the unit (a, which is also a vector, as any math professor would argue).

a[1, 2] + v[3, 3] = b[4, 5].

The only problem is that this move is done in one frame. It wouldn’t be a very enjoyable gaming experience if the enemy could instantly move to you no matter how far they happen to be from you. Thus, we need to “slow down” the movement over a series of frames. To accomplish this, we first normalize v by dividing it by its length. To be mathematically accurate, we must find the dot product of v and the reciprocal of its length, since vector division does not exist.

L = sqrt(3^2 + 3^2)

= sqrt( 18 )

= 4.24.

v · (1/L) = [3, 3] · (1 / 4.24)

= [3 * (1 / 4.24), 3 * (1 / 4.24)]

= [0.71, 0.71].

Once the vector has been normalized, it can be scaled to whatever velocity the circumstances require by multiplying it by the necessary velocity scalar. For example, 4 pixels of movement per frame:

4v = [0.71*4, 0.71*4]

= [2.84, 2.84]

(total displacement is the length of 4v, or 4.01 – accuracy lost due to rounding to the hundredths place)

Each frame, the unit must update and move at a velocity of 2.84 pixels in the x and y directions, thereby moving at a constant 4 pixels per frame, reaching b in (theoretically) 0.75 frames. Of course, in application, the calculations are all mapped to integer values for individual pixels, and as such, accuracy is lost. The overall effect of this loss of accuracy is negligible in many instances.

Thus, finding the shortest path between two points (in two dimensions) is a very simple matter when there are no obstacles. The most difficult part, though not difficult in comparison to other problems in graphics programming, is getting the unit to behave properly and within the design specifications.

A zip file containing the program demonstrating straight-line pathfinding without obstacles can be found here. It uses a queue of waypoints that are navigated in order. Simply right click to add a waypoint, and the squido guy will “find” his way to it. You’ll need both .NET framework updates (1.1, 2.0) and the XNA framework, which requires at least XP SP2.