Thursday 25 December 2008

Bug found

I found a bug from Teemu. You can play the game without entering a name, just press enter when name is asked. Funny thing is that it seems to work fine, it doesn't crash the game. I don't even know if it's a bug, but I'm fixing it in v1.1.

With limited inventory of Teemu I created a tool inventory with items you can only (u)se. This new invention will also prevent extra checks with tool items and makes more room in the inventory for new items.

Monday 15 December 2008

LambdaRogue 1.3

Still don't like the 5 tile height gameview in large tile mode. It's ridiculous. I think Mario should just dump all other modes and make one good graphical view to the game with enough visible tiles both in vertical and horizontal direction.

I don't like the dungeon algorithm either. It's maze-like and boring to explore. When I think of mazes and particulary corridors I think they shouldn't just run here and there. The dungeon should have a clear idea, whether it's just for storage room or place that someone actually lives. No one lives in a maze but minotaurs.

There are more dungeon features like barrels to kick open. It's nice, but if they are all just scattered randomly in a maze it gets boring quite fast. I think that distinct level themes are the proper way to create nice gameplay, which then form the game world with different locations to visit.

Sunday 14 December 2008

Ideas of Teemu

This entry contains some spoilers from Teemu so win it first and read this next. Before the release I was talking about some new (for me) ideas I had while developing Teemu:

1. The strategic situation in spider cave. Spiders don't want to go in water, but there are lots of them and you need to wipe out them in some way or quickly get to the chest and get the item. This kind of strategic situation could be set up in many different ways.

2. Moving platform (the ship). In Teemu it's only a part of the end scene, but could really be used to travel on water. Ships or smaller vehicles are less used in roguelike games.

3. Grab command, something that could be more complex, giving new kind of interactions with the game world.

I think all these will find their way to Kaduria.

Sunday 7 December 2008

Teemu v1.0 released

Here it is. Fixed the "last" bug and it was uninitialized member variable, a counter that determined how long monster is searching with the pathfinding. That uninitialized value was random so monsters sometimes got stuck on walls and didn't respond to anything. I hope it's fixed now. The game is Windows only and should work without M$.NET.

Release version bugs

The problem is not in gcc, because VC++ release compile also has the same bug: monsters just go somewhere and get stuck in walls. It could be uninitialized variable, because debug and release versions might have different values for them. I think I have to double check the routines that take direction as parameter, because some functions assume that it's a valid direction and nothing else.

