Cottage of Doom, winner of TIGSource’s B-Game Competition, is one part shooter, one part tower defense, and one part survival horror. It is, in other words, totally addictive and awesome.

…

Cottage of Doom’s most interesting mechanic, by far, is the player’s ability to block windows, doors, and entire areas off by moving furniture. Though it sounds like a small thing, there’s literally no other zombie game I can think of (heck, maybe no other game, period) which allows you to dynamically barricade certain parts of a house.

In most zombie games, barricading is a binary thing: you either do it, or you don’t. In Cottage of Doom, barricading is an integral, strategic part of the game. If you don’t keep the right parts of the cottage defended, you’ll get overwhelmed quickly. If you don’t destroy certain barricades ot get ammo from them, you won’t be able to take out the encroaching zombies. If you can’t strategize and find a good balance between blasting the undead and maintaining your barricades and doors, you’ll be screwed.

The barricading system almost makes Cottage of Doom more of a strategy game than an action title. Blasting zombies is fun, of course, but the gunplay never gets any more complicated than “click on this zombie a few times to kill it,” while the barricading gameplay has an incredible amount of depth and nuance. I’m not typically one to enjoy thinking in my zombie games, but Cottage of Doom tricked me into loving every minute of strategic, furniture-moving glory.

Thanks Anthony! Glad you liked it :)

Efficient Development - part one
Efficient Development - part two
Efficient Development - part three
Efficient Development - part four

Enjoy!

I’ve been discussing Dyson with Rudolf, who is the chief designer on this project. The plans we have laid out for the game design actually incorporate many of the ideas that people have fed back after playing the game. Partly it’s because they’re great ideas and we want to give people what they want, and partly it’s because we had already planned to put these elements of the design in.

Among these additions will be a limitation of how far you can expand; more emphasised attribute effects; interface improvements; defensive structures; improved enemy AI; more visual feedback. Hopefully when we’re done, we will have a more rounded and complete game. If you’d like to know more, do feel free to write to Rudolf or me. We really love getting feedback.

I’ve been on a break after the competition deadline, but I couldn’t help messing around with a few bits of code to make the trees look nicer. This is an early prototype of the code:

I teamed up with a good friend of mine and we are quite proud of what we ended up with.

Dyson is a kind of RTS about taking over an asteroid belt. There’s even some procedural content in there that may be useful for Deadrock, so the time taken to write the game was definitely not wasted in Deadrock terms.

Here are a few screenshots:

You can download the game here.

All feedback gratefully received!

The official competition thread is here.

A week ago:

And today:

What you are looking at is a broad plan of the town - these are large lots into which smaller building lots will be placed. The generation process is fairly simple and goes like this: first I generate a population density map, which is a combination of a cloud of points with an area effect and Perlin noise. Next I distribute some road seeds across the map. These grow outward and branch into smaller roads if they don’t collide with another road. I then distribute building lot seeds over that and grow those at different rates until they can’t grow any more.

Next stage is to put some lots inside the lots I have already made, and then move on to building generation, which I reckon is going to be much harder :)

Things I’ve added:
Two-sided walls
All walls may now be two-sided. It’s so that a wall can have a different pattern on each side - since my engine works on a tile system, having one sided walls would mean that any walls that needed a different pattern on each side would need to be one square thick, which would look ridiculous in a realistic context (although it would be fine for a dungeon crawler).

Fully 3D rendering
As you can see, the game is now rendering in full 3D. The player can rotate the camera.

Camera frustum culling
This was a lot easier than I originally thought. I used theory from this paper to write the code.

Camera-relative movement
All controller movement is now relative to the camera, so moving the stick left makes the player go left. The game currently supports only Xbox 360 controllers.

Mouse control
I used to have mouse control but with the 3D mode it stopped working, as I was using my own maths to calculate the world-position of the mouse pointer. I now use the projection matrix to do that, which is pretty easy to do in OpenGL using a function called gluUnProject.

Multi-storey buildings
Much of the recent work has been improving the game engine to run several layers of map at once. It’s more-or-less working now, and even the collision routine is working between layers now.

Next up:

I think next I will go back to some scenery generation. Part of the earlier work was removing the scenery generation from the individual map segments (which are 16×16 tiles), and into their own system of world-building classes, and it’s pretty much ready to go now. So I can start making roads, houses etc. And now that the game actually supports multiple-storey buildings it’ll be possible to make some really interesting stuff like car parks, malls etc.

