Spellcaster Studios

Make it happen…

Balancing, tweaking, replay…

Well, not much progress lately… DayJob™ has not abated, but hopefully it will calm a bit down in the coming weeks, due to end of a big project…

Anyway, I’ve been taking mainly care of fixing bugs, balancing, tweaking, etc…


After a bit, it gets a bit boring, specially when you start to question yourself a lot; for example, earlier this week I toned down the enemies’ health pools on the starting worlds (danger level of about 25% – worlds further away from the initial position have a larger danger level)… I thought I’d got it just right and played some more, going deeper into the galaxy… but today I started revisiting the game from the start again, and I felt they were so easy they became no fun… It seems the practice makes all the difference, but it means that I’m no longer suitable to define the difficulty level of the first areas again… BUT (there’s always a but), in this game, there’s also other factors beyond the health pool of the enemies, and most of them are defined randomly… For example, playing in lava levels or jungle levels that are more “bumpy” is harder than playing desert levels… Playing against beam weapons is harder in the desert than on the jungle, since there’s less places to hide… High-burst weapons like the pulse bomb or the shotgun are much more effective in those…


So all of these factors have to be considered, and the more I play, the better I get at it, and the more I get away from the “common player”… It’s a tough job, and a bit boring at times… Another issue this game has for the testing guy is that it has a grind component to it, that gets old if you’re playing it through for the tenth time… It’s supposed to be 50% killing stuff, but also 50% of doing side procedural missions, which aren’t implemented yet, so I have to do 100% of killing stuff to get alloy… I could cheat, of course, but I also need to understand and balance very well the drop levels and equipment cost, so I really have to go through it…

I also found that I can nitpick a lot… Smile Example: first image in this blog post is the new waterfall effect… I had to put it in, after looking at the same place without it… And I’m feeling like remaking all the terrain generation code for the jungle and swamp levels… too many fringe conditions which are “pretty” and “realistic”, but that don’t make good/fun play areas…

In a game that has such a big procedural component has this one, the environment is also a very big part of the balancing and has to be analyzed and deconstructed as much (if not more) than drop rates and health pools.


The good news is that sometimes I really get into it (even after all the playthroughs I’ve done so far) and I get greedy (just this enemy and I’ll beam back to the ship to restore health), which is a good sign!

Time for an update!

Well, again a long time has gone by…

Time has been very limited lately, due to work (long hours, and very tired), but some progress has been made…

The storyline/cutscenes have been progressing nicely, with the silly engine I’m using behaving better than expected!


A lot of small bugs fixed, pirate camps added to the galaxy, ground work for random missions, etc, all have been implemented, although I’m still a long way off…


Anyway, need to figure out a way to get more motivation to be able to work more hours on the game… Nowadays, I stay late at the office to be able to use the computer there for programming, since I know if I go home I’ll have to deal my crap computer and lack of multi-monitors, which leads to little will to code… And I really hate to do coding on a laptop (although it’s workable for cutscene/balancing work)…

Anyway, hopefully the game will be done in the next couple of months… if everything goes alright… which it never does… Smile

Portability work

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! Smile

So, until next time!

Not many updates…

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).

Wow, much work, many pixels!

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!




In-game shop!


Tutorial system!

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)

Revision: 64
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

Revision: 63
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)

Revision: 62
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

Revision: 61
Date: 30/11/2013 00:43:30
- Added email console
- Added navigation console
- Added hyperspace effect
- Added lander model (replacing hunter ship billboard)

Revision: 60
Date: 26/11/2013 22:14:28
Added base console system, including browser, malfunction, maintenance and login consoles.

Revision: 59
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

Revision: 58
Date: 23/11/2013 13:38:15
- Added Gear class

Revision: 57
Date: 23/11/2013 22:30:26
- Added pirates
- Improved AI (for pirates, but after will use it for robots as well)

Revision: 56
Date: 19/11/2013 23:09:50
Added camera drone
Added custom map loading

Revision: 55
Date: 18/11/2013 23:02:30
- Added electrofloor trap
- Idle anims kick in earlier than previously

Enemy base generation

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):

struct plDoor
    int dir;
    int target_id;
    int size;
    int pos_x,pos_y;
typedef std::vector<plDoor> plDoors;

struct plRoom
    int    id;
    int    x,y;
    int    sx,sy;
    int    index_x,index_y;
    int    area_id;
    int    distance;
    plDoors    doors;

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!

It’s been 20 days already!?

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! Smile

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”)…

Better late than never!

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 riversscreen33
  • 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 anymorescreen38
  • 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.screen40
  • 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!)

More game work = Less blog time

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.


The ElectroCannon!

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! Sad smile

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!

Chrome Hunter: Postmortem


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!)