Rogue Hut

Framework classes

2012-01-26T03:13:00.000-08:00

There are now 15 classes in the framework. Still, I want to extend the framework to higher level classes. Some of my goals are GUI itself and a generic Message class to output roguelike style messages. The current one in Kaduria is a real mess, it's very big and confusing so I have to think hard to create a better one.

This is the current list of classes and enums. Tar_Ball is a serialization class with binary/text data format. I'm quite proud of it actually. One of the problems I have to tackle is how class instances should be created. This far instances like Keyboard and Random_Generator are global, because there is only need for a single instance. It's not modular, but I don't know a better solution. Although Random_Generator could have several instances in classes where random numbers are needed, but the seeding should then happen somewhere else. Classes that are global usually can't be used as local instances, because they load stuff or are otherwise heavy to initialize.

Framework

2012-01-23T05:16:00.000-08:00

Thought it would be a good idea to create a generic framework for the next project which is that 7DRL I was talking about in the previous entry. I have programmed some modular classes during these years which I have used in my projects. You can view some of them in Teemu's source code, especially in 'classes' subdirectory. What I want to do is make them even better and for that I'm using GCC which is more anal about purity of C++. I will also compile the code with Visual C++, because it's my main development tool.

Building a framework or a library of useful generic classes is wise. It reduces the amount of time spent in setup of a new project and improves code quality since usually those classes have experienced a good amount of testing. What I also would like to achieve is a number of higher level classes that could be used as a base for each new project. For example this far each GUI class has been specific for that project, but I'm hoping to create a generic GUI class which then can be extended with new features.

Plans for the next 7DRL

2012-01-21T01:03:00.000-08:00

I have an idea that could be implemented as 7DRL. While working on Kaduria (and Teemu) I have possibly started to think that a tile should own everything it has. In practice this means that each tile should have container list for items, flags for different stuff etc. For some people this is the way to do things anyway, but it's new to me, because this far a map has been just a collection of tiles, a simple 2D matrix. But when you think a tile as an object that can hold and own stuff it begins to look more and more a good idea. It makes many things easier, but could possibly make others harder.

Another thing I want to try is game objects without inheritance. Just one class for all game object types. It should be easier to do now when I have more knowledge about data-driven style.

If the "tile based" approach works really well there may be a brief refactoring session in Kaduria...

Skyward Sword

2011-11-19T02:07:00.001-08:00

The european release day was yesterday and of course I had pre-ordered Zelda: Skyward Sword like three months earlier. I'm not a die hard fan of Zelda series, but I do have a habit of getting new Zelda. My initial reaction was disappointment. Really, they took Ocarina's engine and added some kind of DOF filter to it. It's just like old days: moving around is dangerous, because Link shoots from 0 to 100 in 0.01 seconds. Even the camera sucks like it did in Ocarina of Time. Characters consists of like 20 polygons. All this in 2011. I guess some people like retro, but I'm not one of them.

Then there is the old school game design like dialogs you can't skip and it's typed one letter at a time, slowly. People talk a lot and they repeat their bullshit a lot. I could live with retro graphics, but game design like this. Fuck.

So is there anything good in this game? Well the animation of the sword is impressive. You can feel the weight of the sword. Handling the sword is cool in places where you have to cut stuff, but I haven't yet learned to use the sword in combat. I'm just swinging around like mad. Maybe it's just me. I also like the stamina meter, even it's just a small detail. It makes things like hanging on the ledge much more interesting and "realistic".

After a well slept night my anger has settled and I feel that I can play this game. There are small positive things like level design and maybe even character design (those funny characters) that makes it worth it to take beating from the poor aspects of this game.

Teemu continues again

2011-11-17T09:27:00.001-08:00

My new plan is complete Teemu 1.3 before 2012. It gives me something to focus on and it's something I can finish in relatively short time, since Kaduria is not going anywhere soon. Some planned features of Teemu 1.3 will be removed from the to do list for 1.3, but not the important ones.

