As you unlock levels you also unlock new towers and upgrades on previously unlocked towers. I’m not entirely sure how to make all this self explanatory yet. Also, it feels like the game is missing something, it feels kind of stiff. Not sure what exactly. I like the simple graphics and I don’t wont to spend to much time on that, but it might be that enemy movements are too much moving along a rail. I might make that more organic in a future version.

Thanks to everyone who is testing it and leaving feedback!

Try it here and let me know what you think!

Level Format

I managed to remove all xml formats and convert them to json and build the editor in game. This means I can actually edit levels while playing them. It was totally worth the effort. I converted the xml because json is so much simpler and lightweight.

If anyone is interested this is how the level format looks:

{
	"name": "Algorithmic",
	"uid": "r2_algorithmic",
	"mapPos": [0, 0],
	"mapSize": [12, 12],
	"numberOfLives": 10,
	"seed": 5,
	"energy": 120,
	"easyWaves": 10,
	"mediumWaves": 20,
	"hardWaves": 30,
	"waveInterval": {"init": 7, "add": -0.2, "min":3},
	"level": {"init":1, "add": 0.4, "mul": 1.05},
	"waveSizeDef": {"init":5, "add":0.5},
	"waitDef": false,
	"waves":
	[
		{"queue": ["Xor"]},
		{"queue": ["XorSpeed"]},
		{"queue": ["Xor", "XorSpeed"]},
		{
			"wait": true,
			"size": {"init": 1, "add": 0.2},
			"queue": ["XorBoss"]
		}
	],
	"allowedTowers": ["bullet", "slow"],
	"tilesData": "sssssssssssssssspppsssssssssppppssssssspptppsssssssppttppsssssppprpppssssspptrrtppssspptppptppssspprpppprppsppttpppttppspptptpptptpprrpprrrpprpp",
	"overlayData": "00000000000000000x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b00000000000000000000000000000e"
}

On top of this I added an tree based EditView that allows me to edit instantiated level object on the fly. This was boring to do since it involved so much UI program (which I really dislike). On the right in the image below you can see the palette, all the different tiles and overlays (bases, entrances and exits). I think now it’s gonna be fun to create levels.

I will include the level editor when it is usable for and has less bugs.

New level & laser towers

So I built a level in my new editor and added a new tower type: Laser Towers. Those shoots beams through one or more enemies giving mass damage. Place it carefully to hit as many as possible.

Now go and play the new level here! Remember to leave feedback on what sucks and needs to be improved (and what you like).

Feedback is appreciated

This is a first test in order to get some feedback on controls and game play and the general feel of the game. Please comment if you try it out.

Toplist and ads

I also added a top list to make it a little bit more fun. At first I designed an own high score system (on paper) then, in order to save time, I decided to use an already made API. After some hours of reading I wasn’t any wiser on what system to use so I decided just to pick one that looked decent (sometimes it’s more efficient to just try stuff in practice than trying to figure them out in theory). I ended up with mochi media. I wanted to turn off the ads, at least during development but it seems that I had no such option.

As I final note my record has already been broken, a player “fghj” managed to stay alive for 33 waves vs my 27.

PLAY IY HERE

I found this puzzle a lot of fun and decided to create a dedicated game. The objective is to move over all tiles without getting trapped. Select a starting point then choose a direction in which the tiles will be lit all the way until a wall is hit, then select a new direction. You can’t move through yourself so you need to make sure you don’t get trapped.

Last weekend was extra long and that was the time span I sat out to do this within.

Initial development

I started by created a level format, I kept it simple and used a char matrix to describe the board. Then I implemented a simple view on this that drew rectangles in different colors. And on top of this I added the ability to move over tiles. This was all straight forward and playable within a couple of hours.

Level Generation

Once I could actually play some test levels I went ahead and wrote a level generator. This was also pretty straight forward and very brute force. The only thing I had to put some effort in was the difficulty calculations so the levels could be categories into easy, medium and hard. I ended up using the number of choices needed to solve a puzzle going the easiest way (fewest moves). Another thing that I had to do was to remember to throw away duplicates, to do this I mirrored and rotated each solvable to make sure every level was unique. Totally more than 300 levels are used for the game. All in all I probably spent 10 hours on this.

Adding some nice graphics

Once this was done, the boring programming was left. Building some kind of menu, making games save, showing dialogs upon level completion or failure. This took the rest of the time. Anna did some cool buttons and tiles for the game to make it look better. This probably took 20 hours. All the fiddling with mouse overs etc. Phew.

