Teemu v1.2 released

Download the game from Teemu homepage link at the bottom of this page. This version is mainly an engine update with some extra items. Chests are different now, they can be opened and closed, and also moved around. There is also movable object type, but none of them are present in this version. I wanted to release this version now, because I really needed a break from Teemu. I'm quite happy that I was able to rewrite the game object system and also some other parts of the source code. It's now more data-driven and better ready for things like npc actions similar to player's.

Playtesting day 4

Almost all feature fixes are done, but there is one new bug. It appeared when I compiled the game with VC++. It was first complaining missing header for std::sort which is 'algorithm'. GCC didn't notice that, but it's older version that came with DevC++. It's impossible for humans to update GCC manually so I have to work with that older version. The actual bug is somehow related to std::sort which in VC++ seems to include a null pointer in the list, which should be impossible (only existing objects are added into the vector). Maybe the bug is in GCC too, but it doesn't catch it (wouldn't be a surprise..). I don't think the bug is actually in std::sort implementation of VC++, I guess they would have found out that.

There is a manual way to check this out. It's of course displaying the contents of the vector before and after the sort. That should.. sort it out.

Searching interweb revealed that the bug was caused by something called Strict Weak Ordering.  I have no idea what it is, but changing if (o<=co) return true; to if (o<co) return true; in the comparator functor seemed to fix it. Oh well, yet again one of those cryptic programming finesses that escape my limited intelligence.

Playtesting day 3

I'm in halfway of the adventure. After surviving food clock it's actually quite nice to play. New items are useful as I expected. What I really miss is a good game system with sensible hit points and damage modelling. The current game system  in Teemu is just so braindead. Kicking is probably the most effective way for close combat and throwing bones and coconuts seem to be the way to kill everything fast.

I was thinking of adding some kind of armour class system, but with simple items like a shield for main protection and deflecting attacks. Somehow it's starting to look like Teemu is going to be amazingly similar to Zelda when you think of it. I don't want to "clone" Zelda in any form to avoid being sued by Nintendo, but I'm going to keep it as simple as you can in roguelike way.

That and many other new ideas are however not going to be included in v1.2 which is going to be just an engine update with some new items. I'm very careful  not to repeat the mistake I made with Kaduria, of course. It's wise to think before planning or adding new features. Soon you will be overpowered by the demands of features and unable to release a working version of the game, because there is always something unfinished.

Playtesting day 2

It's funny what things you find when you actually play your game. First fail was in the way throwing hit removes all power points from the monster. That obviously makes possible to repeat attack until the monster is dead. How could I miss that one?

There was also a huge bug in object spawning. The code was trying to create item or monster only once and if something was in that place, it failed. I noticed the bug when I was trying to find an important quest item from the level and it was not there. I think this bug is actually in the current version 1.11! Good thing is that no one actually plays Teemu. This second bug is already fixed and it's giving a message if item creation fails, so I can keep track of those situations, should they now ever occur.

I keep dying in starvation all the time, but of course now when spawner is working correctly there are also more food items created. I planning to release 1.2 when I can play it through.

Playtesting

Loading save game fails completely. GDB is as cryptic as ever. It doesn't even show a backtrace which makes it hard to understand where the bug is (well it's obviously in save and/or load game, but where...). Output shows a lot of "frames-invalid", that's GDB's way to tell that the program crashes. I know that! Now it could be a good moment to move this project to VC++.

Found it. I was using good old "get key" to see the point where it exits. The bug was in player's save game so it was quite easy to search. I was saving the light item's slot id to restore the light item pointer when game is loaded, but I forgot to save -1 in case there is no light item in use:

if (light_item!=0) tb.Put(tool_inventory->Get_Slot(light_item));
else tb.Put(-1);

I forgot that else line and of course the load game was loading the value when there was none saved.

Almost ready

I need to write commands for looting chests (and add some virtual function actions), then I could start playtesting. When I think of physical interactions that could be useful for alternative solutions to some problems I was thinking of fire... it could be cool to try to burn anything wooden, something like a locked wooden door. Maybe fire could have some negative effects also, like producing deadly smoke clouds. Adding fire is not that difficult, or at least that's what I'm thinking. Fire could be actually an object itself, that way it could just exist when it has fuel and send fire damage to anything in that place.

Grass DeBugger

So I was picking up grass and the game crashes after I pick up a second item. Not in first item, but second. What is really bad is when you try to figure out the bug with GDB, which I have now renamed to Grass DeBugger. It's alright telling me that it crashes in Pick_Up_Item. So what, I know that. I really miss the way Visual C debugger works (the way that lets you actually find the fucking bug). In fact I think I have to move this project back to VC to fix the bugs. With GDB it's pretty much the same if you just go through the source code and try to find the bugs yourself.

Switching to events was a sure way to get bugs, because it can be confusing sometimes to keep track of them.

Well, after some manual debugging I found out that I was using an old object handle in pick up: when you pick up something the handle is destroyed when item is added to an existing stack. So, that one was pretty simple.

There is however a trickier bug when kicking coconuts out of a tree. Somehow the coconut can't be picked up, it's not detected by pick up routine (using Level::Find_Item_At). The strange thing is that debug list shows the coconut and you can also see the coconut (it's in the map).

Fixed that bug too. I was using == operator to find match for location and of course some of the z values were different (not always zero as I expected). Made a new routine to check only x, y -coordinates.

Monster actions

Monsters can mainly move and hit in Teemu, but I have slowly started to plan more actions for them. I've tried to write generic action routines for the player which then monsters also could use. It's achieved mainly with event based programming, executing parts of the action in the proper place. That way both monsters and the player could execute an action and get individual results. Sadly I think this feature is going to be ready only in far future. The current plan for ARRP includes only the change from player-only actions to events and of course the object system rewrite which is almost ready. I want to believe that I'm able to finish all needed changes before ARRP, but things can happen.

Obstacles and new fov

Added obstacle type of game object. It currently has two objects: sandstone block and large boulder. I had plans to use sandstone blocks in some kind of sokoban levels, and now they are ready for action. The remaining object type is a container (those chests) which are basically obstacles that you can stuff items into. It's going to be the hardest of game object types since I'm planning to also change the way inventory works.

New fov map was quite easy to do. This time I used a clearing routine to set up visibility blocks and it went nicely in the lightmap clearing loop. I was able to simplify the actual los drawing so I think the fov is as fast as ever.