Filco Tenkeyless has been working great, no bugs or whatever. Now I don't understand how I was able to use keyboards like Labtec Ultra Flat. I guess it's difficult to spot if something is wrong with the keyboard. It's possible to write with any kind of keyboard, but writing with Filco is just easier.

Filco Majestouch 2 Tenkeyless

2011-10-16T06:48:00.000-07:00

It's a new keyboard day. I don't know how long this model has been available, but it's without keypad section and it's Fin/Swe layout. It was 130 euros and the keypad (also Filco) 60 euros so it was quite an investment. However I feel now that getting tenkeyless version was really good idea. It's narrow without sacrificing the standard keytronic layout. Narrow is good, because then the mouse is closer to the body and your arm doesn't twist that much to the side. When you work with computer like I do things like this matter.

After so many years of tightly packed keyboard layouts I keep hitting Ctrl when I try to press left arrow and also I noticed that I press + from the keypad which isn't there anymore so I need to learn press it from the keyboard. This model is "brown cherry" (tactile). It's doesn't produce a clicking sound like blue one, but it does sound like "clank" when you press the key all the way down. It could be described as more noisy than a regular keyboard, but it's not too noisy.

The quality is an interesting question, because it doesn't really feel a lot different than old keytronics. But I guess keytronics were good. Keys are tall and wobbly, but easy to press down. The keyboard is small, but it's quite heavy and with those feet thingies extended it stays in the place and doesn't move even when typing hard.

Funny enough, I've run into one "bug". It happened when I was programming: suddenly the keyboard flushed about 30 space bars or so, like there was some kind of buffer problem. I think it might have something to do with the USB->PS/2 adapter which doesn't fit tightly in the slot. I haven't been able to reproduce that bug, but even if it does happen again I don't have the heart to complain. These guys are serious about giving great alternatives to your typical keyboards with these kind of special models.

I didn't even know how much I did miss the standard layout and feel of tall keys. Now it's time to kick ass with this keyboard and get some programming done.

Random thoughts

2011-10-01T01:12:00.000-07:00

Working with Level class I've managed to narrow down from 21 functions to 15 in two days. The biggest issue with Level is how to determine what objects (mainly creature and item types) are created in a level of some theme. Previously I had static lists, but that's not very clever and it tends to create quite similar levels what comes to objects.

An idea I had with creatures is give each creature a difficulty point. That would allow to set a max level for each level theme and create monsters to that limit by determining how many difficulty points are used. If you create a harder monster you get less monsters. That way a balance in difficulty is maintained. Need also some kind of way to determine where the monster wants to be usually. It should be just a generic rule to allow most of the creatures to created everywhere, excluding quest creatures.

There are still special set of objects created in some level themes, but I've tried to keep that number low. One of the main goals in this version is increase the randomness which is pushing Teemu towards the realm of a roguelike game.

Engine thoughts

2011-09-22T00:18:00.000-07:00

When I was looking at Teemu's current structure and the increasing number of data-driven classes I realized that I was going in the same direction as with Kaduria: trying to create a better more flexible engine. It's not a bad thing if you are looking for that kind of way, but it got me thinking. Do I really want to go that way again? Maybe not! It could be just better use not-so-perfect source code to produce the result I want.

Well it doesn't mean there is something wrong with the code quality. Nope. My goal with Teemu and all other projects is zero bug quality. It's just less engine and more "hacks" which means something like checking the player id in Creature class and choosing different action based on that, or checking visibility of actions in different ways to show different messages. In other words not using one core solution for all problems. For me it means "breaking" the engine, for some people it may be the usual way to do things.

Fighting

2011-09-18T01:56:00.000-07:00

In effort to organize the source code better I wrote a new data type class for combat results. It's getting to the micromanaging department but somehow I like this way of doing things. I developed that style during programming Kaduria and while it's very anal to say at least it's giving nice results in the long run.