Then there was a bug with endianess of wst file (my tile editor's native format). For some weird reason it's reversed in release version vs. debug version of VC++. I have no idea why. Anyway, I don't want to do anything more today. I wanted to release the game today, but this difference with release version was an unpleasant surprise.

Test stories

I have tweaked items and monsters in Teemu and haven't yet won the game. I have included messages warning about hunger, but still I died two times in starvation. Maybe the food meter is too fast. I could slow down it a bit and make food items less powerful. What I like in this game is the way you can get in trouble fast if you make a mistake and I do mistakes a lot. This game is practically ready, but I still have to win it to release it.

Then there is one little thing to do.. I have to compile the project with DevC++ to get rid of Visual C++ dependency of .NET. GCC also has good optimization options. There are some VC-specific stuff I have to give an option for GCC, but I think it's going to be just couple of small things.

Actually it was just two warnings with -Wall. One was returning -1 from unsigned char return value and other was unused variable. That's all. I can't believe there were no other problems. It took about five minutes to set up the DevC++ project and compile it.

Friday 5 December 2008

Teemu ready for testing

Teemu is ready, only some minor details missing like level descriptions and maybe some game world interactions with new terrain tiles. I have an odd feeling now, because this will be my first game released in a long time and for a moment I was worrying how people will react to it when they may have certain expectations. Well, I can only blame myself for being such an ass with all that stuff about Kaduria and how it will become the next gen roguelike surpassing every major roguelike.

Thursday 4 December 2008

Serialization part 4

There were two bugs in load game. First one was easy, I copy-pasted npc restoring code and there was old value from item restore loop so it tried to restore too many monsters. The second bug was a bit harder, but found when inspecting the load buffer size. I forgot to clear the std::string where data was stored before loading next piece of data, so the new data was added to the old string.

Load game seems to work now and I can concentrate on pathfinding routine.

Wednesday 3 December 2008

Serialization part 3

I'm testing the save and load game routines. Loading doesn't work, which wasn't that much of a surprise. It's giving me out of bounds error with std::string. It seems that I have to use a debugger for this one, which I rarely have to do, because usually I'm writing bug free code. I'd like to know more about Visual C++'s debugger, because I'm not that familiar with it. It seems to stop when player's data is loaded, but the traceback information shows that it's breaking in Level's load routine. Go figure, but stepping through the code should clear the confusion when it's actually crashing.

I already programmed today more than two hours so I think I'm going to do something else like home page for the game, so it's already there when the game is ready.

Tuesday 2 December 2008

Serialization part 2

Save game routines are now ready. I'm taking this carefully, because I want to have bug free save and load routines. I'm constantly checking with hex editor that the save file contains proper data. I also wrote new packer routine for maps that are saved to reduce the amount of space they take in the save file. Loading is going to be more difficult, but I'm sure it will work fine without big problems.

The pathfinding problem is annoying, because I know from experience that I'm going to spend a lot of time to create it. There are also some bugs in throw routine, which has been difficult in Kaduria as well.

Sunday 30 November 2008

Serialization of Teemu

One of the reasons why Teemu is taking so long to finish is that I'm doing some of the routines first time. One of them is serialization. The first and easiest place to check how the load and save works was the scoreboard. I don't actually know how other people do serialization, because I usually become confused when I read source code programmed by some random dude.

I was thinking that it would be easier to save the number values as text, because then you don't have to worry about types. Arrays are saved as raw arrays, because they would take more space if saved in text mode (numbers separated by comma). The file mode is binary and it's always containing the next block size loaded in one piece.

I'm using a helper class named Tar_Ball to save and load data for objects. It's a low level class which makes load and save routines in object's class clean:

void Score::Save(K_File *f)
Tar_Ball tb;

for (int t=0; t<Max_Player_Name_Len; t++) tb.Put_Char(name[t]);



void Score::Load(K_File *f)
Tar_Ball tb;


tb.Get_Next_String(name, Max_Player_Name_Len);


Now I just have to save the world. Game world, to be more specific.

Thursday 30 October 2008

Testing combat of Teemu

Today I was testing how the creatures should react to attacks. This is the first time I'm this far in a combat system. I never did that for Kaduria, because I have focused in complex world creation and the combat system of Kaduria will be different anyway. I think it will not have hit points at all, but Teemu certainly has them.

You can already hit and kill the enemies and they respond to attacks, but there is no movement or counter attacks yet. I created all monster types in one level to test the combat and it's easiest if they don't move around. It's tempting to add features in this stage, but I try not to do that. I'm free of high expectations for this project, it's not even supposed to be complex.

I started to make the power system, but then ran out of time. I'm keeping it in that two hours strictly so I don't get tired of programming. This seems to be the best idea I've had in times. The game may actually be ready in two weeks.

Saturday 4 October 2008

LambdaRogue 1.2

This version has nice looking graphic tiles, but the graphical mode is unusable because the odd gameview size 20x5. So you get visibility of whopping 2 tiles in north and south directions. The ascii mode however has more visibility and it's better in terms of playability.

I don't know what happened to the gameplay, but when I allocate skills points to fighting it's almost impossible to die, at least in the dungeon at right side of the overworld map. I just went on and killed everything with few hits. If that is not easy enough, you have 20 aspirins in your inventory and they are good for healing your character.

Some of the UI decisions are strange, like when you need to input a number when digging (besides I tried it a couple of times and it didn't even work). The game is tediously asking you to press space or enter in every situation, but when you die it's possible to exit the game without seeing anything, because the direction keys are now "any key" that quits the program.

The dungeon is very boring with lots of dead ends and predictable layout of rooms and corridors. I don't know what you should be doing in the dungeon, maybe kill everyone?

I don't want to sound too negative, but the way the graphics mode has been destroyed is epic. In top of everything the tile height is two times the width. Why? Tiles should be square sized and preferably the gameview too.

Monday 29 September 2008


I'm creating a roguelike definition that is partly an answer to rather poor one they made in International Roguelike Development Conference 2008. Then I heard that Rogue didn't have player classes. At least the original Rogue which I actually had never even played. My only contact to Rogue was in Atari ST era when I played a commercial Rogue published by Epyx. It had graphical tiles and I could swear it was more complex than the original (I guess it's 3.6 from Roguelike Restoration project).

The problem in my definition is that it makes Rogue itself a non-roguelike game, because you can't select a player class. Yeah, it's kind of funny. In my definition Rogue is an adventure game. I had this idea of building the definition on top of role-playing, but it seems that Rogue itself is hitting this definition hard from beyond the grave. My first contact to "roguelikes" was Nethack so it was always my idea of a true roguelike and the foundation of the definition.

The absence of role-playing in Rogue makes it harder to define a roguelike, but maybe it's still possible to create a decent definition including adventure games (simple form of role-playing).

Tuesday 5 August 2008

LambdaRogue 1.0

This time I was able to actually kill something, some worms, but the game told me that I shouldn't kill them. Like.. why. They are worms and enemies. The I was quickly killed by ant-something when I was trying to find out why numpad diagonal keys don't work. I didn't land a single hit, maybe because diagonal keys don't work in numpad? I tried both num lock on or off.

The user interface is still confusing. You have Space, Return, Esc and both mouse buttons to perform actions, but they seem to work different way in some situations. For example Esc doesn't always exit the current window, you need to use Space to continue. It's just confusing. I'm hitting all the wrong keys and buttons all the time! Well, it's not that bad actually, it's just an user interface.

The game itself seems to be pretty simple. I can't say, because I always die very soon when I can't hit the monster for some reason. This is becoming a game I love to hate.

Wednesday 9 July 2008


Let's first go back to discussion about traps. The first problem is that even if not harmful random traps are just too random. They make the game world look like a random generic place which I think it not good. Then Numeron said something interesting: "even damage traps can be used to get monsters to walk over when chasing the player."

Then why monsters can't set traps for the player, making the same mechanism work against the player? It's because setting traps is hero exclusive. The traditional or high fantasy design is based on the myth of hero, who is some way more gifted than anyone else in the world. In fact this design is familiar from the first computer games like Pacman who can eat pills and use the magic power of that big special pill. And how about Link from Zelda-series? He can use the master sword to beat evil monsters. That design is like a lock and key, they both must exist.

But what if the hero didn't have any special skills? It would pretty much also remove the lock or high fantasy evil & big monsters. Well, maybe not if there are other ways to defeat them, but I guess it requires more original design and therefore rarely used in games.

One of the important hero exclusives is magic. It's probably the most commonly used exclusive and that's why many role-playing games can't be won without magic. Sometimes wizards become more powerful than fighter characters, because magic in entire form is hero exclusive. Some monsters can use magic, but it's usually restricted for tactical reasons, so that the player can prepare for the spells and have a key for them.

The obvious problem in low fantasy is then how to make the player character survive in the first place? It's an interesting question and from my point of view it's so much better than following the same old road of high fantasy. Everything feels new and you can expect to have gameplay balance issues that need to be solved in some clever way.

Wednesday 2 July 2008

Frozen Depths 1.03

Frozen Depths is a roguelike written by Glowie. It has a cold world theme, but I didn't have time to notice the effect of cold since I died in the first level. I think the coldness is a gameplay clock, but I'm not sure.

A distinctive feature is the large number of floor traps. This I always thought was bad design, because you usually can't avoid traps unless you search after every step. Searching while moving is so annoying that I never do that. Floor traps make you wonder how the native inhabitans of the level ever survive. Do they all know where the traps are?

In my main project Kaduria game objects are trapped, so when you handle something you can be sure that it's your fault if you didn't check for traps. There are floor traps also but I plan to create them on specific levels that are trapped for a reason so you know there are traps. Or if traps are found elsewhere they are in obvious places (guarding something etc.) I believe that only the player's wrong actions should lead to death and there should be less random accidents that has nothing to do with how good you are as player.

Tuesday 1 July 2008

The cave

New screenshot from Teemu:

It's a cave. But, there is something different in this cave. It's not just any cave, it's there for a reason. The inhabitants of the cave made it like that. It's a functional cave and a real part of the game world. This small difference made me think "why, of course..." If you create a random level with random monsters that has no other function than be a level, it's going to be poor.

A new feature is unexplored tiles shown in dark grey color. It makes navigating easier when you see what areas you have visited and makes a clear distinction between floors and walls that are obstructed by the field of vision.

Wednesday 25 June 2008

Teemu news

Making good progress with Teemu. Today I spent only about an hour to add a new feature which is super fast and very different than adding a feature in Kaduria. The game world of Teemu is going to be very simple, but I try to create interactions with the world to make it more interesting as a gameplay experience. Here is a screenshot from Teemu:

The development of this game is actually fun, which is something I can't say from Kaduria.

Tuesday 24 June 2008


This one is pretty interesting new roguelike project by Mario Donick. Unfortunately it's also an example of game design issues that seem to plague roguelike development. There are two important factors of erratic design. One of them is that most roguelikes borrow user interface styles from ancient roguelikes like Nethack and ADOM, and they probably honestly think they are good user interfaces while in reality they are not.

The other more important reason for failure in game design is that some people think their ideas must be the best way to implement a feature. They are too selfish and don't realize why common interface rules were invented in the first place. User interface knowledge is something you need to learn to understand it and never just create something you think is cool and working like a charm.

LambdaRogue has these issues in user interface and its role-playing system too, but it's still a promising roguelike project and I'm going to follow the development of that game as much as I can.

It's actually the only interesting roguelike project at the moment, because you can see the effort he is putting into the development. It's something opposite than 7DRLs which are nothing more than simple ASCII action games. If I want to play an action game I play Pacman or something else with graphics (invented in 1970's).