Year 2011

I was looking at my dev diary from summer to this point and there is surely an interesting trend for increasing amount of development. It's also showing in the new LOC chart (starting from summer):

LOC has increased "only" 2000 lines, but it's quality code! Most of the source code is already in place and only involves some adjusting. Not to mention removed code, there has been some of it also.

This December was actually the best month in development point of view. I was able to complete or almost complete several major classes and the work is now more and more focused on narrow set of classes which have the most difficult problems to solve (AI, item routines, advanced level generation, etc.).

Rebuilding gameview

Areas of the gameview are starting to update properly again. While refactoring I ran into something quite unexpected. The main stats were updated inside the stat class and signaled to GUI, but of course it was done for all creatures, not just the player. So, had to backtrack and create wrapper routines in creature class to adjust stats and check if the creature is the player, and only then signal GUI. It was easier than I thought so I made it in one run.

It looks like other parts are fine, although I have to add parts that weren't there in the first place: two explanation text slots and quick item slots that can be used with keys 1-7. Then I have to clean up some manual updates, especially check out calls to Redraw in the dungeon class.

GUI class ready

Another part of the source code is now as ready as it can be. I think the GUI class is looking pretty good now. I don't even hope for good looking graphics at this point, I'm happy that basic drawing functions are done. The gameview still can't update itself so it looks a mess and even messages aren't shown and need to check out n+1 things related to drawing functions, but I'm still happy that something was done and finished finally. It may not sound very exciting, but for me it surely is, having spent so much time on this project.

Next I'm going to concentrate on that gameview drawing. The gameview now has clearly set areas so it should be easy to check out them one by one.

GUI development

I was right about text updates, most of them work without update inside the Text class. GUI class is actually almost ready and it's doing the job properly for most of parts. The biggest problem is how to draw and update parts from different sources. They also probably need notification instead of direct update which would lead to multiple drawing operations per turn. The good thing is that a roguelike doesn't have that much GUI stuff.

Back about three or four weeks I injured my elbow. The doctor said, judging from x-ray images, that it's some kind of calcification resulted from a long period of inflammation. I guess it's probably right, because I've had tennis elbow for a long time now. The injure came in weight training of course and I think it was a disaster waiting to happen. So, it looks like my training days are over, at least until this is healed completely. I don't want to reach the point where I can't move my fingers anymore. That would suck.

The bright side is that I have more energy to spend on something else like roguelike development. It's going to be a positive thing for this project and I already feel I'm getting more results in shorter time.

Update on update

Rewriting GUI for update rectangles is going to be worse than I thought. There are manual updates in some wrong places, namely in text output routines and keyboard routines. It was quick and dirty way to implement some linked updates, but they were in wrong place. Things like that should be there, but they belong to GUI. Text update is silly, because text is usually printed on some self-updating surface like window or gui background graphics. That's why there are double updates in most text routines.

It's more complete rewrite than I thought, but essential for that consistent flow of drawing and updating.

Update rectangles

Gameview is also being re-designed for consistent behavior in drawing and updating. The gameview is divided into rectangles which are updated only once during a turn when a flag is set for that area. It removes multiple updates and makes things both faster and also aware of what should be updated. Update rectangles are needed, because Kaduria is using only software output without any hardware acceleration. It's easier and more portable in the end, and I feel that a roguelike has no need for hardware routines.

I have also finished the structure of the gameview. It's going to have quick item icons for using items with keys 1-7, and status icons. Both of them will have explanation text when hovering over with mouse cursor. One thing I'm not sure about is the debug radar which is a small level map. I guess it could be visible in non-debug mode also, but it should be re-written to display only what the player has discovered.

Load and save game

Most of the classes know how to save and load, but the main routines are still under development. It's looking quite good actually and only some things need to be tweaked to make sure that there are empty versions of instances for loading saved data. Load/save can be difficult to program, but I'm now much more prepared for that task than I was before.

Debug routines... ready?

Yes. It appears so. I've finished debug routine module, it's as ready as it can be. Of course there could be some new routines needed, but it's only when I can figure out what they are.

It took only 15 years. And this is not a joke, it's a real number.

Hero coder

People keep calling me a hero coder (literal translation from finnish language). I guess it's some kind of joke, because sometimes I write comments about social media games like Minecraft and Angry Birds. Even writers of popular Pelit-magazine (biggest gaming magazine in Finland) make regular references to me. It's cute and flattering, but I don't care about that kind of thing a lot. You know, being a celebrity.