I don't have any good estimation when the next version of Teemu will be released, but there is not really that much stuff to do. TEROS (TEemu ROleplaying System), couple of new locations and when the engine has support for data-driven objects it's time to add some new items, monsters, etc. The last feature depends only from the engine support and there are just couple of things to do in that area, namely adding support for dynamic object creation (object types are not in a static list but generated from the data by determining which objects are suitable to create in various locations).

Refining TEROS

2011-09-16T03:50:00.000-07:00

Now all stats are in T_Stat class so it's time to continue developing TEROS. I actually refined it in the plan, not in the source code. It looks like it's ready to kick coconuts. I changed weapon accuracy to more generic attack type accuracy and added a modifier for dodging an attack. This is what creatures do at the moment, but it's not very well defined.

I was thinking of extending creature AI by allowing some player operations for NPCs but then I realized it's better forget that for now. It's wiser to implement a couple of selected features and then look where it went. And as a bonus you get to release a playable version which then could generate feedback in theory.

New stat class

2011-09-15T04:18:00.000-07:00

Stats have now a class that handles everything they need. It'll replace old stats that each had dedicated routines to handle them. I've already replaced hit points. It was easy, but blood alcohol content may need some special code, because it has a counter value.

This is just refactoring, but it's needed for TEROS. Stat class will also remove duplicate style code and makes it easier to avoid bugs that way.

I try to keep TEROS as simple as possible. It's only adding weapon and basic attack power plus stamina points which affect attack points in simple and easy to understand way. Stamina will recover like HP in most role-playing games while hit points are recovered by drinking alcohol as always.

Teemu continues

2011-09-13T06:58:00.000-07:00

I'm now ready to return to Teemu. I have a plan similar as in Kaduria to concentrate on Creature class and close routines in VC when it's done. It's interesting how much uncertain code I have already found to fix. Things like returning zero as magic number etc. Stuff like that is not good if you try to reach zero bug program. It's one of my goals with Teemu to create a game that has no bugs at all.

Working with Teemu is easier than Kaduria, because the engine is quite simple. I'm still trying to think the best way to implement Teemu's role-playing system TEROS with APEWASH stat set. I think it will reveal itself as I'm refactoring the Creature class, because that's where the obvious changes are going to happen.

Resizing algorithms

2011-08-02T04:44:00.000-07:00

I'm doing some research in trying to replace the current bilinear resize with something more intelligent. Since I'm hopelessly bad at math I don't think there is going to be any really cool solutions like vector transformation. I have started by implementing scale2x and it could be the basis of the final routine. Or not. The good thing about resizing is that it's quite logical and easy to understand. You need to figure out how to translate the information to bigger or smaller size without losing the form of the original.

With tile/sprite editors there is a special need to maintain the original pixel's color which means interpolation routines are giving somewhat poor results. Developing a really good resizing routine is difficult, but an interesting subject.

Brick Atelier 0.84

2011-07-30T00:23:00.000-07:00

http://koti.mbnet.fi/paulkp/brick/brick.htm

New version available. Some bugs were fixed and it's actually faster than before, because I removed double updates in some drawing operations. It has one new major feature (append), but I think it's wise to make release versions sometimes. There was one Microsoft extension detected by GCC in the final compile. It looks like Microsoft has implemented pop_back in std::string which I guess(?) is a non-standard feature. That was replaced with s.erase(s.size()-1); which I think does the same thing.

Now when append is ready I "have" to return in Kaduria and just try to bash my head against its cold, unforgiving dungeon walls.

Brick Atelier news

2011-07-24T09:34:00.000-07:00

The first version of tile append is finally ready. At first it felt like bit difficult feature to implement, but once I got all the pieces together it was easier than I thought. I'm already dreaming of a custom file dialog that would remove the only Windows only section of code from Brick Atelier, but I guess it's also pretty difficult to program.

New version of Brick Atelier is going to be released soon. Not that anyone is really interested, but for me it's nice: at least something is happening. With append there is a re-designed dialog system with consistent style. Some parts (like map editor) are not using it, but they also will be using it later.

