Stone muffin

There was some talk at RogueTemple about Abura Tan, an abandoned roguelike project by Michael Blackney. I remember couple of years ago I tried to create an SDL version, but in HD failure I lost the open project. However I was able to find just one backup which I guess was the latest one.

It did not compile right away in the latest GCC version, but it was quite easy to fix couple of errors it had. It runs, but there is a bug in display routines which I guess is my fault. When changing from DOS (an old operating system) type output to SDL I made some kind of error. In fact the problem is that I don't understand the gameview code. It's quite weird.

There were 99 warnings (using relatively strict compiler settings). I've fixed them to 80, but there are still work to do. Lots of shadow variables which may be a source of possible bugs. I could also search for "the usual suspects" of C programming. Things like malloc/free, memcpy, void* pointers etc.

This is a "spare" time project that could be useful once it's ready for a release. Someone may find it easier to continue from a project which can be compiled and run in modern environments. Also, some better programmer than me can then fix the display routine bug.

For some reason I call this version the Stone Muffin project. I don't know where I get these ideas.

Teemu: I know your name

Last couple of days I've been creating a name generator with hand-selected name data which has been more difficult to create than I thought. Since I don't speak english it's possibly harder to remember common names like Charles. Rather than copy pasting all names in existence I've selected names that fit the pirate theme. Something like dutch, french, german, spanish and english names.

There are also pirate names and nicknames appearing sometimes. I think this was worth the effort and also I think I can use this system in Kaduria as well, since while it has a name generator it's not this well written or using std::string like this one.

Teemu: Bird or avatar?

After fixing some events I realized that parts of the event system I had in Game_Message could be changed to create message events. So it was even easier to fix than I thought. However other events still can produce message events which can happen in wrong order, but only if it can be noticed! There are only small number of other events so they are quite easy to check out.

Next thing was the sign object type. It went ok, but it required more than I remembered. First you had to add a new list type to Level class, but then also a genuine map for signs. For non-moving objects it could be easier to have a combined map for each object type. The problem with sharing object types for one map is that objects don't know their type. This was a design decision I had, because it's more OOP than knowing the type. I don't know it has any real advantage.

There is a lack of checking for overlapping object types during creation so it's possible that some objects can be created over others. In fact I have to create a routine to check that thing. I also need a debug text output routine really bad, because a lot of stuff is happening during the creation.

Teemu: Events

I started refactoring messages by detaching "long" messages (those which appear when you enter a new place etc.) from the regular messages displayed on top line of the screen. Then I rewrote Game_Message class with std::string style code taken from Kaduria. Messages are now event driven so adding a message will only add it to a list without directly showing it.

A while back I added a primitive event system for Teemu. What I didn't realize then was that direct messages and event messages created a logic error where some messages were displayed in wrong order. This also happens with current event driven message system, because messages and events to display them are two different layers of events! The reason why it went like that was that I suck as a programmer. Yes, I'm afraid it's the case.

Anyway, I think fixing the event problem is not going to be too difficult, because there are only few events happening. More so, only those events that have something to do with regular messages are wrong.

Teemu: Signs

The secret feature is almost ready, but it has to wait for other GUI elements to settle, because there is a new arrangement in that area coming.

For another new level theme I needed a new object type which is a sign. With the introduction of game objects (other than enemies and items) the source code has suddenly taken a step to more complex class hierarchy. I really try to keep the game object class (and derived classes, actual game objects) as simple as possible to avoid same kind of trouble as I have in Kaduria. Still, it already starts to look similar system I'm using in Kaduria, just in much smaller scale.

Started to const correct object strings, because I want to change message routines to std::string the way I now have in Kaduria. It's much better that way, but of course means some rewriting.

I'm also keeping a daily LOC count just for fun, to see how much code is actually written for the new version.

Teemu: New level theme

For ARRP I've continued Teemu. In two days I have added one new level theme, that one I was talking about earlier. It required one new algorithm created in short time. It's nice when you are able to create a simple algorithm that has cool and required output. The level theme's code is only 33 lines which isn't too bad. It's still missing items and monsters, but their creation is still open, because I'm planning more generic creation process for game objects.

Today I made a new feature which luckily has little to do with the core engine. For that reason it was easy to add and possibly nearly as easy to complete.

Brick Atelier 0.85

There is a new version of my in-house tile editor. Download it from http://koti.mbnet.fi/paulkp/brick/brick.htm.

Now when I got Brick Atelier out it's time to return to the island so to speak. I wanted to add one new level theme to Teemu, because I had an idea for it and it's not just another level theme. Yes, even I get ideas sometimes!

Biggest problem in Teemu is partially static level creation process. If you want to add "super lots of items" it's better have dynamic creation with some kind of logic for what is created and how much. Still I try really hard to avoid any kind of too heavy engine programming, but some of it is required. I want to keep Teemu a fun project as much as it is possible.

ARRP 2013

It's soon here, but what to expect? It looks like RL developers are not excited about it, because the development plans always follow their own schedule. Still, I could try to release new version of Teemu somewhere around the date. It's anyway the next thing, after new version of Brick Atelier is released which is very close. There is only one (easy) unfinished feature in BA and then some testing.

Teemu's to do list doesn't seem difficult, but the last version was released three (what the fuck?) years ago so it's never too easy.