Work has been progressing lately, albeit not too fast…
Anyway, most of the work lately has been on the portability, since I want this game to come out for Windows, Mac and Linux… Problem with this is that the framework I’ve been using (the one from my 48-hour compos) wasn’t designed with portability in mind, so it demands I do a fair amount of refactoring…
Anyway, I’m taking it slowly, by steps…
First up, I removed my dependency on the D3DX library (except the shader compilation, more on this later)… For that, I reworked all the matrix code to use my own primitives (most of them taken from Spellbook), and I ported the text rendering code to FreeType 2… It’s a quite nifty library, and I use it to create a font atlas and I render the text using the normal “blitting” code of the engine.
The text now looks slightly different from the text under D3DX, but in some instances it looks better, so that part’s done.
After, since I want to port the game to OpenGL 3.2, I had to make it work in shader-only mode… So far, I was using only the fixed-function pipeline, but under OpenGL 3.2+ it doesn’t work (and to be fair, I like the flexibility of going for shaders in the future provides, for some eye-candy), so I have to make the game work only with shaders…
So I’m not tackling two tasks at the same time, I first did the migration from fixed-function pipeline to shaders (still in Direct3D 9), so the game is currently only using shaders for everything… Some things are a bit slower (due to the larger setup stage of rendering), but I can probably shave off some milliseconds from that and get it back to the same performance as before…
Below you can see a screenshot that looks almost identical to before, but now is fully shader driven!
So, the next step is probably getting OpenGL 3.2 working, which will no doubt carry its fair share of pain… I’ve never worked that much in OpenGL, so I only know the basics, but hopefully at the moment the rendering is abstracted enough to minimize the work…
I also have some new assets to put in the game, and that will lead to working on some new cutscenes, which will make for a nice distraction from the heavy load of work that’s incoming… But I can’t wait to see the game running under Linux and Mac… Will be very cool!
So, until next time!
As you probably noticed, there hasn’t been any updates for more than one month… Reason for this was the Christmas break, and DayJob has been very intense lately, with some expansion being prepared…
Motivation has also not been soaring lately (probably due to the down time), but I intend to rectify that maybe next weekend, with a coding marathon to get me pumped again…
Anyway, the only development in the last weeks has been the jetpack, mostly because there are still inaccessible places in some maps (the lava maps are prone to it), so if the player falls in some places he can’t get out! He can use the home beacon to teleport back to the ship, though, but it might be frustrating… And some holes are almost impossible (although I might solve that in the future with better lighting). So, to offset that, I’ve added the jetpack, which the player can buy and use in this kind of maps…
Actually, flying around with the jetpack is quite fun, so I think the player will use it quite extensively when he unlocks it.
Also added camera collision, to avoid the (likely) possibility of the camera looking through the terrain when the player falls, although I’m not 100% happy with it, even if nothing can be done to solve it completely (can’t tilt the camera because the player is just a billboard/sprite, so you wouldn’t see him anyway, so I can only play around with the distance).
Hopefully, with some more playtesting I’ll be able to figure out how serious this issue is… it seems to me that it only happens on the “Lava” levels, since they are the ones with more irregularities in the terrain (by design).
Well, work has been progressing immensely on “Chrome Hunter”, but I really haven’t stopped to write much…
I’ve done one million things in the game, and now it’s starting to look it’s part: cutscenes (simple ones, of course), tutorials, the works…
I’m starting to add more work on the actual balancing/story of the game than on the backend stuff, so I’m expecting the game to be finished in another couple of months (give or take some more, depending on how tired I am of DayJob).
Some chosen new stuff:
Custom maps (mostly for story purposes): this is the Skydancer (a bit different now from when this screenshot was taken), the player’s ship. This acts as a a hub for the game.
Pirates! The AI had to really be improved to make for interesting behaviors inside of bases… Still not 100% happy, but with balancing and such I’ll probably find ways to improve it further.
Consoles! The player will find consoles throughout the game world, containing secrets and information.
New navigation console. Some functionality, better organized!
So, a lot of work… And this is just the visual part of it… behind the scenes, the code has really evolved and it’s becoming much better… Also finished writing the story and the random mission templates, so this is getting closer and closer of being an actual game!
For fun, this is the current dump of the SVN logs since the last blog post… My messages are just stuff I jot down for future reference (when I want to remind myself of what I was doing)
Date: 10/12/2013 23:29:47
- Added more cutscenes (pointing to the "structure north", introducing enemies and sandstorms)
- Added tutorials: items, shooting, UI
- Sandstorm warning now comes from the Skydancer
- Tutorials can now queue
- Load and save anywhere (no menu for it yet, just functionality)
- Disable home beacon on loaded scenarios
Date: 9/12/2013 21:01:12
- Added cutscene system
- Added tutorial system
- Added first cutscenes (introduction to the game story)
- Added first tutorials (introduction to the controls, etc)
- Added speech system
- Fixed bug with jumping next to "almost-stepable voxels)
Date: 4/12/2013 01:54:50
- Added log console
- Added load/save game (with multiple slots)
- Added start email/log entry
- Added shop console
Date: 30/11/2013 00:43:30
- Added email console
- Added navigation console
- Added hyperspace effect
- Added lander model (replacing hunter ship billboard)
Date: 26/11/2013 22:14:28
Added base console system, including browser, malfunction, maintenance and login consoles.
Date: 27/11/2013 02:32:47
- Improved pirate AI and added run and teleport behavior
- Added model prop
- Merged props with trees
- Added props, etc, to manual area loading
- Added palm tree
- Items now drop a bit after the character is killed, not when it disappears
- Added action nodes, including tooltip and zoom functionality
- Fixed in_combat flag
- Separated PlayerData and PlanetData in two different files
- Separated PlanetScreen and PlanetArea in two different files
- Split render in render2d and render3d
Date: 23/11/2013 13:38:15
- Added Gear class
Date: 23/11/2013 22:30:26
- Added pirates
- Improved AI (for pirates, but after will use it for robots as well)
Date: 19/11/2013 23:09:50
Added camera drone
Added custom map loading
Date: 18/11/2013 23:02:30
- Added electrofloor trap
- Idle anims kick in earlier than previously
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…