Name: Touch All Puzzle

For now the game is available for free in the Android market. The name is “Touch All Puzzle”. I’m not very happy with the name, but it will do. I will make an IOS and flash version as well.

Whats next

Also I would like to experiment with monetizing it as well. This is something I am really bad at. I’ve written free software for 15 years now but starting to feel that some money would be nice.

I though I would write up how I did this, much for my own sake (haven’t fiddled with this in a long time) and as they say repetition is the mother of all knowledge. You can skip to the bottom part to get the code directly. Also sorry for not using a proper font for math symbols. At least I tried to be consistant, * is the dot product and for scalar multiplication I didn’t use the mul sign (e.g. st).

These are the variables:
v = enemy velocity
p = enemy position in relation to tower (enemyPos-towerPos)
s = bullet speed
t = the time of impact (unknown – what we want to find out)

Now assuming that the enemy will continue in its path we can calculate where to shoot to get a hit.

The first equation we set up is:
|p+vt| = st

This happens when the distance from the tower to the bullet and enemy is the same. You can think of p+vt as a point along a line, starting at the enemy pos (p) and extending in the direction of its velocity (v) as the time (t) grows. The |p+vt| simply means the distance (from the tower) of a point on the line at a given time. st is the distance the bullet have traveled after t time units (remember distance = time * speed).

What we want to do is to find out the time (t) when they are at equal distances. To solve it we need to rearrange the expression a bit. Remember that |v| = sqrt(v*v) (* = dot product), in order to “free” t from its walls |p + v * t| we start by squaring both sides:

|p+vt|^2 = s^2t^2

Freeing t out of the distance operator (|):
|p+vt|^2 = sqrt((p+vt)*(p+vt))^2 =
(p+vt)*(p+vt) =
p*p + 2p*vt + v*vt^2 = s^2*t^2

Now we set it up as a quadratic equation just as we learnt in school.

v*vt^2 – s^2t^2 + 2p*vt + p*p = 0

(v*v – s^2)t^2 + 2p*vt + p*p = 0 (This is the quadratic form ax^2 + bx + c = 0).

Now we only have to solve it, so we plug it into the olden equation:

t1 = (-b + sqrt(d)) / 2a
t2 = (-b – sqrt(d)) / 2a

where d=b^2-4ac

There are two possible solutions to quadratic equations. The factor inside the sqrt is called the discriminant, d, and reveals information about the solutions, a positive d means we have two real solutions, if d is zero there is only one solution and if it’s below zero we have complex solutions this means that we don’t have anyway of hitting the enemy (enemy moving away faster than bullet).

a = v*v – s^2

b = 2*p*v

c = p * p

This is basically what I implemented, than after I got the solutions I returned the lowest positive t via some ugly if statements. I wasn’t really happy with this so I kept looking around and ran into  slembcke’s post ‘leading target‘, in addition to illustrating the equations nicely with graphs he points out that we can use the alternate quadratic formula if we only are interested in the first possible time of impact (works when there is a positive solution).

t = 2c / (-b+sqrt(d))

After unittesting this bad boy I felt pretty comfortable that it was what I was looking for, even though I haven’t proved it for myself. One thing to keep in mind is that this will return 2c/0 (division by zero) if  sqrt(d)=b, this happens when the enemy is moving away at the exact  speed as the bullet, in one of the towers axis (the bullet can’t catch up nor fall behind). I solved this by checking if the t == Infinity, if so I handle it just as if there are no solutions (negative t).

Another small improvement that  James McNeill pointed out is that you can cancel the 2 factor in b. As for this aiming problem we get 2*p*v for our b factor, squaring this in d (b*b) , gives us sqrt(4(pv)^2 – 4ac) => 2 * sqrt((pv)^2 – ac) so now we can cancel the 2 in the top 2c.

The equation we end up with is:

a = v*v – s^2

b = p*v (removed the 2 factor)

c = p * p

d = b*b – ac (removed the 4 factor)

t = c / (sqrt(d) – b)

Here is AS3 source code to calculate how to aim on a moving target:

private function _getToi(targetDir:Vec2Const, targetVel:Vec2Const, bulletSpeed:Number):Number
{
	const a:Number = targetVel.lengthSqr() - bulletSpeed * bulletSpeed;
	const b:Number = targetDir.dot(targetVel);
	const c:Number = targetDir.lengthSqr();
	const d:Number = b * b - a * c;
	if (d <= 0) return -1;
	return c / (Math.sqrt(d) - b);
}

