Terrain decorations

I have improved the terrain generator of Teemu with some automatic decoration rules. It's the same kind of style I'm using in Kaduria: first create generic terrain structure, then decorate with automatic growth of features and plants. The new feature in Teemu is that rules are data-driven (related to terrain type) so with one scanning routine you can determine what extra tiles need to be created for that particular tile. The routine is creating things like automatic shallow water edges between ocean and land, and growing bushes next to trees etc. There is a primitive rule to actually remove bushes to avoid them getting too widespread. It's a primitive form of competing from space which I'm going to use in Kaduria in much bigger scale to create plant growth.

Automap

Automap colors were taken from ascii color values, except entrances which are purple and red player dot.

Scrolling gameview

One of the new features in Teemu. In order to get it work I had to separate the Display-functions from level coordinates and give them absolute screen coordinates. Level::Show is refactored heavily and it's almost ready. I think I need to link the offset checking routine into movement of player and not inside Level::Show, but I'm not sure if there is any speed gained since the offset check is going to affect moving speed anyway. I made the view follow the player's coordinates so it's scrolling each time you move, but I'm going to change that to push scroll type. It's harder to do, but better than continuous scrolling. The main issue with push scroll is the area not visible to player, but reachable by throwing item. The visibility check must include the area left outside the current gameview.

I have already made a support for variable size levels and tried both smaller and bigger than the default size. I guess most levels are going to scale to bigger sizes well, but smaller sizes could need some adjusting. It's nice that the default size for level is gone and there can be different size levels.

Monster spawner

It's almost ready. With monsters there is need to filter more powerful monsters to certain type of levels. I'm not yet sure how to do that, but maybe adding a generic level theme type (cave, deep cave, outdoor level, etc.) and then select monsters along with the individual terrain type. I could also try to make monsters more or less data-driven with maybe some special cases that are possibly easier to handle directly. There is only 25 monster types in Teemu so there is plenty of room for new monsters.

Before I start wildly adding monsters I need to look at the monster family class and see if it could hold more basic type data for monsters, taking some data out of the monster type class. That way adding a monster requires less data input and a longer list of monsters is easier to maintain.

Item spawner done

The item spawner is already creating more interesting set of items which are a lot more unpredictable than were the old level theme based items. There is a resolution problem in finding free places for objects. It's a classic chicken-egg -problem: if you first find places for objects it's going to include unwanted places where some objects could be created. For example monster search includes water tiles where some flying/swimming monsters can be created, but not the land crawlers. Then again, you can't select a monster first and search after that, since there is no guarantee that such place exists (not all levels have water).

The solution could be two or more search patterns combined with specific set of monsters for that place type. I can think of four such scenarios: terrain/cave, forest, beach and water. Maybe the level creator could actually determine those places automatically by searching and counting the size of each area type. That's surely something to try with monsters.

Spawner

I've started to implement the spawner for items in Teemu. First the spawner collects data from items and determines where items can be created. When the level is created the spawner is scanning the level terrain and creating random items selected from the filtered lists. There can be factors like where the item can be placed and how rarely the item is made and other stuff like that. With the spawner the creation process of items becomes automatic and I can start to add more item variety which is one of the main features of the next version.

Messages

The way messages are handled gets complicated when the engine is becoming more generic. My plan is trying to have the responsibility inside Message class as much as possible to avoid if-code in the caller function. I've created several types of message functions from simple message to object message checking the distance and visibility to the action object and changing the message when the player can't see the action for that object. Then there are of course player vs. other object problem. At least for now most messages need to change the message structure for the player and some if-code is there. However I think I can manage them the old school way, without need to create a more sophisticated message system.

Kicking ass

Level::Throw_Loop is now generic. It came with a cost though, since some operations needed to be moved back to caller, especially deleting the object if it's destroyed in throwing collision. I have to see if it's possible to write a generic destroying routine, but I think it will be difficult.

When testing kicking with creatures I also noticed that the projectile has to be removed from the level list while it's flying. You could do self-checks, but only for some things. The list routines are buried such deep into the level structure that it's just easier to remove the object, then make it fly and after that add back to the level list. This could mean some extra Add/Remove -functions for different types of objects, but it's only a minor style issue.