I think there has been misunderstandigs about my comments on social media games. I don't hate them or lucky developers who get zillions by taking advantage of the social media. They are game developers just like myself. Except that they own ridiculous amount of money and some of them wear a hat which attracts women.

The biggest misconception is that people think in their own terms like being jealous about money and girls. I don't get that. Game development is my hobby and I'm pretty devoted to it. It means I'm interested in game development itself, not money or girls. Being a roguelike developer means you are in the forefront of game developers. We don't just make games as products but in the next generation roguelike genre we make something new. It's a way no one has explored earlier. And that exactly is the reason I'm making games.

Some people measure success in money (or amout of girls) which means Minecraft is a great game. But if you were a game developer and look at Minecraft from developer's point of view, then it would not be that interesting. Still, as I stated before, I'm happy about the unexpected success of social media games or more like products. They just don't have a lot to do with hardcore game development which is a small sector of game genres living and surviving under the pressure of this commercial world.

Basics

Sometimes I feel really dumb, because I realize I'm programming some basics that should have been there way back. I'm still working on container code which is moving items from objects like barrel to inventory or somewhere else. It's a kind of feature you would suppose to be implemented in early stage, but somehow isn't.

I guess this is the case with some other features as well. Maybe there is no proper order to complete features. Then again I have spent a lot of time creating this simple turn-based RPG with random content and I'm still wondering how hard this could be? What is the problem with roguelikes anyway?

Secret idea

I got my ass kicked by the first temple's boss in Zelda Skyward Sword. And I had one revitalizing potion (restores four hearts). So they finally decided to make Zelda harder. Well, one of the strange things is that I don't know how to use the shield. Would it help in that battle anyway? Maybe I'm going to cry for two days and then look for Youtube videos about how to beat that son of a bitch.

While playing Zelda I got an idea. It must remain a secret however, because it's going to change one of the main areas of a roguelike. And what is a better project to use that idea than next gen roguelike.

Bug hunting

Today I fixed a special bug that made the program crash in Long Corridor level theme. It was a special one because there are no other known bugs that crash the program. The bug was relatively easy to find. In fact I was using VC debugger to find it. Usually I don't even need a debugger to find the bug, but in this case it was needed.

The number of open bugs is 12 which isn't that bad. I try to limit it under 10 to keep the game playable and as solid as possible. Some bugs are caused by parts of the code that are going to be refactored and usually the bug will be fixed at the same time. The current speed of development is quite fast and I believe it will produce an increasing number of bugs, but it's obvious that the release version will have zero known bugs.

Theme randomness

I'm having trouble trying to determine the stuff that will be generated in level themes. With lots of stuff it becomes more difficult to figure out how to select that stuff. There is a list of stuff to create for each level theme, but I know it's too restricted and predictable. Creating a list is easy, because you don't have to program a logic that "thinks" what could belong to that particular level theme. And that is exactly what I have to do next.

It's not an easy task. There must be a new type of classification of objects just for level creation. Then the level theme could ask an object from different kind of classes to generate in specific terrain area or climate condition or whatever the reason will be.

Level class

Returned to Level class. I have switched between big classes and browsed through them, fixing everything in sight. Level class is possibly the worst of them, because the dungeon generator still has some problems. It can't generate all level themes yet, but I'm working on it.

In some parts I have made a decision to settle for less great stuff to speed up development. Maybe I'm really looking forward to create a playable version, no matter what features it could be missing. Still, I'm pretty sure that the first playable version is not going to be a release version.

Item class part two

My tennis elbow got better really fast, it was just some kind of episode. It's still there, but not painful. Item class is almost ready for the parts that are already there. Something tells me there is going to be more code for items, but it looks surprisingly good now. I have lost my obsession to create "perfect" code (or engine) and just try to get stuff work. Well it isn't a surprise that things start to happen. However I'm as puzzled as ever when I think when or how this project is going to become a real game.

Item review

Giving Item class the same kind of check than Level and some others it was quickly obvious that it needs serious fixing. Many problems come from the unfinished role-playing system. It's really slowing down everything, because you can't write a routine if you don't know what it requires. But like with previous classes I have learned to look at the source code more closely and make better decisions.

Level class refactoring