Once you have the time of impact, you check if it’s negative or infinity – if so there is no firing solution. Otherwise you can easily calculate the aim position or direction by interpolating from the enemy position in by it’s velocity scaled by the time:

public function getAimPos(shooterPos:Vec2Const, targetPos:Vec2Const, targetVel:Vec2Const, bulletSpeed:Number):Vec2
{
	const targetDir:Vec2Const = targetPos.sub(shooterPos);
	const toi:Number = _getToi(targetDir, targetVel, bulletSpeed);
	if (toi == -1 || toi == Infinity) return null;
	return targetPos.add(targetVel.scale(toi));
}

As a final note, I assumed that the shooters (towers) are standing still, you can easily modify this by adding a shooterVelocity and pass the relative velocity to the _getToi method.

Some time ago I ported a c implementation of a Naiver-Stokes fluid simulation to AS3 and I thought I should share it. It’s all based on this paper ‘Real Time Fluid Dynamics for Games‘ from by Joe Stam. If you want to understand the details about this I suggest you read it, or look around on the web. But the concept is to  set up a velocity and density field to which you add external velocities and densities. For each update you solve the velocities by iterating over the grid and then move the densities accordingly.

On top of that I added some balls that you can play around with by moving a ball with the mouse, it’s visually not very impressive but it should give an idea of what you can do with it.

It seems like the flash bottleneck is the memory access (all the _v[index] etc), I think using Alchemy for memory access would speed it up a lot, and you could probably do really cool simulations. If you decide to try it, let me know how it works!

Use the method ‘getDensities’ for rendering (just iterate it and plot it). Here is the AS3 code for the fluid solver:

