Roguelikes and all things Roguish


August 2015

Upgraded to libtcod 1.6.

So today I updated to libtcod 1.6

and I updated my MinGW compiler.

There were some issues compiling libtcod 1.6 at first, so, for anyone who cares, the makefile-mingw  command in libtcod 1.6 was using incorrect keywords, for those who were getting a “Missing separator at line 28” error, but everything is tabbed in as it should be, use this make file instead of the one in the repository:

Download My makefile

There are also errors in the library itself (and I dont feel like going on bitbucket and fixing them on there ) so:

When you compile the debug version it will give you some warnings about radiobuttons, but if you aren’t using the gui version of libtcod, then you can safely ignore those. (Of course you could always jump in and rewrite that bit as-well, I wont bother going into details about that, but its an easy fix regardless)

Also you WILL get this error when compiling the release version:

c:\mingw\include\math.h:635:30: error: ‘_hypot’ was not declared in this scope
{ return (float)(_hypot (x, y)); }

Just change that bit to
{ return (float)(hypot (x, y)); }

Hope that Helps anyone who is trying to compile libtcod 1.6!

Segfault Week And Hunger Clocks

Sorry for not posting a devlog this weekend,I spent the entire week (alongside my other two actual jobs) debugging Roguelegends: Dark Realms like mad, (including the weekend)  it was a strange error, because it was happening on my friends computer but not mine, so I had no real way of recording the error (I have yet to add support for crash logs, but I plan to), so that was “fun”.

Other then that I have recently been putting a-lot of work into the Hunger and Thirst Systems, My game Roguelegends : Dark Realms doesn’t use a standard Hunger system.

The Hunger/Thirst Bars  look like this currently

At Full:


When Dehydrating (Notice the thirst bar goes down at double the speed of the hunger bar:

(when your hunger or thirst bar turns to 0, the bar changes to a dehydration/starving bar respectively, the dehydration and starving bars start at 50 but go down at double the speed of the hunger or thirst bars.


When you run out on your “dehydration bar”:


It Starts picking at your max health until:


The Same Happens when you are Starving To death except Your hunger bar turns to “Starving” and is an amber color.

In a standard roguelike, your hunger bar is hidden, and when you starve to death it is usualy an instant process, in my game I instead went with this:

Hunger-Starving (Strength/2) – lowering your max health, so it takes awhile to starve, but when you do, you have permanent consequences

It works the same for my Thirst bar

Thirst-Dehydration(strength/2)-> lowering max health

If you are both dehydrating and starving you always attack monsters “In vain” because your strength is equal to 0.

Certain Foods Increase both your hunger bar and thirst bar, some more or less then others.

The meat from corpses (which already drop rarely) for example gives food but little to no water, so you HAVE to get off your current level to find water (This prevents players from attacking enemies too long to grind), The hunger bar, is in there to make sure that the player cannot abuse the system on the next level, and it goes back and fourth. It is also interesting to deal with, instead of just eating food all the time, you have to try to manage both food, and water. And it is also easily noticeable. so ~hopefully~ it wont be as confusing as the standard system to new players.They reduce your strength to further prevent grinding to the point where you cannot even attack.

The Maxhealth being reduced, forces the player to deal with the consequences of their actions, without being TOO evil about it (which is why it is gradual and not immediate).

What do you guys think?

Updated My Game Development Page

I have decided to update my game development page with a bit of info from my game development document, for your reading pleasure. And, I finally have a proper name for it!

This week has been busy, things will cool down in one week, and I will be able to work full time on it that week, but University starts back up in about 21 days, so Ill be busy afterwords.

However, I will make sure to do at-least weekly blog posts on its development and the principals behind its development.

My Way of Coding Roguelikes

I have made roguelikes many times over the years, and in my time of coding roguelikes, I have come up with my own kind of “style” for making rogue-likes.

My  (and my codeveloper’s) most notable one, is the 7drl “March 15 1924”, despite its small size, it is a good means of showcasing what I mean when I say “my style”.

Recently my closest friend, and co-developer, Greg brought it to my attention That when I make a roguelike, there is always a small distinct set of features that I try and never fail to add that makes the game distinct from other roguelikes, I will list them and I will try to point out why I think they add to a game.

1:Deep Descriptions for everything (including walls and floors)

Most of the time when you play roguelikes, and you examine something (if there is even an examine function) you get simple descriptions like “it is a floor” or “it is a bat” even in nethack. While this is good for influencing the player to interpret the world themselves, I think it is bad for immersion. When I play a roguelike ,and this will be very controversial,  I WANT to be immersed in the world, while most people would argue roguelikes are for tactical decisions, and for people who want to be very tactical instead of about immersion, I think that a game can be very tactical and very interesting and immersive as-well. Being immersed in a world makes it so you are more likely to play it longer, you care more about your character and the world itself.

I do love ASCII for the ability to interpret it your way, but I think that giving detailed descriptions also helps you to interpret the world, when you see “it is a floor” you probably think a very plain floor, but when the game says to you “This is a floor, it is cracked and dusty from millennia of disuse” then now the floor you envision in your head is a more interesting floor, a floor that reminds you you are in an old dusty untouched place, a floor that has history to it, a floor that is more interesting. This can only be a good thing,

Many may argue that very little people will make use of the examine function, however, I believe that if they do, then the first time they use it I want them to say “wow”, and when they say wow, I assure you it will be used more. It also adds considerable polish.

2: Simulationist ideas (eg, you are usually able to equip anything as a weapon, and can try to interact with everything even if it makes no sense in that situation, with appropriate punishments for dumb interactions.

I am a big fan of the game “dwarf fortress”, this has probably influenced my simulationist leaning when choosing roguelikes and developing them. In that game , you can equip anything as a weapon, and interact deeply with everything, if you find a person, not only can you talk to, become friends with, and join that person, but you could also kill them, and butcher them, and eat their heart and keep their brain as a trophy. People love the ability to use everything as a weapon, there are even reports of people throwing fluffy creatures  called “fluffy wamblers” so hard that they have taken the heads off of bronze colossi no other mainstream game is capable of having THAT happen.

I couldnt find an image of a human being butchered (you can do that in adventure mode, but here is a pile of prepared organs)

A Bit grim to explain, but its a power the game has, I like to replicate this kind of idea in my games, in my games, you can usually use any interaction as long as it makes a slight bit of sense.

As You can see from my unreleased alpha game from several years ago “roguelegends”. (I apologize for the ascii tileset, of course I was going to add support for proper graphical tiles later)

In this image, an individual has decided it was a good idea to shove their chainmail armor in their mouth, here is the result.

In Roguelegends, one example I will use is, “consuming” items, in this game you are able to put pretty much anything in your mouth, this includes large rocks and armor, I’m not saying it will turn out well for you if you do, but you can.

I think this also adds to immersion, and it adds a procedural depth to the game, its very cool, for you to be able to interact very deeply with the items in your possession as long as its accessible,  lets say you are in a tough situation, MAYBE, just MAYBE, you have a better chance at escaping when you have a deeper set of interactions. In the below video, (of our old 7drl march 15 1924, the person lping it was very interested when he found out he could examine everything, and he was more terrified as a result (it was a survival horror game). He also got stuck behind a crate, he then bashed the crate open (since that was possible in the game) to escape He bashed down a door as well, another power as a result of my focus on mechanics.  He also had the ability to bash down walls (and he would have survived if he had figured it out, sadly we weren’t very clear that you could do that, so he never tried it.

One problem with adding these aspects to your game is that it hurts accessibility because interactions may become confusing, and in my current project I am working on just that, more on that when I have something to show for my work.

Good Night! And happy rogueliking.

Create a free website or blog at

Up ↑