It was nice to see that I could kill another monster by kicking a monster at it. The damage routine isn't very sophisticated, since you can kill a monster effectively by kicking a chicken at it. That needs some adjusting, but it's closely related to the gameplay system which is very crude at the moment. The projectile could also be damaged and even killed. If you kick a chicken at elephant you expect the chicken to take damage while elephant only gets angry.

It wasn't that hard after all, other than the bug when monsters are kicked to water: they seem to freeze there, unable to realize that they are in water.

Throwing chairs

I have moved Throw_At_Me function in the game object base class and it's not even a virtual function, mainly because it's calling virtual functions to get different types of results with derived objects. However I think the main throwing loop must be made virtual, because there are type specific things involved. Another option could be a collection of smaller virtual functions.

An example is the way object is landed after throwing. When you throw something at a big object like closed door the object isn't placed at the same place, but in front of it. The rules also change when you can throw other objects than items. This rule could be a small virtual function. The reason I need virtual functions is that I planned the base class so that it doesn't know the main type of the object. It's a small but important detail and leads to a design style where virtual functions are responsible for getting the proper result when something is done with the object. I think that's how it should be done, because the other option would lead to type-check code with special cases and that's something to avoid when you try to make a generic engine to drive the gameplay content.

Throwing coconuts

Refactoring Teemu's GO_Creature::Throw_At_Me routine to generic collision routine between two objects of any type. It has involved some thinking and five new functions. When it's done it should not be too hard to change the actual throwing loop to handle all object types. It means that in future you can throw other objects than items. The main application are smaller monsters that can be kicked away, but maybe also chests. Even doors could fly away by force like explosion.

Gui programming part 4