package com.playchilla.algorithm.fluid
{
	public class FluidSolver
	{
		public function FluidSolver(
			width:int,
			height:int,
			solveIterations:int,
			diffusion:Number,
			viscosity:Number)
		{
			_width = width;
			_height = height;
			_solveIterations = solveIterations;
			_diff = diffusion;
			_visc = viscosity;

			_n2 = _width * _height;
			_size = (_width + 2) * (_height + 2);
			_d = _createArr();
			_d0 = _createArr();
			_u = _createArr();
			_v = _createArr();
			_u0 = _createArr();
			_v0 = _createArr();

			_rowAdder = _width + 2;
		}

		public function update(dt:Number):void
		{
			// Add sources from previous to current (last += new)
			_addSource(_u, _u0, dt);
			_addSource(_v, _v0, dt);

			// Diffuse new with old
			_diffuse(1, _u0, _u, _visc, dt);
			_diffuse(2, _v0, _v, _visc, dt);

			// Project velocities onto new velocities
			_project(_u0, _v0, _u, _v);

			// enforce new velocities to uv
			_advect(1, _u, _u0, _u0, _v0, dt);
			_advect(2, _v, _v0, _u0, _v0, dt);

			_project(_u, _v, _u0, _v0);

			// Density step
			_addSource(_d, _d0, dt);
			_diffuse(0, _d0, _d, _diff, dt);
			_advect(0, _d, _d0, _u, _v, dt);

			for (var i:int = 0; i < _size ; i++)
				_d0[i] = _u0[i] = _v0[i] = 0;
		}

		public function getDensities():Vector.<Number> { return _d; }
		public function addDensity(x:int, y:int, amount:Number):void { _d0[_index(x,y)] += amount; }
		public function addVelocity(x:int, y:int, velocityX:Number, velocityY:Number):void
		{
			const index:int = _index(x, y);
			_u0[index] += velocityX;
			_v0[index] += velocityY;
		}
		public function setVelocity(x:int, y:int, velocityX:Number, velocityY:Number):void
		{
			const index:int = _index(x, y);
			_u0[index] = velocityX;
			_v0[index] = velocityY;
		}

		public function getWidth():Number { return _width; }
		public function getHeight():Number { return _height; }

		private function _addSource(x:Vector.<Number>, s:Vector.<Number>, dt:Number):void
		{
			for (var i:int = 0; i < _size; ++i)
				x[i] += dt * s[i];
		}

		private function _diffuse(b:int, x:Vector.<Number>, x0:Vector.<Number>, diff:Number, dt:Number):void
		{
			const a:Number = dt * diff * _n2;
			_linearlySolve(x, x0, a, b, 1 + 4 * a);
		}

		private function _linearlySolve(x:Vector.<Number>, x0:Vector.<Number>, a:Number, b:Number, c:Number):void
		{
			for (var k:int = 0; k < _solveIterations; ++k)
			{
				for (var j:int = 1; j <= _height; ++j)
				{
					var current:int = j * _rowAdder;
					for (var i:int = 1 ; i <= _width; ++i)
					{
						++current;
						x[current] =
							(x0[current] +
							a *
							(x[current-1] +
							 x[current+1] +
							 x[current-_rowAdder] +
							 x[current+_rowAdder])) / c;
					}
				}

				_setBnd(b, x);
			}
		}

		private function _advect(b:Number, d:Vector.<Number>, d0:Vector.<Number>, u:Vector.<Number>, v:Vector.<Number>, dt:Number):void
		{
			const dt0:Number = dt * _width; // FIX
			for (var j:int = 1; j <= _height; ++j)
			{
				const current:int = j * _rowAdder;
				for (var i:int = 1 ; i <= _width; ++i)
				{
					++current;
					const x:Number = Math.min(Math.max(i - dt0 * u[current], 0.5), _width + 0.5);
					const y:Number = Math.min(Math.max(j - dt0 * v[current], 0.5), _height + 0.5);

					const i0:int = int(x);
					const i1:int = i0 + 1;
					const j0:int = int(y);
					const j1:int = j0+1;

					const s1:Number = x - i0;
					const s0:Number = 1 - s1;
					const t1:Number = y - j0;
					const t0:Number = 1 - t1;

					d[current] = s0 *
						(t0 * d0[_index(i0, j0)] +
						 t1 * d0[_index(i0, j1)]) + s1 *
						(t0 * d0[_index(i1, j0)] +
						 t1 * d0[_index(i1, j1)]);
				}
			}
			_setBnd(b, d);
		}

		private function _project(u:Vector.<Number>, v:Vector.<Number>, p:Vector.<Number>, div:Vector.<Number>):void
		{
			for (var j:int = 1; j <= _height; ++j)
			{
				var current:int = j * _rowAdder;
				for (var i:int = 1; i <= _width; ++i)
				{
					++current;
					div[current] = -0.5 *
						(u[current+1] -
						u[current-1] +
						v[current+_rowAdder] -
						v[current-_rowAdder]) / _width; // FIX /_N

					p[current] = 0;
				}
			}

			_setBnd(0, div);
			_setBnd(0, p);
			_linearlySolve(p, div, 1, 0, 4);

			for (j = 1; j <= _height; ++j)
			{
				current = j * _rowAdder;
				for (i = 1 ; i <= _width; ++i)
				{
					++current;
					u[current] -= 0.5 * _width * (p[current+1] - p[current-1]);
					v[current] -= 0.5 * _height * (p[current+_rowAdder] - p[current-_rowAdder]);
				}
			}

			_setBnd(1, u);
			_setBnd(2, v);
		}

		private function _setBnd(b:int, x:Vector.<Number>):void
		{
			for (var i:int = 1; i <= _height; ++i)
			{
				x[_index(0, i)] = b==1 ? -x[_index(1, i)] : x[_index(1, i)];
				x[_index(_width+1, i)] = b==1 ? -x[_index(_width, i)] : x[_index(_width, i)];
			}

			for (i = 0; i <= _width; ++i)
			{
				x[_index(i, 0)] = b == 2 ? -x[_index(i, 1)] : x[_index(i, 1)];
				x[_index(i,_height + 1)] = b == 2 ? -x[_index(i, _height)] : x[_index(i, _height)];
			}

			x[_index(0, 0)] = 0.5 * (x[_index(1,0  )]+x[_index(0  ,1)]);
			x[_index(0, _height + 1)] = 0.5 * (x[_index(1, _height + 1)] + x[_index(0 , _height)]);
			x[_index(_width + 1, 0)] = 0.5 * (x[_index(_width, 0)] + x[_index(_width + 1, 1)]);
			x[_index(_width + 1, _height + 1)] = 0.5 * (x[_index(_width, _height + 1)] + x[_index(_width+1, _height)]);
		}

		private function _index(x:int, y:int):int {	return x + y * _rowAdder; }

		private function _createArr():Vector.<Number>
		{
			const arr:Vector.<Number> = new Vector.<Number>(_size, true);
			for (var i:int = 0; i < _size; ++i)
				arr[i] = 0;
			return arr;
		}

		private var _solveIterations:int;
		private var _diff:Number;
		private var _visc:Number;
		private var _width:int;
		private var _height:int;

		private var _n2:int;
		private var _size:int;
		private var _rowAdder:int;

		private var _d:Vector.<Number>; // dens
		private var _d0:Vector.<Number>; // prev dens
		private var _u:Vector.<Number>; // vel x
		private var _u0:Vector.<Number>;
		private var _v:Vector.<Number>; // vel y
		private var _v0:Vector.<Number>;
	}
}