Victory

2011-07-18T01:15:00.000-07:00

Went down some three stairs in a dungeon. Couldn't capture the full error message, because copy-pasting it to Notepad crashed Notepad itself! But I got this:

It looks like JADE has lots of issues, but what the heck, I'm playing it anyway. It's interesting to follow the development of this game.

Bad news

2011-07-11T04:45:00.000-07:00

I guess they are bad. Teemu is now in ice, I will possibly continue it when Kaduria's first playable version is ready. There is a lot of stuff to add in Teemu, but I just can't concentrate on two major projects at the same time. I even have difficulties to add some features in Brick Atelier I need in the development of Kaduria (tile append to be exact).

I think Teemu doesn't need that much work and maybe if I keep a distance it will be easier to return and finish the job.

Other bad news is that I'm expecting some problems in my personal life... it may reflect to game development. No, I'm not getting married, that's the worst mistake any roguelike developer can do. I'm just having problems with everyday life, which is supposed to be easy.

JADE released

2011-07-02T11:14:00.000-07:00

I was disappointed when I saw JADE 0.1.0. I can understand the lack of content, but the engine just doesn't seem to have that next gen roguelike feel. JADE is like ADOM with bigger world map. Fan boys seem to be happy though. I was looking for something more, like ideas to borrow. It's just starting to look like I am the only one with actual new ideas for roguelikes. So all that bragging I've done (not that seriously) can actually become true and Kaduria will simply destroy all previous roguelikes. Well I guess Stone Soup is pretty cool, but I haven't really played it much since I always die in the first or second level.

Omega source code

2011-06-22T01:11:00.000-07:00

I find old roguelike source codes interesting, because I started from C-style myself and then went to C++ which is in many ways better than C and that's stating the obvious. Back then however C++ didn't even exist or it was new to people. In a way it still is today and some people are unaware of its benefits.

Still, there is something great in those old C source codes. It's the way authors forced the game to emerge from that chaos. Despite of number of dangers from using raw arrays and global data. Whereas today authors are much more engine-oriented like myself. However engines are bad as games and sometimes writing a game engine can take surprisingly long time.

That in mind I have really changed my strategy especially in Kaduria and it seems to work. I no longer try to create a "perfect" engine but try to look at how to implement features as fast as possible, while trying to use the game engine's building blocks in the process.

Troll Slayer

2011-05-28T02:03:00.000-07:00

I was looking for some small side project to relax between coding sessions of Kaduria. I found Troll Slayer. It was promising (and I guess still is) 7DRL with nice tiles. However the source code is quite difficult to work with. It's taken from some previous project so there are lots of commented out code. Not to mention that the code is pretty messy. I was almost close to abandon the project, but looks like it's something to improve during a long period of time...

At the moment I'm writing a BMP importer for Brick Atelier so I can load Troll Slayer's tiles and start to make them better. It's not a simple task however, because I'm re-writing the dialog class for more consistent style (like all dialogs should have at least Ok button) and also adding a support for viewing the BMP image and also selecting tile areas from it to import.

Meanwhile the development of both Teemu and Kaduria are stopped for a while I guess. Well, at least I'm doing something.

MyWinLocker adventure

2011-05-11T01:46:00.000-07:00

Acer was pre-installed with MyWinLocker, a totally useless piece of crap software. Control panel's remove program did not work with either settings (checking/unchecking) and when check the MyWinLocker suite entry was removed, leaving the program still there. I tried to download and run the "tool" from Egistec site, but nothing happened. Well, fuck this. Let's go hardcore. You wanted it, you got it.

1. De-activated all processes related to Egistec.
2. With CCleaner deleted entries in startup
3. Deleted all Egistec folders from Program Files (x86), well the IPS or whatever refused to be deleted so a restart was needed
4. Deleted the remaining IPS folder
5. Deleted start menu folder of Egistec
6. CCleaner windows registry clean up
7. Re-started and hoped that nothing important was broken (while thinking of removing the entire Windows and becoming a Linux user)

