Since libtcod is now ported on Haiku, games using it can easily invade this OS too. The only downside is that I had to disable FMOD and lua to get the cave working on it, but if your project relies only on libtcod, compiling it should be a snap, especially if you have a linux or mingw makefile. Just grab Haiku VM (works with vmplayer, vbox and qemu), get SDL source and compile it, get libtcod for haiku and with a few tweaks, your makefile should work.

There’s new hot stuff on Umbra’s front too. I will give  a try to the 4DRL contest next week. But I don’t want to start a project from scratch, nor copy the cave’s code and blow it apart. I want my “treeBurner” 4DRL code to be easily reusable for the cave. Umbra provides an obvious way to do that : develop modules for the 4DRL and simply replace  the cave’s module in the main function. But what would be even better is to be able to define the module chain in an external configuration file.

That means you could replace a module by another one without recompiling. More concretely, you could add a transition screen between the main menu and the game without recompiling (providing you have a module that implements a transition screen). We could even use this module dedicated configuration file to add custom parameters so that we don’t have to use libtcod’s parser, we would have a configuration file out of the box.

Exemple of simple module configuration for the cave :

moduleChain "theCave" {
    module "mainMenu" { active } // the module started first
    module "chapter1Story" { fallback="chapter1" }
    module "chapter1" {
        floatParam { name="playerSpeed" value=8.0 } // a custom parameter


For this to work, modules must have names, which would make them easier to manipulate (engine.activateModule(“chapter1”) instead of using the module’s internal id). The parameter playerSpeed that I define here could be immediately accessible inside the chapter1 module with a call like getFloatParam(“playerSpeed”).

With this system, I could create modules for my 4DRL entry and a simple update of the module configuration file would allow me to switch from the cave to treeBurner. But what if we could define several module chains and switch from one to another by changing the active chain with a single parameter ?  This would make it possible to have several game mode, or several games in the same exe…

Well, believe it or not, everything already works in Umbra’s svn version. A proof ? Remember pyromancer’s code was hidden inside the cave. Now it’s accessible again, thanks to a second module chain :

moduleChain "pyromancer" {
    module "pyroTitle" { active fallback="pyroGame" }
    module "pyroGame" {
        floatParam { name="playerSpeed" value=12.0 }
    module "pyroGameOver" { fallback="pyroTitle"}
    module "pyroVictory" { fallback="pyroTitle"}

Now if I set moduleChain=”theCave” in umbra.txt, when I launch the exe, I’ve got the cave. If I set it to “pyromancer”, I’ve got …

pyromancer ! I haven’t run it for months, yet it’s there, and with the cave’s UI goodness (message log and status panel). There are probably a lot of bugs and side effects to fix (you can probably open the inventory and crafting screen even though there are no items in pyromancer), but it works !

All this is work-in-progress but it should be stabilized in an upcoming 10.11 version of Umbra. Also be aware that if you’re using Umbra, upgrading it to the svn version will break some APIs…

[edit] Well, Mingos has already posted videos about this on youtube ! Head to his channel for more info :

6 comments so far

Add Your Comment
  1. fmod? 🙁 (because of license and stuff you know)

  2. Broken API? Never come across th*CRUNCH* Damnit! Start again… ;P
    It’s always nice to see what’s coming next, even if I never get my pet project completed.

  3. fmod is free for non commercial use, but it’s not ported to Haiku yet.

    @Scautura : the API break is small. As far as I know, only the registerModule has changed. You should upgrade and get the module configuration goodies. A bigger API break is upcoming because we want to rename most event linked functions in a more consistent way (onInitialise, onActivate instead of initialise,activate and so on…), so you’d better upgrade before this one 😉

  4. Actually, I took care of the registerModule change in a way that should be as little painful as possible. The additional parametre is optional, so old code should compile anyway.

    Now, the upcoming mthod renaming is a different story… But the change will be for the greater glory of all Umbra users, as the method names will be more intuitive :D.

  5. Hm, could this also be a way of managing mods? A mod could be a module (heh, mod… module… nice) that adds new items/monsters/rules, or changes some stats.

    Although this is pretty cool, its usefulness is limited by the fact that the modules themselves must be done in native code; you can only shuffle them around. And there will be instances where a module activates another one, and you really can’t do anything about that since it’s part of the core functionality. But yeah it’s nice that you can activate different game modes at will 🙂 I’m just not sure that this data belongs in config files, if you switch from the cave to pyromancer you’ll probably have to change other things in the code, and recompile anyway 😛

  6. Well, support for lua modules doesn’t seem impossible. It’s even a pretty sexy idea… 🙂