Ska Software, whose games I love, have a really, really awesome free game called Survival Crisis Z that makes me want to just give up and abandon Deadrock forever. Why should I bother now? What is the point? SCZ is the game Deadrock is supposed to be, pretty much.
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.
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 🙂
I’m brainstorming zombie-related ideas in the forum. Please feel free to add your own ideas either in the brainstorm thread or in the comments 🙂
Long or short ideas, unrealistic, ridiculous, funny, dead serious, convoluted, super simple, technical, artistic, theoretical, any kind of ideas or thoughts are welcome.
First deadrock video.
This happened because of the consolidation I mentioned earlier. The furniture is hacked to always load the chair model. The Actor always draws the 3D model if it exists. When I put the code in the same class, the player started drawing a chair instead of the player sprite.
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.
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).
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.