I also need to implement some kind of bloodstain system, and I’d like to look into doing some lighting so that the game can simulate day and night.

And yeah… also some gameplay I SUPPOSE

Baby steps

The starting point for all this is Jos Stam’s work. A good paper to read is his 2003 paper, Real-Time Fluid Dynamics For Games, which will show you how to create an incompressible single fluid volume, which is useful if you want to show smoke, for instance. This is basically what I used in HCS to simulate the heat flow. A collection of Stam’s published work is held at his page at the University Of Toronto. This is the same stuff that I believe was used in the now-defunct Plasma Pong.

How it works is that you have a field of velocity and a field of density. You then make the density follow the velocity field, and do the same for the velocity. You then conserve mass over the entire system. This paper will give you a few further insights into the method. It was extremely helpful for me to read this paper.

The major setback with this method for the Coder About Town is conserving the mass of the system. This is done, apparently, by using a Hodge decomposition, which apparently states that a velocity field is the sum of a mass-conserving field and a gradient field. Finding the gradient field involves solving a Poisson equation, which is a linear system, which Stam achieves by using something called a Gauss-Siedel relaxation. You may have guessed that I didn’t understand a single concept or process in that last paragraph.

Here is a java implementation of the Stam work with some additional work added for vorticity confinement. This is the version I used for HCS; Java is very close to C# as a language so it was easy to port this. The code in the Stam paper was heavily optimised and hard to get to grips with.

Here is another implementation. Not that much info.

There is an interactive 2D version of a similar solver by Andrew Selle, who has gone on to do some really excellent work at Stanford.

Moving forward

The main problem with the above work is that it deals with a volume containing a single fluid. What you really want for a fluid simulation is at least two fluids, let’s say water and air. There are plenty of solutions for this problem but most of them are not suitable for real-time interaction. One that I did find was a deliberately-compromised version intended for educational purposes. The idea is that you run particles over the fluid simulation and ensure that boundary conditions are correct between cells containing fluids, solid cells and empty cells. Correcting the boundary conditions is left as an exercise for the student. It is not trivial.

This guy used similar methods to get his fluid interacting with a soft body. He correctly identifies the major pain in solving the boundary condition calculations.

I was talking to a friend at Sony about this and he told me I should take a look at smoothed particle hydrodynamics. I haven’t gone through the paper, so I don’t know what it’s all about yet.

The current state-of-the-art work at nVidia was presented recently at GDC 2008. Here’s the PDF, there’s some nice stuff int here even if it is just presentation slides.

UPDATE: Mick West has been kind enough to upload some code and accompanying Game Developer articles for a Stam solver he wrote. Very nice!

UPDATE: Found a pretty hot SPH demonstration with source by Takashi Amada. This runs 2000 particles and does surface calculation for the lot. Super!

I guess the best-known game of this type is Corewar, and if it isn’t then it’s the biggest one I’d heard of when I heard about it.

Corewar is a game played between two or more computer programs on behalf of the players who create them. Known as warriors, these programs are written in Redcode, a low-level language similar to assembly. Warriors battle to eliminate all opponents in the core memory of the MARS virtual computer.

Here’s a lengthy review of the game.

Two computer programs in their native habitat — the memory chips of a digital computer — stalk each other from address to address. Sometimes they go scouting for the enemy; sometimes they lay down a barrage of numeric bombs; sometimes they copy themselves out of danger or stop to repair damage. This is the game I call Core War. It is unlike almost all other computer games in that people do not play at all! The contending programs are written by people, of course, but once a battle is under way the creator of a program can do nothing but watch helplessly as the product of hours spent in design and implementation either lives or dies on the screen. The outcome depends entirely on which program is hit first in a vulnerable area.

I also found a link to one million other games involving robots or other programming activities as their gameplay. The rest of these I got from there. Kudos to Steve Robbins for compiling and maintaining that list! It’s awesome! The rest of this post is made up of quotes from the game websites or from Steve’s page.

Grobots is game in which robots eat, fight, and reproduce under the control of programs written by the players. It runs on Mac OS, Windows, and (without graphics) Linux. Screenshots:

JROBOTS is a clone of an old game called CROBOTS. Some bots fight in an arena, firing missiles and avoiding enemies’ projectiles. At the end only one will survive! This game is involving, but it is not interactive: you must develop the AI algorithms of your own bot using the Java language, then you upload it in the arena and follow online its fights against other bots.

The bots in AIWars are insect-like mechanized units, programmed in their own command language. They come fully loaded with scanners, shields, sensors, energy cells, friend or foe beacons, mines, fuel, ammo, missiles, and even a self-destruct mechanism for those really sticky situations. This game has many web sites hosting regular tournaments.

Roboforge lets you construct gigantic robotic gladiators, train them to think and fight, and then unleash them in massive international tournaments for money and prizes. Videos here. Screenshot:

I think it’s great that there are so many of these games. Keep it up guys!

Things that went wrong:
No clear design
The game started out, conceptually, as an RTS where you placed computer components on a grid in order to generate “bits” which would travel along the copper tracking (i don’t know what it’s called) of the circuitboard, which you would lay down. Then it turned into a clone of Outpost Kaloki, and then a kind of cross between that and Sim City. The simulated heat flow led to a lot of confusion over how the game worked (and whetehr the fluids could be made fun).
Mixed goals
Not having a clear design led to different aims throughout the project, which led to development of a few systems that didn’t need to be developed. I was also keen to capitalise on the “hardcore” of the name, if not in the game design, then both in the visual feel of the game and in as much of the code as possible. It wasn’t possible to add much actual depth in the design in time, as it would have required too much balance. There’s probably too much in there as it is.
Anyway this led to the fluids thing, which took days to get in because it’s really annoyingly complicated code. I had fun trying to crack the problem yet again (I’ve tried several times before) and it turned out that the only way I could get it done was basically copy-pasting the code from someone’s java implementation.
Time
A combination of lack of management and a three day holiday in Paris led to my interest waning in the face of a tough deadline, and then I started reasoning that if I wasn’t interested in the project then I’d never make it good anyway and it was too much like hard work and we do these things for the love of it right? So I basically stopped working on it on the 17th or thereabouts.

That’s about it. I wouldn’t have had time to do any decent art either, which sucks, and had decided early on that the game would basically not have sound. Overall it was a bit of a washout. Sorry to disappoint anyone who was looking forward to the game.

I’ve uploaded the build, with source and research papers, over here. Instructions for use below (and included in the archive). You’ll need to install Microsoft .NET Framework 2.0 if you haven’t already.

Hardcore Computer Simulator

–Explanation–
The game is a cross between simple tycoon games like Outpost Kaloki and complex grid-based simulations like Sim City. The idea was that you place components on the circtuitboard, they work together to provide computing power to Users, and when in use, they generate heat which needs to be removed from the case or the parts overheat.

–Playing the game–
There is no way to get money back currently, so you’ll have to place what you want and then watch the simulation run. Place parts by clicking the symbols at the bottom of the screen (a popup will tell you what you are buying). You need to click twice as the first click brings up a new menu. Place them wherever you like. The striped areas are vents. You’ll need to buy at least one of each process to see Users’ processes running, but it doesn’t matter anyway as there’s no result from doing this yet.

Click the icons on the right to show various windows (the comp window is for editing components, so if you change this and save them, you’ll fix your changes forever). The console window does nothing. The status window show what’s up with your money and how many resources are left. The users window shows who’s connected and what processes they’re running (they’re all trying to run games at the moment). The component window appears when you click a component you placed on the grid.

Click the heat button a few times to increase the opacity of an overlay showing the simulated heat flow in the computer case. This is the best bit really. Place fans (change the fan direction by clicking on th efan and adjusting the slider in the component window) to direct air flow around the case. If air is coming into the case, the area near the vent is cleared of heat, so you need to set fans so that air comes in through one of the vents and out through the other. Experiment with what works best.

That’s it, enjoy!

–To do–
If I were to finish this game, I’d need to put in Users using different processes; time limits on levels; getting money back from users who were successfully running processes; possibly component destruction from overheating (they already stop functioning); some better graphics; some level design (possibly with obstructions in the circuitboard when you start); a use for the logs I downloaded; more component types; possibly a more coherent way for components to interact (at the moment the only thing resulting from actually placing the components is their heat flow which isn’t supposed to matter in the early game); a ton of other stuff I thought of.