Well, I think that was good enough. The program doesn't start and the files don't exist. There could be entries in the registry, but that's ok.

Brick Atelier 0.83 released

2011-04-18T10:13:00.000-07:00

Download link:

http://koti.mbnet.fi/paulkp/brick/brick.htm

Brick Atelier news

2011-04-16T10:00:00.000-07:00

It's almost ready for release. I still have to solve the editor pixel size problem, but I guess it's going to be quite easy to limit the max size of editor pixel when the tile size is getting too big.

This is the current development version. As you can see there are some changes made. The UI, while still trying to fit everything in one screen, is less crowded. I also spread the information about tile id which is now in bottom left next to the tile strip and there is now a new information screen that shows things like location and color values. I'm planning to move the brush icons at the left side of palette area, where that empty space is. Then the vast empty area is reserved for the editor tile and 2x2 real size tile, tile copy and clone brush.

Grid intensity

2011-04-11T02:20:00.000-07:00

There is a grid intensity value in Brick Atelier. It's of course cooler than regular grids, because it's using the current pixel's color and darkening it. I wanted to add an adjusting option for the intensity, but the current dialog system was unable to handle that kind of adjusting. It was the way dialogs were constructed, using values and buttons as pairs. Buttons were linked to the dialog in Dialog_Set class. But then I realized that with more complex dialog items it was kind of difficult to set the locations of buttons.

I refactored the dialog system by adding buttons in the individual Dialog_Item class (a Dialog_Set is a list of Dialog_Items). Now, I hope, it's easier to add different dialog types. Refactoring this one was hard, and easy. Easy in a way that I have learned to write modular code and I only needed to change Dialog_Set and Dialog_Item classes. Everything else like setting up the dialogs and processing them didn't need any changes. That's the bonus you get from writing good public interfaces.

7DRL failure report

2011-03-13T01:19:00.000-08:00

I made some stuff for Teemu 1.3 and the week started nicely, but then I was distracted by setting up a DAW for music making. From the demos I tried I liked Ableton and actually found a Lite version from my M-Audio keyboard package. So it didn't even cost me anything. There is a hard limit of 8 max tracks (or instruments) but if you keep things simple it might be enough.

I think I'm going to continue with Teemu, because it was a good start towards version 1.3.

The player

2011-03-08T02:12:00.000-08:00

I'm in process of rewriting some stuff in Teemu's data-driven engine. The big question is how Creature and Player classes are organized. This far I've made "quick hack" solutions and wrote some checks inside the Creature class for the player. It makes some routines player only and it's bad from data-driven point of view. So I'm trying to rewrite those routines. Let's get an example. When someone throws something at enemy there is no way to determine who threw the item so it's always the player. There is a also a chain of routines leading to Level class without any way to determine the thrower.

The strict way to do shit is make Creature class routines generic enough so they can be used by the player and other creatures without any kind of special checks. Then use virtual routines to override Creature routines when the player needs something special. This is what I need to do now to prepare creatures for more sophisticated AI routines.

The pirate week

2011-03-04T04:05:00.000-08:00

7DRL starts tomorrow. I'm probably going to participate with the next version of Teemu which I know will not be done in one week. But let's give it a try. I'm stuck in Kaduria (as well) so it's nice to switch project for some time.

The task of creating a custom role-playing system for Teemu doesn't look that difficult, but I guess it is. It's mostly the balancing and how to balance stuff with... other stuff, mainly weapons and armour. I have a cool idea about how to use armour, but no idea how it will actually work.

The second thing is trying to create a data-driven engine for all object types so you can like create new items and touch only the item type data and class. That way I could add insane amount of object types and surprise everyone with a new major roguelike.

Teros

2011-01-14T09:42:00.000-08:00