Merry Christmas!

I want to create a sandbox Tower Defense game instead of a linear. Here are two key features I am adding:

1) Physics. Shoot creeps with big canons and knock them off their path, even make them fall of the map.

2) Behaviors. Creeps can posses different behaviors. So far I’ve implemented a behavior to avoid incoming artillery fire, this looks really cool – shooting into a group scatters it as they are fleeing all over. Another behavior is to avoid towers by taking advantage of a weighted graph they can find their way to the goal exposing themselves to as little danger as possible. More to come.

Also I created a little level editor in which I can draw maps using a hexagonal layout. I will not spend so much time on graphics instead focus on the game play. Your objective is to protect your “souls” which the creeps try to steal. I’ve a story line for this in the back of  my head as well, but that’s for the future.

Here is a first screenshot to show you the progress. This level has allows 2 types of towers, a normal canon and a slow tower, creeps enter at the bottom right and exits in the top. I’ve built a windy path for them to follow.

There are many good things that have come out of this side project, I have a pretty robust testbed for AI, goal selection, astar, physics integration etc.

TRY IT HERE

This is all crude, and the graphical theme will probably be refined. I’ve set a kind of dark setting, perhaps on an occupied space ship. I will probably add some little background story to it at some point to make it more interesting.

Well try it and let me know what you think can improve. Any info on levels that are too hard or easy is important.

TRY IT HERE

But fear not, progress has been done. I decided to create a teaser video, this took me two evenings and was a lot of fun. While looking for music on different free sound sites I found Buba Producer on SoundCloud. This guy creates really high quality scores and shares them freely for attribution. I think that is really cool. The only “bad” thing is that the music quality is so much higher than my video.

I also had some trouble with the compression – some walls were removed when uploading to youtube. I don’t want to spend to much time on polishing the video so I will just leave it like that, and improve if I make another one in the future.

Physics

Another problem I ran into was level creation, I noticed that I needed a new game play element in order not to repeat myself. I decided to add balls that the player can push and hide in it’s shadow projection. Now creating levels was easy again.

Pushing the ball to get to the key unseen.

Another idea I’ve is to shape up the level editor and let you guys create levels and put them into the game? This will probably mean more variation.

Play it

Use ARROWS to move. Use MOUSE to throw pebbles. Use ‘R’ to restart level. Be quiet. Stay in the darkness.

You will always find the latest version under the shadowess project page.

I won’t tell you more about my ideas now. The ‘Shadowess’ page will always contain the latest version of the game (I’ll not post it in individual blog posts any longer).

CHECK IT OUT

Update:
- Random directions
- Random turn speeds
- Minor control tweak
- More levels
- A new pickup (pebbles)

Use the MOUSE for the last pickup, use ARROWS to control the bot, press ‘R’ to restart a level.

What I probably should fix:
- Bots must be able to chase player off the path grap (now the just look crazy)
- Fix different hearing distances
- Make the investigate goal less “dumb” (now everyone just runs the shortest path to the sound source)
- Perhaps add some memory to the bots (as soon as player is out of sight the just forget him)

Generating a random direction, three different algorithms

When I was going to implement this I noticed that I didn’t have any central code to create a vector in a random direction. This is something I use frequently so I decided to do a proper implementation.

Randomizing a direction can be done in many ways, but be aware: some intuitive approaches are simply wrong and doesn’t provide a uniform distribution.

Wrong: normalizing random points in a square

The first time I was doing this, I didn’t realize this until a code review. The reviewer asked me if I was aware that my code generated biased directions. It all seemed random in my testing, I replied. I guess my first draft of the code looked a bit like this:

private function createRandomDirBad():Vec2
{
	const u:Number = 2 * Math.random() - 1;
	const v:Number = 2 * Math.random() - 1;
	const l:Number = Math.sqrt(u * u + v * v);
	return new Vec2(u / l, v / l);
}

Can you see why this is skewed? This generates a random point in a square which is normalized to have length one – this means that diagonal directions will be biased because points outside the circle are “pushed” inside. The image below illustrates this bias. (Points are drawn in the circle rather than on the outline to demonstrate this)

Discarding points outside of the circle

I was quickly convinced and changed my code. I fixed it by discarding all randomly generated points outside of the circle (x*x + y*y > 1). This requires more iterations but gives an uniform distribution of points within a circle. See distribution B below.

