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.