Clicking the video above (or HERE) will take you to the game. Source code is available here.

Why make a Doom clone?

Why create a FPS in JavaScript in a total of 13k (compressed)? There are a few reasons. But probably the best answer is that the JS13K contest FAQ answers the question “Can I use WebGL?” with “Yes, though it might be hard to fit it into 13 kilobytes if you plan on doing an FPS game.”

But aside from that fact, I had just made a 3D renderer and wanted to keep working on it more. Also, writing heavily compressed code is something I enjoy doing, (For example, many years ago I created a language and wrote a compiler for a new language designed specifically for use in code golf.)

So that's why an FPS. What about the question “why doom?” The answer here is easier. If you're going to write an FPS, and want to keep it small, doom is about as minimalistic as you can get.

The reason doom is so simple (by today's standards) is clear: doom had to run on hardware five orders of magnitude slower than what we have today. For the same price today, it's entirely possible to build a machine that can do a hundred thousand times the work of the Pentium of 1994. And so, I thought it would be fun to try and re-create something like doom but instead of handling performance constraints, handling space constraints.

Starting Point: A 3D renderer in JavaScript

I based the game engine on a 3D renderer I had been working on previously with the intention of being as simple as possible. It turns out by being simple, it's also quite small: the core 3D rendering engine only came out to about 5KB of compressed JavaScript, so that left 8KB for the game itself. I figured this wasn't that bad of a state to be in, after all. As long as I didn't use any large game sprites or object files it should work out.

Player Movement

Going from a 3D renderer to 3D game engine basically just requires one change: player-controlable camera movement followed by re-rendering after every movement. To do this, I put the player on the inside of a box and worked for a while making movement feel right. Doom has a very distinctive style of movement that I tried to recreate.

The first step towards this is making the player accelerate in the direction they're facing up to some (fast) maximum speed. I had more acceleration than the original doom because that seemed more normal now. Most importantly to make things feel doom-like is adding the camera bobbing as the player moves. In the steady state this is just a sin wave, but there are some necessary details to make it feel right when going from stopped to moving.

If you don't do anything additional, then the player will resume the bobbing from wherever they were when they stopped. This looks very wrong. Fixing it is actually just some very small tweaks: The player maintains a variable of where the animation is in its cycle (modulo two pi), and when the player stops moving in any direction, the variable resets itself to zero. This really cleans up the motion and makes starting and stopping feel right.

One feature I added that doom didn't have was I added a small amount of camera roll on every step. (Doom doesn't have this because it only allowed rotation along the z-axis, the player couldn't even look up.)

From there I added clipping. There's no reason to create complicated doom-esque mazes if the palyer can walk through walls. Now, the “correct” way to handle clipping is to make the player is a sphere, the walls plans, and then detect sphere-plane intersections. I was worried this would take too much space for a 13k budget.

Instead, the game extends eight rays out of the current player's position, and detects if any of those rays intersect with a wall. If any does, then I back the player up so that it's at least five units away from the that wall. This has the effect of being a poor-mans sphere collision detection while also coming in at just a hundred bytes.

Getting this right was somewhat finicky, especially when the rays intersect with multiple walls simultaneously. It's still broken in a few situations, so when designing the levels I manually tested for glitches and just designed the levels around the collision detection bugs. (Hey, if it works...)

Object Lathing

In order to have any objects in the game, I was going to need to represent them somehow. One natural method would be to use the .obj file format. Unfortunately, this is quite large and cumbersome. (This is what I did for my prior 3D remderer to load the mandatory teapot.)

Instead, I decided to write a minimalistic object lathe method: given a 2D path represented as a sequence of points, lathing rotates the points around in a circle to generate a 3D object. This lets you create some very nice objects with only a very small amount of space. For example, the jug pictured above comes in at around twenty bytes of code to represent.

For a long time through the development of the game I also created a heavily-minified 300-byte implementation of surface subdivisioning (that I'd previously used for the 3d renderer). But at the end of the day, I ran out of space and had to cut it---I didn't feel too bad about this, because it really wasn't adding anything to the game.

Game Loop

Up until here everything has been fully static. Only the player camera moves through the world. Making a game, however, requires interactivity. So that's where the game loop comes in.

The game loop here is just the completely standard game loop. Initially it was actually the following code:

While this really is nice and pretty code, each of the functions there was only ever called once. So they all got inlined and the loop got ugly.

Gun & Enemies

A first person shooter isn't much fun without something to shoot with, or shoot at.

I started with the “shooting with” problem. I wasn't sure if there would be enough space for more than one gun (narrator: there wasn't), and for a game designed around shooting, I figured starting with the doom chaingun was the natural choice.

The gun model is just a few cylinders made with the object lathe. Again the first step here was to make moving with the gun feel right. To do this I just re-use the existing tracking for the up-down movement when walking: the gun moves both up-and-down as well as side-to-side, depending on where the player is in the walking cycle.

The next necessary step was making shooting with the gun feel satisfying. That had three components. First, it has a small kick-back every time it shoots. Second, it spins. And finally, there's a small flash every time it shoots. All of these contribute nicely to the feel of the game. For a game that revolves around shooting, it has to.

Hit detection is implemented as a simple ray-cast hitscan (using the same code as the collision detection with walls for player movement) followed by creating some explosion particles and a small light flash.

I had to make a few changes to the ray-cast for hitscanning. First, because the initial implementation just checked horizontal collision, I had to check if the collision was the correct z-height when it arrived. This wasn't too hard: compte how far the object is away from the player, looking at the players pitch determine what the bullet height would be, and if that is within the objects height bounding-box, then it's a collision.

(One other minor detail was necessary to allow shooting the ceiling and floor. Otherwise when aiming too high there would be no explosion effects and it looked all wrong. All other collision detection only detects horizontal collision, but these are vertically-oriented and so needed a bit of special-purpose code. Doing this is actually not too difficult: record the starting z-height and pitch (angle off of the xy plane), and then for every polygon in the entire map, check how far the ray would have to extend to hit the floor and the ceiling of that polygon; then check if stepping that far actually ends up in the polygon at that location.)

After this, I sort all potential collisions and choose the closest one.

Shooting also has some screenshake, and because there is no ammo, slows down player movement. It's important to give the player a reason to not hold down the trigger the entire game.

Then I turned to the “shooting at” problem. I initially created a really basic block-model of a person. It's entirely based on cubes which makes it very easy to store: by saving just a single cube model, I can stretch it in arbitrary directions and get an enemy. The basic enemy then consists of eight boxes.

The death animation started out as something simple and the enemies would just fall over. This didn't look all that bad, but shooting felt weak and boring. So instead, I made a few tweaks so that the enemy would remember each of the constituent cubes that makes it up and then when it gets hit, explode into pieces. This felt much better.

Initially the blocks that made up the enemy would just fly through walls and off the screen. This was somewhat disconcerning, and so I added an effect to make them bounce off walls. The bouncing is completely physically implosible in order to be short. Collision is again implemented with the ray intersection. Then, if the nearest wall is completely on the xz plane, the objects reflects its y velocity. If it is completely on the yz plane, the x velocity is reflected. In all other cases, both the x and y velocities are reflected.

When the object position is lower than the current room's floor height, the z-velocity is negated and decreased by 20%. Every second the object slows down by 50% (as if by some hypotehtical friction).

Enemy AI

For someone whose degree and career is ostensibly in (with lots of quotes) ““AI””, the enemies here are really rather unintenilgent. Enemies have a position and rotation. They pace back and forth forever, until being woken up, either (a) because the player is within line-of-sight, or (b) because an enemy within line-of-sight gets shot.

Detecting line-of-sight is again implemented with the raycast implementation which is re-used from detecting where the gun hit is supposed to be and from collision detection. In order to not burn cpu cycles with even more ray casts, the enemy only checks for enemies once per second.

Once awake, the enemy will move in a straight line directly towards the player. If something gets in the way, the enemy will pick a new random direction and move that way for a few steps, and then return to moving towards the player. Occasionally, the walking enemies will shoot at the player.

Also, whenever an enemy dies, it requests help from all other enemies that it can see (again through a ray cast). This makes it hard to just pick off enemies one by one while hiding behind a corner, which is a boring game mechanic that shouldn't be encouraged.

Textures

Until now everything was very dull being just one texture. I knew there was no way I would fit in any manually-drawn textures---even small ones---so instead I procedurally generated them. I opted to go for just three textures: a tile floor, a brick pattern for walls, and simple Perlin noise for lava and explosions.

---

If you want to be notified the next time I write something (maybe like this, maybe not) enter your email address here.

There's also an RSS Feed if that's more of your thing.