private function createRandomDirSquare():Vec2
{
	var p:Vec2;
	while (true)
	{
		const u:Number = 2 * Math.random() - 1;
		const v:Number = 2 * Math.random() - 1;
		const s:Number = u * u + v * v;
		if (s > 1 || s < Vec2Const.EpsilonSqr) continue;
		const l:Number = Math.sqrt(s);
		p = new Vec2(u / l, v / l);
		break;
	}
	return p;
}

Here is the distribution within the circle (on the circle surface it's uniform - but not over the area):

Using trigonometry

Another method for random generation of points in a circle is to use trigonometric functions. This perhaps the most straightforward way, we just grab a random angle and create a vector in that direction:

private function createRandomDirTrigonometry():Vec2
{
	const rads:Number = Math.random() * Math.PI * 2;
	return new Vec2(Math.cos(rads), Math.sin(rads));
}

This will put points uniformly along a circle outline.

No square roots, no trigonometry

While looking around, I found a method attributed to Von Neumann. This trick allows us to generate a random direction without any use of square roots or trigonometry which can be useful if those are slow.

public static function createRandomDirKnuth():Vec2
{
	var p:Vec2;
	while (true)
	{
		const u:Number = 2 * Math.random() - 1;
		const v:Number = 2 * Math.random() - 1;
		const l:Number = u * u + v * v;
		if (l > 1 || l < EpsilonSqr) continue;
		p = new Vec2((u * u - v * v) / l, 2 * u * v / l);
		break;
	}
	return p;
}

Final note on performance

The difference from the three methods is very small, today sin and cos are mostly hardware accelerated and as it turns out in my measurements this is the fastest way to do this. So perhaps I would recommend using the one with sin and cos, if not for its performance for its simplicity.

This prototype only consists of 7 small levels (once you completed the last you will spawn on the first again). It has no fancy stuff, just some basic game logic and some sounds and some scary bots.

Use ARROWS, press ‘R’ to restart the current level you are on! Be quiet. Stay in the darkness.

It would be interesting the hear what you think? Could this eventually be a fun game?

What I need is a frustum, or flashlight type of light source. Before, I had solved this by first drawing a full circle onto which I drew masking triangles, carving out the frustum pie. This mask was very expensive to draw (imagine a small frustum, then the mask would be huge in order to cover the non-pie circle parts).

Drawing the light

My new approach is far from optimal, but way better. Instead of carving out the view cone, I only draw the cone as the light once, then I apply shadows to this. In order to draw this pie I used line segments, so pie end is not circular, but made up of n line segments covering the light radius. See the jacked arc in image below (outlines by the red line).

Here is the core of drawing the pie:

const rd:int = left.crossDet(right) > 0 ? -1 : 1;
const rotDir:int = (lightBody.getFovDeg() > 180) ? -1 * rd : rd;
const spinor:Vec2Const = new Vec2(1, 0).rotateSelf(Conv.deg2rad(15) * rotDir);
const parts:int = lightBody.getFovDeg() / 15;

const g:Graphics = _lightData.graphics;
g.beginGradientFill(GradientType.RADIAL, [0xffffff, 0x000000], [0.3, 0], [0, 255], matrix);
g.moveTo(0, 0);
g.lineTo(right.x, right.y);
_tmp.copy(right);
while (parts-- > 0)
{
	_tmp.rotateSpinorSelf(spinor);
	g.lineTo(_tmp.x, _tmp.y);
}
g.lineTo(left.x, left.y);
g.lineTo(0, 0);
g.endFill();

In short, the vector left is the left frustum “tentacle” and right the other. The arc is drawn in the while loop. The next segment in the arc is calculated by simply rotating the right vector one step at a time, until we have covered the pie all the way to the left vector (parts times of segments). The nifty thing with spinors is that you don’t have to leave vector space for rotations. The spinor is only created once, in this case with 15 degrees, then each time it’s applied to a vector the vector is rotated by 15 degrees. So instead of fiddling with sin and cos you can just apply it by multiplication. This is more efficient and clean. If you are interested you can find the rotateSpinor methods in my vector 2d class.

Drawing the shadows

Once the light is in place it’s time to apply the shadows over it. This is done by projecting rays through each “extreme” wall vertex as far as the light source can reach. An extreme vertex is one that is the  “right or left”-most point with respect to the light source. Then it’s just to draw the shadow between each such ray pair and close it up with the same arc as drawn for the light pie above.

Here are the shadows, outlined with yellow lines:

Here is the algorithm outline:
1. For each obstacle within the frustum view
2. – Find the two extreme points (if we are only looking at Axis Aligned Bounding Boxes the simplest way is probably to check in which octant the light source is.)
3. – Draw a line between those two extreme points
4. – Draw lines from the extremes in the direction of the light passing through until it hits the frustum end.
5. – Connect the end points from (4) by drawing an arc (same way as described under “Drawing the light”).
6. – Fill this area with a shadowy color

Once this has been accomplished, I set the blendMode of the sprite to ADD – in this way two light sources interacts in a decent manner. The problem with setting the blendMode is that it’s very slow.

The result

You can run around with a 360 deg light bulb on your head. Don’t worry about the other bots as you have cleverly disguised yourself as one of them for this experiment. (Use ARROWS)

Possible improvements

The biggest performance hit with this method is due to the blendMode. A solution would probably be to only draw the light (absense of light = shadow) This can be achieved by scanning each vertex in one direction creating a light area while moving along. Imagine standing in front of a couple of walls at different distances – then taking a laser gun that has a burning continuous beam, and while holding the trigger turning. This will leave a burnt lines along the walls and everything it hits – if there are no walls the beam will hit an imaginary frustum back wall. Once you are done with turning you can look at this area, outlined by the burnt lines (and start & stop dir) from above and fill this area with light – and you are done.

With this approach you aren’t drawing any shadows (e.g. black) so interactions with other lightsources in shadows will work (instead of overdrawing a light with a shadow) without having to use a blendMode. You probably have to tweak the alpha values to get this to look decent (perhaps it’s hard to to get it as nice as with blendMode.ADD?).

Well perhaps there is a simpler way of doing this but this is the first I came to think of?

As you may notice bots bump into each other, this is because there is no dynamic avoidance. I’m not sure if this will be a problem or not for this experiment. If it turns out to be a problem, I will either disable collision between bots or add some dynamic avoidance (probably potential fields, since that is something I have worked with before).

Use arrows, tag bots without them seeing you, you can also use the mouse to move around again.

To make it a bit easier for the player, I will probably add some weapon pickups, maybe even the bots will be able to grab this pickup. This should naturally make me incorporate some aim prediction which will be fun to revisit.

My former implementation only allowed tests against rectangles – when shooting a ray this might be very inefficient. For example, consider a diagonal ray going from x,y (0,0) to (100,100) in world coordinates. This world is represented in a spatial hash with, say, cell size 10. This means that the Spatial Hash would return all objects from the 100 cells that are overlapped by the rectangle set up by the ray. If we instead could only return the cells that the ray touches on its way from (0,0) to (100,100) we would reduce the number of potential objects a lot. Once we have obtained this subset we can do the narrow phase testing (fine grained ray tracing).

DDA

Now walking along a line from point A to B can be done in many ways, the most common is perhaps Bresenhams line algorithm. The problem with this approach is that it can make diagonal jumps and hence miss cells that the line actually pass over. This is where the DDA, or Digital Differential Analyzer yada yada, comes into the picture. I don’t know why anybody would name it such. Perhaps it’s just me that don’t get it. Bresenham seems like a decent guy, “hey I have a line algorithm, lets name it after myself and with the word line to it.”

Anyway, as opposed to Bresenhams line algorithm, DDA will touch all cells the line is moving over. So if you move from (0,0) to (1,1) it will not make a direct jump to (1,1) but first go via (1,0) or (0,1). This is exactly what we need to make sure we capture all cells along a rays direction.

A visual demo

Click somewhere in the flash to mark the start position of the line, then click again to mark the end pos. The grid is the cells in the spatial hash and the objects are random hash values. Objects that are returned by the raycast are highlighten.

Code

Here is the code! Sorry about the copying pasting trouble here, I might set up a code repository to make all this easier.

DDA.as

package com.playchilla.algorithm.spatial
{
	/**
	 * DDA line algorithm.
	 *
	 * @author playchilla.com
	 */
	public class DDA
	{
		public function DDA(cellSizeX:Number, cellSizeY:Number)
		{
			_cellSizeX = cellSizeX;
			_cellSizeY = cellSizeY;
		}

		public function run(x1:Number, y1:Number, x2:Number, y2:Number, traverseCallback:IDDACallback):void
		{
			var gridPosX:int = int(x1 / _cellSizeX);
			var gridPosY:int = int(y1 / _cellSizeY);
			if (!traverseCallback.onTraverse(gridPosX, gridPosY))
				return;

			var dirX:Number = x2 - x1;
			var dirY:Number = y2 - y1;
			const distSqr:Number = dirX * dirX + dirY * dirY;
			if (distSqr < 0.00000001)
				return;

			const nf:Number = 1 / Math.sqrt(distSqr);
			dirX *= nf;
			dirY *= nf;

			const deltaX:Number = _cellSizeX / Math.abs(dirX);
			const deltaY:Number = _cellSizeY / Math.abs(dirY);

			var maxX:Number = gridPosX * _cellSizeX - x1;
			var maxY:Number = gridPosY * _cellSizeY - y1;
			if (dirX >= 0) maxX += _cellSizeX;
			if (dirY >= 0) maxY += _cellSizeY;
			maxX /= dirX;
			maxY /= dirY;

			const stepX:int = dirX < 0 ? -1 : 1;
			const stepY:int = dirY < 0 ? -1 : 1;
			const gridGoalX:int = int(x2 / _cellSizeX);
			const gridGoalY:int = int(y2 / _cellSizeY);
			while(gridPosX != gridGoalX || gridPosY != gridGoalY)
			{
				if (maxX < maxY)
				{
					maxX += deltaX;
					gridPosX += stepX;
				}
				else
				{
					maxY += deltaY;
					gridPosY += stepY;
				}

				if (!traverseCallback.onTraverse(gridPosX, gridPosY))
					return;
			}
		}

		private var _cellSizeX:Number;
		private var _cellSizeY:Number;
	}
}

IDDACallback.as

package com.playchilla.algorithm.spatial
{
	/**
	 * ...
	 * @author playchilla.com
	 */
	public interface IDDACallback
	{
		/**
		 * Return false to cancel traversal.
		 */
		function onTraverse(cx:int, cy:int):Boolean;
	}
}

Paste into SpatialHash.as
Also:
- Make the SpatialHash implement IDDACallback
- put this in the constructor “_dda = new DDA(cellSize, cellSize);”
- put this at the bottom “private var _dda:DDA;”
- put this at the bottom “private var _rayCastResult:Vector.;”

Perhaps time to open up an account on google code or similar?

public function rayCast(startPos:Vec2Const, stopPos:Vec2Const):Vector.<SpatialHashValue>
{
	_rayCastResult = new Vector.<SpatialHashValue>;
	_dda.run(startPos.x, startPos.y, stopPos.x, stopPos.y, this);
	++_timeStamp;
	return _rayCastResult;
}

public function onTraverse(cx:int, cy:int):Boolean
{
	const bucket:Vector.<SpatialHashValue> = _hash[_getKey(cx, cy)];
	if (bucket == null)	return true;
	for each (var b:SpatialHashValue in bucket)
	{
		if (b.timeStamp >= _timeStamp) continue;
		b.timeStamp = _timeStamp;
		_rayCastResult.push(b);
	}
	return true;
}

Credits
When I first wrote the DDA code perhaps 2 years ago I remember reading a pdf that explained it and had some c/c++ code. I can’t find this article anymore, however, thank you mysterious author. Also thanks to Maurycy Zarzycki for inspiring me to finally get around to do this.

In the example below I added four goals
1) LookAround – the head of the bot looking in random directions (visualized with the flashlight)
2) RandomWalk – the bot picks a random spot in the sandbox and move there.
3) Investigate – if the player accidentally bumps into a wall within a limited distance from the bot, the bot will hear this and the investigate goal will kick in to find out whats going on.
4) Chase – if the player is in the seeing frustum (flashlight) the bot will start to chase the player

I am trying to set up a simple model that allow the bot to run multiple goals at the same time. So for example the RandomWalk goal can run at the same time as the LookAround goal. This is managed by booking resources on the bot. E.g. LookAround only utilized the head, while the RandomWalk utilized its wheels – therefore they can run simultaneously. So basically all goals that can run at the same time are selected from a prioritized queue.

Tag-a-bot

To add some flavor I made a little tag game, try tagging the bot without him seeing you, sneaking up from behind, for each successful tag a new level is generated the bot will get more vision and speed. However if the bot catches you in the flashlight the game will fall back one “level”. (USE ARROWS)

Again, possible future articles:
- Goal selection
- Controlling a bot with physics (forces)
- 2D shadow casting

Not sure what to do next, perhaps drop down multiple bots and to play along in the sandbox. This usually involves making sure they don’t want to go to the same spot all the time, or collide into each other and instead not getting anywhere. Not sure if this is needed for the plan, a reactive tower defense game, but for a little shooter or so it would be cool.