Well, some people came me to me and asked me how I was generating the procedural bases, so I decided to put this up to explain my ideas…
Note that this isn’t ground-breaking stuff! I’m using it to build the pirate lairs (and space bases, etc), but it can be applied to any kind of structure, and it’s easy to add logic for staircases, multiple floors, etc)…
Also note that although Chrome Hunter is a voxel-based game for the environment, nothing in the system is tied to that representation (specially because when I generate the pirate lairs, the system doesn’t even have voxels in it!).
So, steps to build a floor plan:
1) Generate X times Y rooms, in a regular grid… These numbers can be adjusted depending if you want larger or smaller rooms… Note also that if you have a specific need, nothing in the algorithm really need the grid to be square (although a grid is necessary… you can probably extend the algorithm, but it becomes much harder)
Next, generate doors between rooms… I randomly generate between 0 to 4 doors, with random directions:
Note that this might generate dead rooms, but that’s no problem…
In my algorithm, I then kill random rooms, and remove all that don’t have a door to them… In the screenshot below, if the room has been killed but it’s “internal”, it shows up as a solid blue block, otherwise, if it’s external, I just remove the walls:
Next step is guaranteeing that all rooms are accessible… To do this, I use a “painting algorithm”, and expect it to yield only one area… if more than one area appears, I scan the map and open a door between different areas… in the case above, I only had to open one door:
Then, things start losing the “grid” look: I merge adjacent rooms that are connected… For this, I ask for a random room and see if I can merge it with an adjacent one… To be able to merge them, they have to have a door to one another, and have to have the same size on the other dimension (so if it’s a east/west door, they have to have the same north/south size)… I repeat this for some random number of times:
Then, to break even more the regular grid look, I move walls around… That means that I move a wall perpendicular to it’s direction until I find a wall. Again, this is randomized:
Finally, I analyze the map and decide where to place traps:
All of this works through a "room/door structure”, which in my case looks like this (I’m lazy):
typedef std::vector<plDoor> plDoors;
So, there’s no reference to voxels, just some reference to a static grid-like system… This could be probably changed by using local reference frames and rules to merge that are slightly different, but that’s probably a lot of work!
So, hope this helps in someone’s endeavors in the world of procedural generation!
There’s one million awesome papers would a lot of information on how to generate more realistic stuff, but for more purposes, this was great!
Well, development has been great… been working a lot of long hours, but it’s a lot of fun…
What have we been up to? Well, general improvements and more of everything, really… I’ve been keeping my twitter busy with updates, but again, it’s the old choice between doing more development or blogging
We have new planets:
Desert planet has also a new enemy type (sound sensitive sandworms – I never said this game was original!).
Alien planet has glass clouds and other environmental nasty stuff!
I’ve also added the dark planets: planets where there’s no light, so you have to use a flashlight!
Of course, these are the more visual stuff, there’s been a lot of work behind the scenes, and I’ve started writing the story as well (it started really simple, but it’s getting better and better!)
Now, I’m going around working on something that was being considered for a long time, because of the aditional development effort: enemy bases!
I’ve decided to make them, since they add a different flavor to a part of the game, which breaks from the repetitiveness of shooting enemies, moving, shooting enemies, etc…
Here’s some samples of randomly generated bases for your viewing pleasure:
Ignore the textures, of course!
I’ve started also to add some new traps to it:
There’s still a ton of work to be done on the bases (and everything else, this game is becoming much larger than it should), but every week I’m getting closer and closer to being “code complete”)…
Well, although there hasn’t been many updates on the blog lately, I’ve been working like a maniac both for DayJob and for my games!
On “Chrome Hunter”, I’ve added one million different things, for example:
The player can now jump and fall
Jungle planet was refactored to look better, with lakes and rivers
Added a statistics system to help me balance the game out with the testers
Refactored all the AI system: now I use a state machine, which allows me for more complicated AI… this will also allow me to build different types of AIs
Added support for Recast/Detour, so now the robots don’t get stuck anymore
Added a special “hologram generator” equipment, which places decoys that follow the player… Unless the player attacks the enemies directly, they’ll stick with the decoys; this was only possible because I can have different AIs now, and because I can easily implement a follow AI, with the navigation mesh and pathfinding.
Added a virtual resolution system (which rescales the UI for different resolutions), and a dialog at game start so you can choose the graphical and sound options.
So, a lot of work got done…
The pathfinding part in particular was very useful. On “Grey” I’m using just straight navigation through the center of the nodes, but that looks terrible… my idea initially was to use the DetourCrowd module to have better movement, including movement with a lot of agents that would avoid each other… After looking into the documentation, and its limitations, I decided against that, and I implemented (on “Chrome Hunter”) a system that does string-pulling for getting a steering vector for the agents, and then using that in combinations of a “boid-like” system that makes the entities avoid each other. It needs a bit of fine tuning, but with some more conditions, I might have the ideal system for navigation on “Grey” as well…
Add that to the fact that I found out how to use the navigation queries properly (to allow for things like make the agents avoid water unless it’s really to their advantage, and to open/close areas), and I’m quite happy with the learning experience on “Chrome Hunter”… I’ll really put that to good use on “Grey”!
Since not everything is rosy in gamedev, I looked into device recovery for the “Chrome Hunter” codebase… Basically, when you alt-tab a fullscreen application, Windows fudges the graphic resources, and the graphical device gets into a “lost” state… to reset it, you have to release all video resources and reset the system. On Spellbook, the system was built with this in mind, and everything goes smoothly, but the “Chrome Hunter” framework is a bit anarchic, which means that doing this will be a nightmare…
The good news is that this is really only a problem for DirectX 9 (think 10 and 11 don’t suffer from this)… OpenGL doesn’t need this at all, since by design it handles this automatically; since I intend to port “Chrome Hunter” to Linux and Mac, I’ll need to port it to OpenGL, which means the problem will go away then!
I’m still having a lot of ideas for the game, and I have to do my best to keep them in check, or else I won’t finish this game anytime soon!
Finally, since I have a spawning system with a nice follow system, here’s a screenshot of about 30 or so holograms running around:
Was surprised the system managed to hold up without a significant drop in frame rate (it’s a lot of navigation queries!)
Not entirely true, but when I’m in the development zone (as I’ve been in the last couple of weeks), I don’t feel like stopping to blog… It’s more a question of “should I had this or should I blog about this I just did?”…
Anyway, I’ve been toiling on both Grey and Chrome Hunter…
On Grey, most of the work has been on the AI of the summoned creatures, including behaviors like “Follow” and “Wander”… Also did some minor UI work, to make the gameplay flow better.
Added also camera control, which was quite hard to get to what I feel is “exactly right” (this being entirely a subjective quality).
Chrome Hunter (I definitely need a better name for this) is advancing much faster (it’s also a much easier game, since I don’t have some many worries in building “good code”)…
I’ve added hundreds of small things, from weapon to gear, improving the map, effects, playability, balancing, etc, etc, etc…
Above you can see the beam cannon, the enemy analyzer and the mini-map.
We’ve worked mainly on the “Lava Planet”, and I did change the way the map is generated (now it’s all generated at landing, so we can have a more continuous map and the edges of areas are no longer empty); the downside is that I broke everything else in the process!
Anyway, we’ll get that part up and running soon, so that we get the game in a playable state again… That way we can start to balance some of it and see what’s missing…
My to-do list gets shorter everyday, but it’s still one million miles long…
New storyline/cutscenes and better AI for the enemies will take some time, and there’s also some surprises in the game yet!
Next week I’ll be away on a trip for DayJob™, and I might be able to work on it at nights, but it won’t be easy!
Well, as you might have noticed, we stopped blogging in the middle of the project… And that’s the symptoms of “not-enough-time-itis”…
Anyway, we’ve finished the game, and I wanted to do a short postmortem on it…
What went right
Scope wasn’t as bad as it’s usually on 48-hour competitions… We set realistic goals, and we managed to finish a pretty complete game
Pixel art was a big win… we weren’t sure of the capabilities of our graphical artist in terms of pixel art (he’s a 3d guy), but he did an excellent job, even with the animations. He was really fast pumping out work, keeping a bit ahead of the coder (which is great!)
Using my Ludum Dare engine instead of my Spellbook engine: although Spellbook is more complete, it’s not very compatible at this point in time (very graphical card dependent still), and it misses the “main pump” components (different screens, etc), specially on the SurgePlayer. Besides, it kept us from falling in the temptation of putting more effects, or better rendering, etc…
A lot of gameplay/weapons/gear put in at the last hour, so the code was relatively well organized.
The music work was awesome
What went wrong
Lost more than 4 hours of coding (and some art time) because of the procedural robot system… We had to give up on it since it was sucking big time, and it still had lots of problems!
UI work is painful and takes a lot of time to get right
Not enough time to be able to test and balance the game properly… testing the game after the deadline, we’ve already found 10000 small things we’d be able to fix and balance really fast. We even found a fatal bug that will probably impede anybody from finishing the game!
Postponed too much the splash screens, etc, so when the artist started on them, he was already dead tired and the results suffered for it.
All in all, it was a very satisfying and rewarding experience… We’re even considering taking a couple of week off Grey to polish this and try to go Greenlight it (it would be a learning experience, to get the grips on how Greenlight actually works, and if we can sell 10 or 20 copies of it at $2 each, it would already be very good for morale!)… Besides, the game is actually fun when you get into it, except for the boring stuff that can be balanced out!
We’re very happy with the end result, considering the not-so-clear ideas we had at the beginning… Stay tuned for more information in the future regarding this game (maybe we can even figure out a better name for it!)
I’ve just improved the terrain generator with trees and rocks… These can be different (in quantity and image) depending on the type of planet…
It really improves the overall look, and although they’re just cosmetic (no collision detection for now, at least), it also has gameplay impact (for example, jungle planet becomes harder because you can’t see the enemies as clearly).
Still need to tweak the AI a bit (and add the robot spawning as part of the generation of the planet), and then I can move on to the Starmap screen!
…but great progress!
After 5 hours of sleep, I’m back to work!
I was so “in-the-zone” yesterday that I didn’t even stop to blog!
After the setback with the robot procedural generation, I thought that there was no way I could make up for lost time, but actually I burned code at a pretty fast pace…
Most of gameplay mechanisms are implemented (enemy AI, loot grabbing, UI, etc), at least in the planet view…
Rincewind is way ahead in content production (so far, I’ll catch up!), and a friend of mine is making the music (which already sounds amazing!)
Today I have a fairly large list of things to do, but I don’t think there’s anything too complicated at this stage (and I have about 23 hours to go, if I don’t sleep)…
Now, to finish the basic gameplay systems (moving from area to area/crossfade) and then I can start work on the galaxy menu…
Robots are running… or more precisely, they’re standing still…
Rincewind used the pieces he already built for the procedural robots to make these really fast…
Now, to hit them with my shots and test explosion (before they start running all over the place with the AI)…
but not out!
I just lost about 4 hours building a procedural system to make the enemy robots, but the results were terrible and very buggy:
I call abomination!!
Anyway, decided to change the game design slightly so we don’t depend on procedural robots… We’re going to use artist-made images for the robots, which will have different abilities, etc… Some of them carry pieces of equipment we need to win the game, instead of the objective being the robots themselves…
It’s not perfect, but the AI issues become simpler and we streamline the production, since Rincewind proved he’s much better at pixel art than I expected!
Don’t think I’m having much sleep today…
Ok, got shooting to work… First weapon is the shotgun:
It won’t be able to fire so fast (it’s a slow weapon, with a lot of damage), but this is just a test anyway…
I’ve also fine tuned the movement and camera a bit, so the game feels a bit smoother; still don’t have a solution to the camera occlusion, but I’ll wait for it to be a big problem.
There’s also a problem with the rendering of the shots, since they’re being affected by the lighting of the scene, which is not what I intend (have to add some kind of rendering pipeline for “glowy” stuff).
Now, the hardest part of the game (I think): creating the procedural robots!