Teemu continues again

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.

Random thoughts

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

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

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

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.

Teemu continues

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.

Victory

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

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.

Omega source code

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

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

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

Download link:

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

Brick Atelier news

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

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

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

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

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

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

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.