Last three days have been quite productive. I have searched through Level class which is 3500+ lines of code. Many routines need either fixing or test how they actually work in the gameplay. I think the worst example was a routine searching for free places (when game objects are spawned). It doesn't work like it should, but when I change it data-driven it should fix most of the problems. I've also learned that everything should be check only once, because you will have extra rules and if that another routine doesn't check them it fails. There must be something like that because sometimes there are plants created on walls. It's bit of a mess, but it's going to get better soon.

Solutions

Going through Level class and closing functions when they look like they're ready. I think this is pretty good way to proceed especially when you get lost in the jungle of source code. The basic idea is find problems and try to find a solution for them even faster. When you program longer you start to understand what are the things that slow down development. I think there are only two things: 1) you did not find a solution for a problem and left the function/class unfinished and 2) bugs.

If it only were easy to fix all problems when you see them. But usually they are related to something else that needs to be done before you can continue. This is the difficulty in roguelike programming. With regular games you pretty much know what you need to add to make the game work like it should. With roguelikes you run into huge problems like artificial intelligence and the myriad of ways to interact with the game world. I hope my new style of programming brings some quick solutions.

Fighting style

There are some things missing in the process of constructing/creating a monster. Artificial intelligence type or AI type was quite easy to add. It was determined from the monster family and/or type of the monster. It's later used to make decisions about how the creature will act in certain situations.

Skills and default items are still missing. Some skills can be determined from the profession, but default item set is a problem. You could determine them from the profession and type of the monster, but instead of that I was thinking to add a new AI module fighting style. That way let's say a human fighter could have several styles with weapons and armour selected for that particular style. Not only items, but you can then determine combat strategy and also some additional starting skills from the style. Besides you need less fighting styles than there are professions and monster types.

Fighting styles need random variation in weapons and armour to prevent static item sets. It's going to be a complex system which is only telling how even one small area of roguelike is incredibly difficult to program. There is no easy way to do this, you need to create a number of styles with proper items, but still maintain random variation.

Monster review part two

After some research I found out that only 40 of 134 functions in Monster class are ok (possibly don't need refactoring). The rest is in less good condition. I have hidden ok functions with VC's gui so it's easier to get work done in unfinished functions. I can only guess that it's a difficult task, but this situation with unfinished code and gameplay content has been going on for too long. Something has to be done and I got a good start by fixing some functions. The following days will tell more about how fast or slow I'm able to fix things.

Review of monsters

Today I was looking at the Monster class. It's 2971 lines of code which in Kaduria is one of the biggest source files. Most of it is ok, but it's missing AI code and role-playing system parts. It has been difficult to create the rpg system itself, because I suck at it. However I feel that if I can nail this one it's going to be much easier to complete the game. This is the important part, how to make monsters tick so to speak.

Another difficult thing is the relationship between Monster and Player classes. I now realize that there should be a clear derived-type construct which should not be broken (which I have done). It's another issue which is going to take some time to fix. But even with all these difficulties I'm optimistic. I have learned my lessons.

Snow fox

I may have been too careful not to add too much content (like new creatures, items, etc.) during the process of programming the engine, but I guess it's time to forget the engine for a while and just add anything that is needed.

Level themes are quite strongly themed with specific monsters and other stuff, but I try to avoid making them too predictable by trying to break the rules randomly. I have thought that it could be possible to entirely replace a part of dungeon area with another theme, but that's something to consider later.

The problem with adding stuff is that it can be later tiresome to edit all that data if/when something changes, but then again I haven't spent all this time for nothing: the engine is flexible enough to introduce new stuff without too much extra programming.

So, again I'm at the snow top, wondering what kind of creatures live here...

New member

I was bored so I decided to refactor some code. Key_Handler was changed to modular class with minor changes and it went into classes directory which contains all modular classes of the project. They are classes that need least amount of maintaining. Whenever I get something in classes directory it's like those lines of code are removed from the usual maintaining horror this kind of project has.

Even two or three weeks off the project seems to make it possible to look at the code from a distance and possibly create better decisions in how to proceed.

Shops

After returning to Kaduria I was fixing some stuff and noticed there was no support for shops in rooms so I started to refactor that. The source code was there already, I just had to add a sub type in Room class for shops. Everything seemed to went well, because the shop creation code was also ready. But then... to my surprise it didn't work at all. Everything went wrong: there was only one table in the shop, the shopkeeper was in wrong place and all shop items were null items (this happens when the item creation fails and it's a safe way to detect problems, because null items actually work, they are just not real items).

