Moving backgrounds, different speeds

Back when I was younger (which is an obtuse way of saying “I haven’t the friggin’ idea exactly when”), I dabbled a bit in game development. There was a period when I was studying side scroller games. Remember those? The classic Super Mario Brothers was one of them.

I also noticed that in some of the games, the backgrounds moved. Yes, backgrounds, plural. I could understand forming a background “tile” made up of hills, clouds, trees, grass, flowers, rocks and whatever suited the game as background. But there was something, else, moving in the (for lack of a better word) background.

There was another background layer, moving at a different speed. Wait. Oh, it’s moving at a slower speed.

When I moved that little sprite (that’s representing my sole means of interacting with the game) on the screen to the right, the flowers and trees and rocks sped past to the left. But that faraway mountain was moving to the left at a slower speed. And the overall effect was a realistic simulation of 3D, a semblance of depth in an essentially 2D game.

Now that I think about it, I have one question. How do you calculate how slow the other background should be? I searched high and low, though I found what this effect is called (parallax scrolling), I found no trace of any suggestion to the relative speeds between the 2 backgrounds.

So I did a little thinking. And drawing. I was trying to work out mathematically the slower speed, given the “distance” between the background layers (there’s practically no distance in implementation. Maybe 0.01 units…) and the speed of the background that’s “in front”.

It didn’t make sense, because no matter how I pivot the movement, the calculations don’t work out.

L1 and L2 are the “distances” between the respective layers. d1 and d2 are the distances from the objects in question to the perpendicular line formed by the sprite position. v1 and v2 are the velocities of the respective layers moving to the left (or right, depending on how you view this whole thing and how you define the direction… never mind).

The layers aren’t really separate. There is a tiny distance between the layers, say 0.01 units. If you’re in a fully 2D environment, then the farthest layer is drawn, then the next closest layer is drawn, subject to transparency to allow elements from the farthest layer to be shown, and then the playing layer is drawn (where our sprite and other objects are). There’s no distance (between the layers) to speak of in a true 2D rendering environment.

I started with the “don’t move the focus, move everything else” approach, keeping the sprite in place, and moving both backgrounds to the left. This meant pivoting around the sprite. The objects drawn on the other two layers are what our sprite would see in a straight line towards somewhere forward. Those objects should coincide at the “perpendicular” line together.

Since the distances d1 and d2 are obviously different, therefore the velocity (or speed. I’m just trying to be scientifically correct here) of the two objects moving to the left must be different. There lies my problem. It meant the farthest object had to travel faster, contradicting our original observation.

What if we pivoted around the object in the “front” layer? The sprite moves to the right, and the object on the “back” layer moves to the left, and all three line up in a perpendicular line (perpendicular to the layers anyway). Too troublesome. Same with pivoting around the farthest object.

I toyed with the idea of pivoting around the vanishing point. At this point (no pun intended), I decided to give up.

So I assumed that the background image(s) in the “back” layer are appropriately sized with respect to the “front” layer. I decided a simple ratio probably worked best. Thus we have
v2 = v1 / (L1 + L2)
which should give an appropriately slowed velocity.

And now, finally, I’m telling you this. It might not matter. What matters is that you test the velocities, and if the 2 background layers scroll at a pleasing velocity, then there you have it. Ultimately, we’re just trying to simulate a 3D perspective given a 2D environment. If it’s believable, then that’s the correct velocity.

Multi-sensory input in artificial intelligence

Artificial intelligence has always been one of my favourite topics of interest. Artificial intelligence or AI, as it’s commonly known, is

the study and design of intelligent agents where an intelligent agent is a system that perceives its environment and takes actions which maximizes its chances of success.

I think of AI more in terms of simulation. How can a certain behaviour be simulated? How can a certain phenomena be simulated? For example, flock behaviour can be simulated using simple rules yet resulting in complex patterns. I’ve even tried my hand at computer virus simulations.

There was a time when I was into game development. I mean, like really into it. I joined an independent game development group. Can’t remember from where (I think I found the group from GameDev). Can’t remember the group name too (I think it has a “rhino” somewhere…)

Anyway, there wasn’t much documentation yet, except that it’s a “get the flag” kind of game (kinda like paintball). I was in charge of the AI component for simulating the computer controlled opposing team. Since this genre was new to me (I don’t play these kinds of games, real life or otherwise), I had to do some research and thinking.

I came up with using a visual and aural component for the AI. The enemy would have the standard 60 (or 45 or 90) degree field of vision, and this has a cutoff distance (or a gradual decline of visibility). Then there’s 360 degree aural sensory input, but with a small cutoff distance.

This allowed seeing long distances but with a narrow scope. Rendering fog only limits the player. Computer controlled enemies can see till infinity, hence the cutoff distance. Well, if we limit the vision, then a player can sneak up to an enemy from behind and whack him on the virtual head. Not realistic.

So I thought up a 360 degree “alarm” system by incorporating an aural component. Any sound made by the player such as moving on sand (or water or gravel) and firing would alert the enemy (from behind, sideways, anywhere).

I was going to add in some sensitivity control to the aural component, like more receptive from in front than from behind. Then I decided that long distance communication, slow responses and school work was too much. So I sent a polite email to the team leader saying I’m glad to have been part of the team and I really need to focus on my studies. Then I left.

That ended my short-lived stint as a game developer.

This just came into my mind. In a virtual environment, autonomous agents can be omnipresent and omniscient. They can be anywhere in the blink of an eye and know everything. In a virtual environment, we try to limit the capabilities of our simulations to create a believable, realistic character.

In the real world, we try to expand the capabilities of our simulations running in robots. In our physical world, robots already face lots of limitations.

I see a squeeze theorem event waiting to happen…

Rapidly calculating Bezier points

The standard cubic Bezier curve is given by
B(t) = (1-t)³p0 + 3(1-t)²tp1 + 3(1-t)t²p2 + t³p3
where p0, p1, p2, p3 are the control points and t is in the interval [0, 1].

Very elegant, but not very practical. Too many multiplications and additions to be used in a fast-paced environment such as game development. If it’s a 3D Bezier curve, 3 separate calculations are needed for the x-, y- and z-component for a given t value. What we need is a simplication of the equation.

Expanding the polynomial equation, we have
B(t)
= (1 – 3t + 3t² – t³)p0
+ (3t -6t² + 3t³)p1
+ (3t² – 3t³)p2
+ t³p3

Rearranging the coefficients of tⁿ, we have
B(t)
= t³(-p0 + 3p1 – 3p2 + p3)
+ t²(3p0 – 6p1 + 3p2)
+ t(-3p0 + 3p1)
+ p0

The coefficients can now be reduced to constants by precalculating them, and calculation of a Bezier point takes less computation.

In matrix form, the equation looks like