Solved the problem with scrolling and offset, for most parts anyway. Now I'm trying to figure out how to implement the game system I planned before. The biggest problem is how to determine the values for each creature. It matters because with clever planning it's possible to determine some values from simpler data, such as the main type of the creature. If something goes wrong it's annoying to fix data. I'm not even sure about the game system itself. I need to write a simulator for it to check out what kind of values it will spew out.

Planning a role-playing system, even a simple one, is not an easy task. You need to get stuff right to give meaningful values for different types of creatures and also items that are involved in combat. Teros will be the hardest thing to implement for 1.3, but it will bring more role-playing feel in the gameplay.

Plans for 2011

2011-01-06T06:05:00.000-08:00

I've decided to leave Kaduria for a while and concentrate on Teemu 1.3. I have also started to plan a new game project that is not a role-playing game. I got a really nice idea and the least I can do is plan as much as possible.

Last week has been hard, because I got a strangely difficult flu. This is something different than your average flu. Even my eyes were inflammated and swollen. I went to a doctor and my inflammation levels were too high for normal flu so I got antibiotics, but I'm not sure if they helped a lot.

If I was to die in this illness I want to say it has been nice to be a part of roguelike community, even I consider myself a rogue part of it. We come from different cultures and religions, to face an intellectual task of creating a roguelike. I think the humanity needs more of these tasks where we can all join our forces instead of killing each other. We need to compete in knowledge, not in the amount of weapons.

Terrain decorations

2010-11-11T00:17:00.000-08:00

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

2010-11-09T04:30:00.000-08:00

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

Scrolling gameview

2010-11-05T05:38:00.000-07:00

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

2010-10-28T01:36:00.000-07:00

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

2010-10-27T03:25:00.000-07:00

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

2010-10-26T00:23:00.000-07:00

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

2010-10-25T00:16:00.000-07:00

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

2010-10-22T04:26:00.000-07:00

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

2010-10-21T00:14:00.000-07:00

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

2010-10-20T02:38:00.000-07:00

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

2010-10-17T23:26:00.000-07:00

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

2010-10-14T04:12:00.000-07:00

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

2010-10-07T02:18:00.000-07:00

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

2010-10-04T03:24:00.000-07:00

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

2010-09-29T00:10:00.000-07:00

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

2010-09-24T03:54:00.000-07:00

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

2010-09-23T04:08:00.000-07:00

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

2010-09-22T22:27:00.000-07:00

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.

Visual C++ Express 2010

2010-09-18T01:36:00.000-07:00

I developed Kaduria with VC2005 and one of the first thing was to get VC Express for my new computer. Installing was not a problem, but then I hit the brick wall. You need to register VC in 30 days, but the validation e-mail is blocked by mbnet, my e-mail provider. There is no junk mail folder to check junk mail. Fuck this shit. I sent an e-mail to microsoft and hopefully the answer is not blocked. Maybe I could re-register to Windows Live ID (something that was required for registering VC) by creating an account to hotmail as was suggested.

Have you seen the movie Brazil by Terry Gilliam? Somehow this mess gives me same kind of vibes. When you look at M$ support pages they don't make any kind of sense. Just loads of text and options ("was this helpful?" Fuck no.). Why the fuck do you need to register a free program? To get junk mail from M$? If there only was an option for Visual C++ but nothing comes even close. Fuck you open source developers. You should be ashamed for not being able to produce as good or even better than Visual C++.

Teemu v1.2 released

2010-08-29T12:06:00.000-07:00

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

2010-08-29T03:40:00.000-07:00

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

2010-08-28T02:04:00.000-07:00

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

2010-08-27T03:52:00.000-07:00

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

2010-08-24T23:00:00.000-07:00

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

2010-08-23T04:08:00.000-07:00

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

2010-08-19T23:50:00.000-07:00

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

2010-08-17T04:22:00.000-07:00

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

2010-08-06T02:19:00.000-07:00

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.

Happy joy

2010-08-02T23:56:00.000-07:00