For some reason Brick Atelier hangs for a long time when loading tiles. That bug appeared from nowhere and maybe related to a memory leak. GDB gets puzzled of course (I'm developing BA with DevC++) and has no idea where the bug is, it doesn't even report anything. So, once again I need to move this project to Visual C++ to find bugs. The map editor is quite ok, I found a partial solution to the ellipse routine which is giving me a big headache. It's this stuff again: the world doesn't have a C++ ellipse routine that produces symmetric bresenham type (one pixel edges) ellipses in all x/y radius values. I'm too dumb to understand math in that context and unable to program ellipse routine myself. Well, maybe some day.

Gui programming part 3

Another long day at work. I have added an option to adjust the editor pixel size between 3-7, but that's all. Usually when I get some feature done I'm already adding a new one to the list. Bugs seem to work the same way. Next major thing before anything else is get rid of two fonts and create one font, better than both current fonts. That should make some gui stuff easier to create.

I don't know yet how to handle the hovering help system, because at the moment events are check only when there is some action (mouse moving, clicks, keyboard) so you can't hover on gui elements to get a popup window. I'm aware that help system would make it easier to learn how to use Brick Atelier. It's obvious to the developer, but painful to other people trying to figure out how the program works.

Gui programming part 2

Refactored the map editor of Brick Atelier, though it's missing implementation of some drawing tools. If I want to get them working I need to create another layer and a mouse hook just like in main editor. I guess it's not that hard and it's nice to have circle and box drawing routines for map editing.

It was easy to add the icon set for map editor tools and I'm glad I wrote a (more) modular icon set class earlier, because I was already thinking about icon sets for other than the main editor.

I'm programming Brick Atelier mainly at work which is kind of strange, but I have some spare time to spend and I'm just slowly programming stuff and trying to make the time fly faster. It certainly does. I don't know any other activity that makes time go faster than programming. Well, maybe it's the same for things that require concentration.

Gui programming

One thing that makes development of Brick Atelier (former Stile) hard is not only the low level gui programming but the fact that the way I programmed the "engine" was really not that clever. It's not impossible to fix the problems, but I found out it takes some work.

For example I had defined consts for zoomed pixel size and of course used them everywhere. Now I want to be able to adjust the pixel size (it's the way to make the app window smaller or bigger for different resolutions) with an option. Replacing consts with a getter for external classes is not that hard, but it's also quite risky code, because of initialization order stuff. So I need to pass the pixel size to both brush classes (which could be combined by the way), but they are allocated in Drawing_Tool class and that class could be refactored out. So making changes like this may sometimes require a lot more work than just simple replacing stuff.

This constantly reminds me about the importance of planning. When I start the next project, whatever it is, I'm going to plan it well.

Brick Atelier

Now when Teemu 1.21 is released I can take a look at my sprite editor Stile. I changed the name to Brick Atelier which I think is better, since there already is sTile and Stile is a boring name. I had to redo some stuff since I lost the original Brick Atelier version, but nothing major (I hope) was lost. Just the Brick Atelier logo for info screen.

There are some stuff I want in next version (0.83), mainly some kind of contrast/brightness (maybe even color) adjusting for selected tiles and tile import from another .wst file. Those I guess are the main features.

I think SDL could be a wrong library for this kind of software, because it has been quite hard to do GUI stuff from scratch and I still don't have a portable file browser (using Windows browser inside SDL which is some kind of hack). I just don't know if the current features could be done with some external GUI (and maintain the speed).

TEROS

After failed searching free and simple role-playing system for Teemu I started to plan one myself. It's called Teemu Roleplaying System (TEROS) and it's based on seven basic attributes with initials APEWASH. Plus alcohol as regaining health and stamina. The basic idea is make both attacking and parrying attacks consume stamina which then affects to overall performance. The way armour works is also a bit different than usual. I wish the initial system actually works, but if not it's always possible to tweak something to gain more balanced system.

TEROS will most probably be in the next major version (1.3) with more items and monsters.

Playtesting Teemu v1.21 day 2

After fixes I still found one bug, but it's not fatal. You can enter the border exit with > by standing on it.

I think there is no need for more food now when the spawning is actually working. The cellar seems to be little crowded sometimes, maybe less monsters there.

When developing a roguelike there are going to be balancing issues. For instance how to determine the amount of total food items and how to distribute them in levels so that the food clock doesn't become too difficult or too easy? A scientific way could be count how many turns a level takes to solve and calculate the food consumption per level, then planning food distribution based on that data. Or you could just playtest the game to see what happens.

However it's difficult to determine the amount of turns per level, because the number of enemies is changing etc. Even the random placement of objects gives different results. When you design a static (non-random) world balancing is much easier, because you can make detailed plans how to distribute items and monsters.

One way to solve this is look at the player's food situation and create more food items when entering a new level, but it could then become too easy if the player realizes that it's going to happen.

Playtesting Teemu v1.21

New data-driven stairs connection system is mostly working. There is one problem area I need to fix and then it's ready. I was wondering if I could put at least some new content in 1.21. Maybe a low nutrition food item that's easy to find, because I find myself drinking rum to stay alive. Now when there are changing number of cave levels the treasure chest creation must be refactored, but that should be easy. Creating the stairs system was a bit hard, but the great thing is that now I can use it in Kaduria too.

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.

Open door

I'm writing a door class for Teemu derived from base object class. Abstract base class is kind of cool, but I still don't know what to do with map routines. Should objects be stored in 2D map anyway? The problem is in collision checking which is fastest when objects are in 2D map, but maybe there are other ways to do that, like a hash map.

New name for Stile?

It appears that there is a program called sTile. Stile is actually a dumb name anyway, so I'm planning to change it. Maybe to something that no one really has thought before. Or maybe something traditional like X Paint where X is something like.. I don't know.. Super? Super Paint. Super Mario Paint. Wait, that was already taken.

Power Paint? Taken. Fuck, this is harder than I thought.

Smudge brush for Stile

It's a small victory: I somehow managed to add smudge brush tool in Stile. Smudge tool is quite easy to implement when you know the idea. I was surprised how nicely it works. Creating smooth edges is easier with smudge and you can do that between all colors, not just with color next to black surface (as with darkening brush). Other new features of (soon to be released) 0.82 are seam tools for scrolling the tile halfway and then working with the seam, and context sensitive F1 (currently only for icons).

Debug mode

Running in debug mode (F8) in DevC++ is different than just running the program. It looks like debug mode actually catches errors, because it found one that crashed the program after new tileset was made (in Stile). And gdb knew where the problem was. Way! I really need to run in debug mode more often, even gdb output can be cryptic. It's now complaining something about st_copy, I don't know why. Nothing special going on with st_copy.

Memory corruption in Stile

Trying to find a mem corruption bug from Stile. It's quite difficult with DevC++ (gcc), because gdb is not very good at catching errors. I may have to re-create a Visual C++ project for Stile to find the bug. Another option is refactor some shit and hope for the best. In worst case the bug has existed for a long time in some part of the source code. I guess it's about time to find out where it is.

The bug was a trailing zero type. strlen() returns the length without the trailing zero so you need to add it to the buffer given to strcpy which copies also the trailing zero to destination.

Objectifying

The rewrite of Teemu is getting harder. The shift from one object class to derived hierarchy has really big impact on other areas of the source code. I also try to plan better ways to do things like game object creation and in that there can be moments when you don't know what to do. And, as we all know, it's the worst thing that can happen. Not knowing what to do next. How to proceed, how to solve a particular problem.

Events

I've started to use events in Teemu. Before I have had problems to work with events and I never liked them. Until I guess now. Events go well with data-driven approach, because you can load events elsewhere with data and then launch them later. I have kept things really simple and used an abstract base class, then couple of simple derived classes with only one function: Launch(); I started to think about events with long messages that should appear in certain point where you could then skip them without need to press space or enter. But events can be used in many other ways. I just hope I don't get too excited about them...

Teemu v1.2 development started

I'm going to aim for ARRP with Teemu 1.2. I have already added five features and fixed the only known fatal bug (when you try to swap items in ancient cave bottom it crashes if there is no item on the pedestal). There is so much time before ARRP that I may add some serious stuff. One of the ideas I have is break out from the static screen size levels and make some level themes huge. I think the island could be bigger. The nice thing is that most of the level themes probably scale really well to larger size, because I have been careful not to use any literal values. But of course it's going to require some work on display routines and actions like item throwing.

New version of Stile coming soon

I had an epic battle with cursors in Stile, but they should be ok now. New feature is a shadow brush which is the image of brush hovering to see where pixels are going to be painted. Also options and palette are both now saved when changed and there are new options for shadow brush and making the precise brush move one editor pixel at a time so you can also draw more.. precisely with it.

I don't actually need better features for Stile right now so when 0.81 is out I could really continue developing Teemu here at work. This time I could try to aim at ARRP (Annual Roguelike Release Party) and take the time to fix bugs and improve the source code, maybe even add some gameplay content.

Tool refactored

Refactored CTool (renamed Drawing_Tool) and it's now the owner of brushes. Before that I placed brushes into editor window class. The problem was that Drawing_Tool had double data for such things as brush shape. Now when shape is in the Brush class itself and brush objects are inside the Drawing_Tool the double/copy data went away.

The dummy or shadow mouse of editor window is now also working, but it's still flickering which could be easy to fix. Actual drawing operations went to Drawing_Tool class as well. It added passing of some variables, but it's cleaner that way, because brush objects now contained in Drawing_Tool.

To restore the previous version's operations I only need to add brush size commands. I think icons could be better than using 1-6 keys for shortcut, but they could be both there.

It's alive

Spent three hours for getting the mouse hook of Stile work as it should. Removed hacky goto to mouse moving event and replaced with initial call to drawing routine, now separate from mouse hook. Damn it was hard. It's all mess of different types of mouse coordinates, but even here the data-driven shit helped a lot. The routine still has couple of annoying bugs, like jumpy mouse cursor when limiting to an area. In HSV selector I solved that by using a shadow mouse cursor, maybe I'll use that in hook also. I could possibly now merge the HSV selector to the mouse hook.

Plans

I feel that there is need for another smaller project I can make that gives me fast results and some kind of joy from game development. I have several small roguelike projects that I started some time ago, but then again, why stick to roguelikes?

While I have good ideas for new games I also might have some minor personal problems, you know, in life. It's got a lot to do with my relationship to computers, programming and games. There must be something more in life, at least that's what they say. But what? I feel like I have lost my interest to pretty much everything. Maybe I'm just getting old.

Teemu v1.11 coming soon

There was one fatal bug found in Teemu. It's in Tar_Ball::Load function. delete nb should be delete[] nb. I'm surprised it didn't crash the game, but it's a problem that has to be fixed and that's why I'm going to release a new version. I'm also going to apply changes suggested by aave @ RogueTemple which should make compiling for linux easier. I'm also going to throw in the makefile for linux that aave created.

This release is going to be a bug fix and improvement for portability type of thing. I don't want to start add features, I have to stay focused on Kaduria.

Source code released

Teemu's source code is now released, download it from Teemu homepage. Now when v1.1 and source code are both released I can return to Kaduria. It's a different, more complex project, but I have noticed that when I "practice" with smaller projects like Teemu it's sometimes giving new perspective how things could be done. In other words you learn stuff.

Teemu v1.1 released

Download:
http://koti.mbnet.fi/paulkp/teemu/teemu.htm

It's windows only, but there is good news for those waiting for the source code. I made a gcc port with great success. There were couple of things I had to fix, but all in all it went really smooth. Now when it's gcc compatible there is a good chance that it will be more portable than just the native Visual C++ version. gcc is complaining about the Teemu_Gui class initializer list, but it should not cause any bugs. I'm going to go through the source code and look for some things to fix before the source code release.

Slight offset trouble

I've been testing Teemu in window mode, now I tried it in fullscreen and this is what I got:

The offset of window border is wrong. Somehow it looks like SDL is including borders if the window size is not a standard one like 800x600. If I can't fix this really fast it's goodbye for fullscreen mode.

Playtesting finished

I'm pretty much done with playtesting Teemu. Everything seems to work, at least the important stuff. There is just one thing I want to add before release. It's a support for smaller font, because the current window size is 960x780 with bigger fonts. I want to support less than 800x600 resolution. I already made smaller fonts and backgrounds for them, but still need to adjust source code. I just can't do it today.

More bugs, part 2

Fixed those four bugs, but found two more. And need to adjust two features. Now it's mainly playtesting, I don't have to add any major features. Playtesting is getting a little boring, maybe it's because Teemu is such a simple game. To avoid dullness you need more variations in monsters and items, which Teemu doesn't provide at the moment.

More bugs

Fixed light source problems, but found four bugs. They should be easy to fix. There are many things I would want to add in this release, but I have to get this ready soon. Oh, another thing, I got my old job back and it starts next week. Bugger! Good thing is that I get more money to buy guitar gear, but it takes some energy and time away from roguelike programming. Anyway, I'm going to set up gcc development environment at work so I can do some development while at work. It works pretty well, because my job is often projects I have to do in certain time limit and then I have some spare time to use.

Bugs fixed

All open bugs are now fixed in Teemu. Feels nice, but I'm sure there are more bugs to find when I playtest the game. What comes to features I really want to add size for objects, because it will hopefully make damage model more complicated and add variation to monsters, and it should improve balance issues.

Bug hunting

Some bugs are harder to fix, because they are more like features that  need checking in many places to work correctly. There are seven open bugs, but I guess I will find more during the playtesting. I just heard that I might get a job, like actual real life job. It's annoying. Why this has to happen now, when I'm finishing this project?

Playtesting

The gameplay of Teemu v1.1 is now ready for testing. Should be possible to win the game again. I have playtested it a bit and noticed that cave bats are maybe too powerful. The reason for that is the damage model where damage is taken only from the damage type. That means every monster using bite (like bats) attack take exactly same amount of damage. To fix that I'm planning to add size for all objects and make small enemies do less damage.

I don't know what extra features I will include before the release. It's like that, if you add something it will delay the release for days, even weeks. I don't have to include all planned features for this release, they can wait to v1.2.

Nostalgic moment

Went through my old floppy disk collection. Two boxes of Atari ST and one for PC disks. It was around 1990 when I got Atari ST so it's 20 years of bullshit with computers (well, I had MSX earlier). It's a long time, feels even more than it is. On two ST disks was word "Hack". I guess that means Hack the roguelike game. I think it was made for ST too. I don't think I liked roguelikes back then.

It's a funny thing wanting to go back in time and change something. Things would just have been different then, but better? Who knows.

ARRP: Teemu 1.1

As the Annual Roguelike Release Party (ARRP) is getting dangerously closer, I'm announcing that Teemu 1.1 will be one of the ARRP roguelikes. There should be plenty of time to program all missing features and maybe even try to figure out couple of new ones. Maybe I should make something every day and take that as leading motivation. I think ARRP makes a lot more sense than 7DRL, because there is no hurry, but at the same time you know others are trying to beat you and create something clever. It's not going to be that easy now, when Teemu v1.1 is announced.

It's on.

Icons

Stile: Keyboard commands work again. I missed the fact that you need to & modifier keys to get proper result. Now I'm refactoring icons, because commands are related to them. Before refactoring icons shared common order with commands, but it's not very cool. You need to keep commands in certain order to synchronize with icons and it's not good design. Now Icons have their own id and related data for command id. It's possible to create icons that have different command even if the icon looks the same and it could be useful in other places (in map editor for instance).

The class design of Stile is interesting, because I feel I'm facing classic problems with class design and ownership issues. I don't know any of that shit, but I'm slowly getting better. I guess.

Wasting my time

Writing some totally unimportant refactoring to Stile. I try to improve Stile's source code structure, but it's taking its time. The command structure is now data-driven which means each command is listed and given a keyboard shortcut (if defined) and after two days of work I can't get the keyboard to respond to the data. I don't know what is the problem, because I have very similar kind of system in Kaduria already working like a charm. Well, something is different I guess! The work I'm putting in Stile feels like great waste of time, but what the heck.. it's all about wasting. Nothing I have done in game development has had any meaningful results, so why not continue that way while I'm at it.

Firefly stories

Finally after days of programming the lighting routine is almost done. I'm in level theme five and it's going to be faster to finish level themes now that lighting is there. I think it could be nice to "hide" in darkness. When you go in dark area monsters could not see you.

Throwing items has become unstable and there are now nine known bugs which is a lot compared to two known bugs in the previous version. The more I work on this project the less I want to release the source code, but a promise is a promise.

The engine strikes back

I'm progressing in third level theme of Teemu. I needed something new for items: duration and a flag telling if the item is active. Adding something like this in object class is very easy, but when your engine doesn't support them it's time for good old refactoring.

The problem in this case was that items in inventory are not real objects. When you pick up an item it becomes just an int variable in inventory list, and is then re-created when you toss it back in the gameworld. This all changes when you have things like duration to store. You could, in theory, refactor inventory so that it has the copy of object's duration. In fact there is one that kind of variable already: the amount of items. However the amount is something that can be controlled quite easily. Duration is different story, because it's natively controlled inside the object class. So, in order to proceed in level theme three I have to refactor inventory to store objects instead of ints.

While I'm at it, I could unify the inventory and new tool inventory with one base solution. The inventory was kind of braindead from the beginning, but I think it was the fastest way to produce something playable. I blame the old school roguelike programming now biting me on the leg like a grid bug.

Teemu progress report

I think the "engine" is ready enough for action. I have been adjusting level themes (one at a time) for new game content and so far it looks good. There are themes that require more work, but some themes are ready to go. It's needless to say, but this version is far from ready. It could be interesting if someone is willing to continue the development of the official Teemu after I have released the source code, but I'm not expecting too much from that (developer people always have their own main projects). I will continue the development some day, but there is one small thing preventing me to do that right after the release: Kaduria.

Darkness

Some levels of Teemu are now dark. The lighting routine is simple and I want to keep it that way to get v1.1 released as soon as possible. Player's light has FOV (which is the main fov routine) but other lights are just plotted over the light map without checking walls for visibility.

As I mentioned earlier the source code of Teemu is not going to be too spectacular. Some parts are "traditional" straightforward programming, but I believe there are also good parts. I have cleaned the source code however, like removing functions that are not used in this particular project. There were quite a lot of that stuff, because some classes were borrowed from Kaduria and Stile.

I feel good about this, while couple of months ago I didn't believe I could finish v1.1 any time soon.

Teemu v1.1 in two weeks

Left Kaduria for a while and continued Teemu's next version. I'm also kind of polishing the source code for release. I got the idea when struggling with the horrible source code of BRogue. The source code of Teemu is not perfect, it's like a fusion of old school procedural and "modern" data-driven approach, but I think it could give some ideas how to use OOP in light weight manner. I think OOP is easy to learn, but hard to master. You can go crazy with it for no good reason and that's why some people don't like it.

There is only one source code level refactoring to do which is terrain code, but then I also have to add the new content I was planning to do for v1.1 and it's not going to happen fast, but I think it could be done in two weeks, or months...