Why another library ? Why in Rust ?

I’ve always wanted to port libtcod to the web. Back in the days, the browsers were too slow. Then things improved and I was able to create a typescript library similar to libtcod. But typescript is being eclipsed (at least for me) by the almighty Rust/WASM combo.

To me Rust is the best language since C. It’s fast, it’s reliable and it can natively target native linux, windows, mac and the web. Sounds like a developer dream.

What’s in doryen-rs ?

This is only the console part of libtcod (input + rendering).


  • fast GLSL renderer
  • keyboard and mouse support => in alpha, lacks typing support
  • true color console => in alpha, lacks advanced formatting methods and console blitting
  • bitmap font support => supports rgb and rgba fonts, greyscale font support to be added soon


What will be added ?

  • UTF-8 support
  • PNG image blitting on background color
  • subcell resolution : might be added later

Where is it ?

On github of course.




Some libtcod news

Hey I’m coming out from obscurity to give you a few information concerning libtcod.


New maintainer

Kyle Stewart, a.k.a. Hex Decimal, long time libtcod contributor and developer of the first python wrapper is joining the admin team on bitbucket. He has been the main contributor for some time and I’m confident libtcod is in good hands with him.


libtcod rust wrapper

To me rust is the perfect language for roguelike development, especially since it’s a first class language to target web assembly (even if it’s still a bit rough right now but it gets better every month). There’s an ongoing effort to write a libtcod wrapper. It’s already featuring most of the important stuff. You can find it there :




I’ve just discovered pico-8 and voxatron.

Those are respectively a 128X128 2D console and 128x128x32 3D voxel console. They both come with harsh limitations. For example, pico-8 has only 16 fixed colors and the game code is limited to 8192 tokens.

Yet, amazing little games have been created with this limited environment. Here are a few of my favorites.


Behavior trees sneak peak

I have the first version of behavior trees ready in yendor.ts, just not yet pushed to github.

The result is that monster’s AI is now trivial as it only has to execute the tree tick function:

public update(owner: Actor) {
   // don't update a dead monster
   if (owner.destructible && owner.destructible.isDead()) {
   if ( this.behaviorTree ) {
      if ( this.__context === undefined ) {
         this.__context = new Yendor.Context();
      this.behaviorTree.tick(this.__context, owner);

Now all the creature intelligence (rather dumbness right now) is described in the actor definition JSON :

    ai: {
        type: Actors.AiTypeEnum.MONSTER,
        walkTime: 4,
        tree: new Yendor.BehaviorTree("basic hostile humanoid",
            new Yendor.SequenceNode([
                new Yendor.PriorityNode([
                    new Ai.FindPlayerActionNode(),
                    new Ai.TrackScentActionNode(SCENT_THRESHOLD),
                    new Yendor.InverterNode(new Ai.WaitActionNode()),
                new Ai.AttackPlayerActionNode(),

The priority node run its children until it finds a successful one : if the player is visible, the creature tries to get to melee range using path finding (FindPlayerActionNode), else it tries to track scent (TrackScentActionNode), else it simply waits (WaitActionNode). This will make much easier to have creatures guarding the chests as planed for 0.8.0.

More info on behavior trees.


Yendor.ts 0.7.0 release

There are probably a few bugs here and there, but overall it should be quite stable :


Next step : behavior trees !