I'm almost happy when I soon get to try if new door class in Teemu is actually working. It's joyous to see that the door opens when you open it, and closes when you close it. What could be more fun? And you know it's a game object, not just a terrain tile.

I have "solved" the object map vs. list -problem by using a simple base class map for quick collision test and when the actual derived object handle is needed then just go through a std::list to find it. I guess map/multiset/hash/crack/whatever could be cleaner and faster solution, but I don't know how to use them and/or I don't have enough intelligence to understand how they actually work.

I really don't know if I can finish Teemu v1.2 before ARRP, but it doesn't look that good. Making new object types and creating a common interface for abstract base class is kind of time consuming job, but I think once I get it running it's easyish to add more object types.

Open door

2010-07-23T01:54:00.000-07:00

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?

2010-07-21T23:47:00.000-07:00

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

2010-07-15T23:36:00.000-07:00

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

2010-07-13T00:15:00.000-07:00

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

2010-07-12T02:43:00.000-07:00

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

2010-07-01T23:52:00.000-07:00

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

2010-06-17T04:36:00.000-07:00

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

2010-06-14T23:40:00.000-07:00

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

2010-06-14T00:09:00.000-07:00

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

2010-06-03T03:29:00.000-07:00

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

2010-06-02T00:15:00.000-07:00

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

2010-05-24T11:13:00.000-07:00

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

2010-05-21T23:11:00.000-07:00

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

2010-05-14T02:53:00.000-07:00

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

2010-05-13T04:29:00.000-07:00

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

2010-05-12T23:52:00.000-07:00

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

2010-05-12T13:13:00.000-07:00

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

2010-05-11T06:03:00.000-07:00

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

2010-05-10T04:25:00.000-07:00

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

2010-05-08T02:07:00.000-07:00

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

2010-05-05T03:27:00.000-07:00

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

2010-05-03T12:48:00.000-07:00

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

2010-04-18T06:58:00.000-07:00

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

2010-03-30T10:17:00.000-07:00

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

2010-03-20T09:11:00.000-07:00

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

2010-03-19T10:16:00.000-07:00

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

2010-02-12T03:39:00.000-08:00

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

2010-02-06T01:24:00.000-08:00

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

2010-02-05T09:56:00.000-08:00

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

2010-01-31T03:52:00.000-08:00

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

2010-01-24T03:16:00.000-08:00

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...

Sleepless nights

2009-12-02T15:53:00.000-08:00

I've had problem with sleeping since I was kicked out from job, but I think it's something that happens when you don't have to get up early. Now I'm going to sleep at 2-3:00. It's beginning to look like I'm able to work at night, while back some time I was too tired to do anything but stay awake.

I'm going to start game testing of Teemu by going through each level theme and see if I can survive them. I guess I need to forget about really big adjustments to the game engine, just to get the actual game released before 2010. That's what I'm planning anyway.

It begins to look like the backlight bleed problem of my Fujitsu laptop is a part of bigger conspiracy (yeah, a real one!) of leds causing it all and they just sell that shit to people. It's my typical luck to get my first laptop just when they started to manufacture led backlight screens. Of course the bullshitting must come to an end, but before that a lot of people have lost their money and will never get it back.

New cave theme

2009-11-12T09:52:00.000-08:00

Re-designed the cave theme. It's now much cleaner with new cavern carving routine mixed with occasional rectangular rooms and small rooms that are attached to free places after the main generation is done. Here is a result:

The nice thing about rooms is that I can later add room themes randomly, something like treasure rooms or rooms full of monsters.

Bugs

2009-11-11T03:33:00.001-08:00

I've found five bugs from Teemu since release of v1.0. Four of them are fixed. Here is the one I have to fix:

Some of the areas are not connected and some items and monsters are created in them. I made sure that stairs are always generated in the origin point of room so it's pretty much the center of it and those points are always connected in other points with corridors so stairs never get created in detached pieces, but I should still fix them. It should be easy.

Tweaking the engine

2009-11-09T08:22:00.000-08:00