I guess it should be easy to fix those problems, because the code to create shop and items is really just about 20-30 lines of code.

Environment actions

I think the objects need to have a memory of where they were before. I think it's the only way to do stuff like pushing things into water. If the object doesn't remember where it was you would get multiple messages of the object falling in water when it's pushed to the next water tile. The funny thing is that I previously had that kind of data, but for some reason I removed it. I need to look at action data again, because creatures do have current task they are doing, like swimming. But I think that can't be used with other type of objects, because things like barrels don't go swimming, they just fall into water and float in there.

I'm thinking of breaking the big poop into micro actions. Like "fall into water", "float in water", "get out of water" etc. Well maybe I don't need the previous action to determine things, just current action.

I've also tried to clean up some of the mess in Message class. It's scary, that's all I can say about that.

An idea about stairs

Playing JADE gave me an idea about stairs. I noticed it's super annoying trying to find stairs to the next level in those quite large levels (especially maze types). So, why not make it easier and place the stairs somewhere near the entry stairs? It would make navigating much nicer when you have explored that level and just want to pass through it. Someone would argue that it makes too easy to advance, but that's not correct. The level difficulty should be determining that. In other words you can't just rush into places without getting killed by powerful monsters.

JADE is a nice game, because it shows how not to do things. It's constantly reminding what is bad game design.

Digging - object specials

It was premature to say that digging objects was going to be easy. Sure, most cases can be handled with Damage that simply causes blunt force damage to the object, but there are plenty of special cases that need plain old source code in each object type's Dig virtual function. Let's take an example: when digging a pit there can be a tree in that tile. You can't dig a pit there and you can't cut the tree. I've made a special case that tells the roots of the tree prevents digging. Other option would be cause damage to tree until it falls, possibly damaging the player if he gets hit by it.

There are surprisingly big number of special cases related to digging, so it's somewhat slow progress when programming that stuff in virtual functions. Nice thing is that I have those special cases in the old switch-case function for digging, so I can extract messages and such from them. But in many cases I have to re-write stuff, because game objects work different way than old terrain based object tiles.

Digging into digging

Digging routine is probably the most complicated of actions. There are actions for variety of floor and wall types, but also for all game objects. However it's now quite easy to handle game objects, because Damage can be used to generate simple "pick-axe" damage to objects, much like kicking does. Floors and walls (terrain) can produce different results, because there isn't just one floor type (like in Nethack for example). You can do all sorts of special stuff like digging on ice and fall through in icy water.

With terrain tiles I had to create a test function that generates all terrain tiles and then just went on checking what happens when you dig each tile. That way I could clear the confusion caused by rather complicated data-driven approach... but I guess that's the best way to do things anyway: test everything you possibly can figure out.

LOC chart 2

When you start to add content it shows in LOC. Although the chart can look deceiving since there is only about 500 lines of code added. It could be more, because I'm in the process of moving old kicking and digging functionality into new data-driven code and then removing old commented out code. Both kicking and especially digging are full of content, because a lot of things can happen in those actions. The functionality shift from old code to new isn't easy, but I've managed to create a good flow with the current engine. The new code is already much better, because it's data-driven and if something is missing it's quite easy to fix later.

Damage challenge

It looks pretty good with Damage and Kick, which is using Damage. The only exception will be combat, because it has to be handled with higher detail. Kicking objects makes them break! Although there is some minor adjusting left in the amount of damage, because you can break anything with one kick. The amount of damage is too much, which in return brings a question about the HP or condition value of a object. What should I do with that? Maybe linking that value to the size of the object is a good choice, because it's obvious that bigger objects can take more damage before breaking. But how about monsters?

Kicking ass

Sometimes virtual functions can reveal their bad side which is repeating code. After all virtual functions are a lot like switch-case in traditional C. I noticed that when re-factoring kicking for objects. Each object type has virtual Kick function, but it's starting to look like the data-driven style is kicking back with generic code that looks like it could be placed in one function. Good thing is that such function already exists, I just never thought it could be more generic. It's of course Damage, a routine that has caused a lot of pain to program.

Sometimes I wonder why it took so long to "return" to this stage, where stuff begins to work like it should (for example kicking objects). Did I really spend six years refactoring the game engine?

Constructing constructs

Constructs are one of the object type that are man-made. They too are still in early stage. However I was able to write light routines for lamps pretty fast. I even made a video in Youtube where I'm testing a lamp:

http://www.youtube.com/watch?v=g8Rdyw4Yp04

Meanwhile Visual Studio and Opera started to act strange. There seems to be some trouble with menus which are aligned to left in the main level of menus:

I don't know what's the problem, but I think it came with Windows 7 SP1, I guess. Or maybe some setting has been changed somewhere. It's not a big deal, but these modern operating systems, you know.. They are so complicated that can't even keep setting like this.

I try to continue with constructs. Some graphic tiles need to be made and start to look at different actions like what happens if you kick 'em.

Messages

Some good progress today. I managed to tweak a routine for messages that places messages in a list and displays them later. It might look like an obvious solution, but it wasn't that back then. However I was pretty glad that it didn't take too much refactoring, in fact both styles work at the same time. I guess it's going to take some testing to check out everything, but that's what the players are for;)

I've been adding missing features and today I was able to program the container creation for item containers (bag, backpack, etc.) and also container routines for them, but that was pretty easy, because I copied the code from movable container. It has virtual functions and in places like this virtuals are cool. No need to re-factor anything, just add virtual routines for the class and that's it.

Now that I have a youtube account (Kricex) I'm planning to create a video demo of Kaduria as soon as the gameplay looks like there is something playable there.

LOC chart

What can happen in ten days of coding? Well, not much. But this chart clearly shows a refactoring event. The number of lines start to decrease, but once the refactoring is over you can see that last two days increase LOC. This means that there is need for new code and the project is not yet ready. How things will continue from here? How much the LOC will increase when the exciting data from next ten days is recorded? Stay tuned!

Doorplace search

This one is really giving me a constant headache. How to make sure that rooms are connected?

Rectangular rooms are quite ok, but round rooms are the worst. There is a small section, often one tile per facing, where the door can be made. If the corridor and doorplace don't cross it fails. Now, this is where I might try a routine that extends the corridors to find and clear the last couple of tiles. There might be couple of ways to do that, but I think starting from the first tile next to doorplace and then searching with a pathfinder. You can't possibly go wrong with that. Well, unless the room is completely surrounded by other rooms. That's when you need to crash through the room walls to another room.

Bridge generation

Finished automap tile data refactoring for all objects that had automap tiles. Some new tiles are required for new objects.

Now when I can see ground objects from the automap I noticed that bridges need more logic in the creation. In that screenshot most bridges lead to "nowhere" in small area of the level and some are generated right next to each other. This one should be quite easy to fix, just check out the sides of the bridge and also what's in the direction of the bridge. Those green spots by the way are the old bush tiles. I found out that there already was 50 automap tiles for ground objects. I did remember them, but they were in a separate tileset that was not loaded until now.

Cave generation

With the current version of cave generation I'm letting rooms connect to walls of another room. I'm hoping that by allowing this it's possible to create almost town-like dungeons just by creating lots of rooms in a small space.

This is a section of a cave theme level view in automap. Those green spots are bushes... it's a start of more generic plant generation, no other than bushes are generated at the moment, but it will be a jungle when there are more plants. It's all getting back slowly. Rooms, corridors, stuff like that.

Room creation returns

I had the room creation switched off for a while, because I was re-inventing the wheel in how the rooms should be placed.

The first thing I noticed was this. It's what we professionals call "island creation". Two systems are created separately and don't connect to each other. In this case caverns and dwarf-made rooms. Well, I guess this could be quite easy to fix, maybe check out if connection was made and if not, use a connecting corridor from one of the rooms or corridor tiles. I think a corridor will usually cross a cavern area, but things like this will happen sometimes.

By the way, I still have to figure out how to prevent corridors meeting a room at sharp corners, creating impossible situation for entrance/door creation. Yes, I know, this is something that I have worked on for a while...

History of Kaduria

During the creation process I have started to form a history for Kaduria. It's loose and I don't know the exact details myself, but I'd like to tell something about it.

As everyone knows Kaduria was constructed by dwarves, like Moria too. But that's only half true. In fact there was an older dungeon built by ancients. (You got to have ancients, because they are cool.) From this process there are still places and items left that are clearly something different than what dwarves made later. Then, who were the ancients? Were they elves or maybe dwarves that were more advanced in metal handling? Or could they have been humans? I like to keep that an open question.

