Category Archives: Devlog

Dyson plans

Thanks to everyone who left feedback on Dyson.

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:

Town generation baby steps

I’ve been working on town generation for a while now, since the last update. I did a bunch of internet research and I have a bunch of links to throw up on the blog here but I haven’t written it up yet. So here’s an update of what’s been going on.

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 🙂

Game entities and inheritance

While I’m busy not writing the camera frustum calculation code, I’m looking at making actors in the game (zombies, furniture, the player etc) more manageable.

There are two goals. There first is serialisation and dormancy: I want to be able to reduce anything in the game that isn’t scenery to as small a data set as I can so that I can save it to disk or keep it in memory without it taking up unecessarily large amounts of space. That is to say, when an entity leaves the playable area, or when the game is saved, I want to lose all the fluff that is used to make the entity seem real on the screen, but keep enough that later on, I can rebuild a reasonable likeness of the entity as it was on-screen from this small set of data.

The second goal is to remove the object-oriented inheritance tree I made for the earlier prototype. Currently, the game knows about a base type called Actors, and the Zombies, the Player and the Furniture all derive new classes based on Actor and implement new code on top of it. What I want to do is have a pool of Actors that know how to be any of these things, so that I won’t have to keep a different pool of each type of entity. What this means is centralising all the code from the three existing classes into Actor, and removing type-specific stuff into places where it makes more sense. This would also more easily let me create more than one Player entity, for example (it’s worth noting at this point that I haven’t consciously built the game in any kind of network-friendly fashion, so I doubt this game will have network multiplayer in the foreseeable future).

For example, at the moment the Zombie class doesn’t do much except set up a new AI program to control the zombie, and set up the graphical data to display itself. There’s some other stuff in there to do with taking damage and seeing the player, but there’s no reason why these couldn’t be in the main Actor class, even if it were under some entity-type condition. On top of this, moving the AI code into the base class would let me set up AI programs for anything, not just zombies.

Overall, I see lots of benefits to removing my badly-designed object hierarchy and making the whole thing more modular.

3D models working / first public devlog

So this is the first public development log for Deadrock. I’ve been posting screenshots for some time to the forum, but I’ve decided to move most of my output to the blog.

Deadrock started as a 2D rendered isometric view much like the old X-Com games. I was calculating all the depth myself and drawing everything by hand. It was all rather tedious and confusing, so for this reason amongst others, I switched to 3D.

It was fairly easy to do in the end, and I managed to reproduce my old 2D view pretty quickly. One upshot of this is that I can draw anything I like in 3D now, so I decided to make all the furniture in the game 3D. The furniture is created in Blender, and then exported to Wavefront .OBJ, loaded in to the game and drawn as a display list (or in OpenGL immediate mode).

Attack of the Giant Chairs

This is 60 chairs each of 6 quads rendered at different angles and at a far greater scale than they ought to be, on top of what the world currently looks like. Most of the draw time is drawing the world, as it’s not properly culled to the camera frustum. It currently takes 2 milliseconds to draw these chairs on my machine. Should be OK to use as it is then.