I've got the plan for Teemu v1.1 pretty much figured out. There may be some extra things that I want to add, but they are not important for the main "plot" of the game. I'm actually quite optimistic this time, because I have done some changes to the engine that makes it more data-driven. It's very similar to the way I'm refactoring Kaduria.

Besides now I have a testing tool that re-generates the level when I press [r]. I didn't have a working one in v1.0 which made the testing of level generation quite challenging. I had to exit the game and restart it to try it again. Now I can make quick changes and test it really good to see if there is any problems.

It's obvious that even a small and relatively simple game is easier to maintain with data-driven approach, even if it's just some parts of the source code that actually are data-driven.

The best country in the world

2009-11-03T02:07:00.000-08:00

Finland is the best country in the world this year, according to Legatum study. This made me laugh for a moment (yes, I'm finnish), but then I realized those wacks can very well be right. We are so hopeless as a species that Finland is the best we can do. It's kind of depressing.

Even we are the best there is still many things we could do better. We have certain amount of corruption, but we don't like to call it corruption. We even have homeless people and a shitload of unemployed people. Finland is also a very expensive country to live in.

The good thing about Finland is that we are pretty decent people. We like to do things right and work hard. But we too are in the pressure of globalization and we really are the most vulnerable to that. If we can't stop the flow of criminal foreigners to our country everything will be lost in 50 years. Their genes are lesser. I hate to say that, but what can I do? It's their fault of being stupid apes compared to us.

Maybe this was not yet the time to progress from apes to real intelligent human beings like us. We need more time for others to evolve in the same level where we are now.

Stile 0.79 released

2009-08-21T00:11:00.000-07:00

Download it here:
http://koti.mbnet.fi/paulkp/stile/stile.htm

File dialog trouble

2009-08-20T10:02:00.000-07:00

What happened was that Windows file dialog collided with SDL_syswm.h which defines WIN32_LEAN_AND_MEAN. I think the best solution for now is create another file for file dialog only, but I really need to get rid of windows file dialog. It should not be used in SDL program, but I can't think of any alternative solutions right now. I really hate gui libraries that are gigantic and most of gui libraries are just like that. Besides I like to work with Stile's gui, because it's making everything possible and not making the program too slow.

Fixed name clash with 'pixel' and also made working RGB handles. It required almost total rewriting of Color_Handles class, but I'm glad I did it. The only problem is HSV bug that is fetching the base color value from HSV selector area, when I think it should take it from current tool color.

---

The solution for collision was easier than I thought. Just switch the places of windows. h and SDL_syswm.h.

Trouble with Teemu

2009-05-22T05:42:00.000-07:00

After 1.0 release I really haven't been that interested to code Teemu. I'm busy with Agduria (and Kaduria) and it may well be possible that Agduria will be playable game sooner than Teemu 1.1. Maybe I added too many features in Teemu 1.1 and going through the to do list isn't fun. Also I feel that I said what I wanted to say with Teemu: that I'm capable of programming a complete game, no matter how simple it is. Not that it's really that important, but I began to get annoyed about jokes related to Kaduria.

Besides it was true what many people said about a smaller side project. It's a great way to improve programming and game design skills and also create solutions that can be used in other projects. As games "7DRL" or small roguelikes can't compete with major ones, that is certain, but they provide good practice for programmers, if there was no previous experience of that kind of stuff.

Teemu update

2009-04-17T02:06:00.000-07:00

It's too slow to program Teemu @ work so I'm taking it back to home. Besides DevC++ is worse than VC and when the project is getting bigger it's clumsy to browse it with DevC++. Plus you don't always have time to program at work, because some people keep telling you should do some things, you know, work stuff. That's breaking my concentration always when that happens.

I could probably concentrate on Teemu anyway, hack the 1.1 ready, release the source code and let other people take care of possible new versions.

Bug found

2008-12-25T10:45:00.000-08:00

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.

LambdaRogue 1.3

2008-12-15T06:20:00.000-08:00

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.