There were also two other ancients. First of them is well known and there are still people left from the tribe that once inhabitated a part of Kaduria. Then there were also a third kind of ancients, who possibly were the oldest of them all. They were the ones who built the twilight gate.

So there is lots of ancient crap to be discovered. Powerful weapons and treasures. Dwarves were not interested in searching the dungeon when they took over. For them Kaduria was a place of mining operations. They couldn't care less about the ancients or the junk that was hidden somewhere. But dwarves were concerned about the twilight gate and it was hidden by them.

Lines

I think it could be interesting to start tracking the LOC count from each day I'm programming Kaduria. The current LOC is 40 609 which includes everything like comment lines. When I get ten days of data I'm going to make a graphical summary and post it as a blog entry. It will blow minds.

In the latest ADOM blog entry Thomas Biskup wrote that ADOM has 150 000 lines of code. That's crazy! It's over three times bigger than Kaduria. And not just that, I seriously doubt that Kaduria will ever be much over 50 000 LOC. But then again, Kaduria will be a simple farming simulator and not a real roguelike game anyway.

Brick Atelier development

Well, now it's time to continue Brick Atelier (former Stile), a sprite editor made for Kaduria. The thing is that I'm using it to draw all tiles and it's missing a key feature: import. I need that for some tiles. I haven't touched BA since last year so time is really flying fast. I had a new idea how to refactor the user interface. It's a needed feature for the release of new version. I don't mind about GUI elements getting in weird places but it's better to fix that for actual release. BA has 10490 lines of code so it's actually quite large project. The main reason for the large size is the custom GUI I made myself. Only the Windows file dialog is not a part of the custom GUI.

Feature days

I try to fix one feature or bug per day. It's a lot for the recent development speed. Oh, Duke Nukem Forever is delayed which is "good" news since I "promised" one level demo (or something) released at the same time when Duke gets out. But I somehow know it's not going to happen. I mean the release of Kaduria's demo.

Things look better now though. It feels like everything I do now is solid, something that doesn't need refactoring later. It feels almost sad to say that after 453 years of development.

The pit problem

A pit in two-dimensional game can produce unwanted logic problems. It's lower than ground level so there should be support for third dimension. But sometimes there isn't and that's the problem in Kaduria. Let's say you push a boulder in the pit. That's easy. What happens if there is something in the pit already, like another boulder or a monster? They don't fit in the same pit, but there is no way to put the boulder on top of anything, because there isn't support for third dimension.

I guess it's time to add that support. I really tried to go with only two dimensions, but it's impossible with the level of complexity Kaduria has.

Notes

Been fixing some difficult parts in the source code marked with note: comment. The overall development is also getting faster all the time. It looks like I have passed the obstacle of not knowing what to do. I have concentrated on dungeon generation to get it ready. The main idea of the generation is first create simple structure and then decorate it with automatic stuff like plant growth and decay. I'm quite happy with the current speed of development, it really feels like something is happening and I just have to fit some pieces in the right places to get this game ready for first 0.0.1 alpha.

Journey onward

About a week ago I got a second flu. This one was easier and I'm getting better, but I have been sick for month and a half! Today I tried to continue Kaduria, but it seems to get more difficult all the time. The source is full of problems that need to be fixed, but many of them are scattered and need fixes in many places and I'm always confused about how to fix problems that are like that. Then there are "impossible" features like sleeping. For some reason I wanted to show a graphical camping scene when sleeping, but it's just impossible, because monsters are moving and when they move the gameview is updated... maybe if there was a possibility to check the sleeping in one place before updating anything then it would be possible. But I think I'm going to settle for easier solution and show only the gameview when the player is sleeping.

Terrain refactor

It's funny how I have to fix the old school design yet to this day. I guess it was worse than I thought. I'm speaking of the terrain/object distinction. In the old model some terrain tiles were object-like and there were a lot of terrain tiles like that. In the new model objects and terrains are separated, leaving some basic terrain types. This doesn't sound too bad until you find out that every action routine must be rewritten, things like digging and kicking. I have found it hard to create a solid way to interact with the environment and limit the use of special case code.

This is where data-driven approach will help, but it doesn't happen by itself. Also, it can be possible that you start to refactor the data-driven implementation to achieve more detailed system. I think my plan with plants was too detailed and I need to stick to basic stuff to get something done in reasonable amount of time.

For a while I wasn't really sure what the hell I'm supposed to do next, but at least now I have this data-driven terrain system to create.