Action

I need some planning with actions. First I have to think how actions are broken down to atomic pieces for both player and monsters and what data actions need. The AI for actions is going to be really tough stuff. I don't have experience with sophisticated AI and it's first time I'm trying to do that. I have a vague idea how it's going to work, because I have thought AI issues a lot during the development.

The new Avatar

I'm refactoring the player class and also U_Npc, the base class for monsters and the player. It's now getting slightly interesting, because I'm restoring the actions which the player (and monsters) have in the game world. They caused some serious problems before, because I wasn't really good at figuring out where actions should take place. Even I knew monsters share some actions I didn't (for some strange reason) place them in the base class.

Writing the code for actions is I think the hardest part in roguelike project. You know, those innocent looking commands like eat, look and search. They rely so much on the engine core, that if the engine is broken then the commands can't work, or they require constant refactoring to match the changes in the engine. Of course, writing modular code is a good way to prevent such problems, but I really didn't know how to do that until now.

Equipment re-design

Previously I had items in inventory list and they had in_use -variable to show in what use the item had. This included wearing and wielding items, but I really didn't think I would have to re-design it later. In fact I didn't think at all when I designed the first system, it just felt nice to have inventory with items tagged as equipment.

The problem was that when you check for items you have to go through the list and check in_use every time and with monsters doing the same it's going to be slow. So, I changed the equipment to an array of items each in equipment slot. The real problem was that I had to re-write everything related to in_use and I'm still re-writing it, because in_use was in pretty heavy use, so to speak.

When this is done I still have to re-design in_use, because it's going to be used in other kind of uses like when you put on a lamp, to indicate that the lamp is on.

I think this was one of the last really annoying re-writes. From now on I try to work with the current style of the source code and accept the fact that it's not going to be perfect OOP.

Tweaking GUI

Made good progress today with GUI improvements. GUI design has always been difficult for me, but now I have a better picture of how it should be done.

Moving objects

There was a bug that was funny for a moment. One of the object types is a movable or mob (moveable object). These are barrels, chests and other big objects you can push, but not pick up. Somehow all of them were moving randomly around. That was a bit hilarious and I was just chasing them for a while. Everything seemed to work well, you could push them like always, they didn't just want to stay in one place. The reason was that when the movable is on water it's floating and moving randomly, but in this case the moving routine was called every turn no matter where the objects were.

This bug could be made a spell, some kind of chaos spell that animates objects to move around and cause confusion among mundanes.

Game object base class forming

It's getting better when I go through the functions and try to figure out them. There are two main areas where improvement is needed. First and most important one are the functions that are interacting with the game world (terrain). Second one is everything related to strings (object names). Then there are some problems with virtual functions. It's a good invention, but can cause all kinds of bad side effects when the class hierarchy is poor.

I'm actually pretty satisfied with the development I made today. There is still time left today to make more adjustments to object base class. It's important to get that working, then I can concentrate to specific game object types.

Room interiors revisited

Back some time I wanted to detach room interiors from Room class, because I thought Room class was becoming too big. I was afraid of big classes, but now I have to fix that by merging interior creation back to Room class. I also had an idea to create room interiors in large multi-room houses, but now I realize I could just create multiple rooms with each having their room interior and connect those rooms to create houses.

I'm actually fixing terrain_map references, but this is a part of it, because room interiors (and rooms) use lots of creation stuff. This time I'm avoiding direct calls to Level's creation routines and use a member for Room which then calls Level's routine. It's one way to emphasize modularity and make future modifications to the source code easier.