Map issue

While the development is shifting from technical problems to content creation there is still plenty of things to do. One of them is maps, where in once again I notice I have been wrong. The current problem is that I have a map for objects that don't move (aka terrain objects). The map id is shared with all types of objects and it's basically duplicated data that has to be synchronized with current object lists. It's a problem, because I want to make it possible to add objects easily.

The current implementation has one base class for all maps, including routines that are needed in dungeon generation. Those routines are however not needed for objects like monsters or items, because they don't come in formations in general. What I now plan is three base classes for maps. The first one should remain a simple int-based map. It doesn't need any special routines for dungeon generation etc. The second one will be a map that has object pointers stored, so you could take the information directly from object type, such as retrieving the correct graphics frame, or even drawing it directly. The third map will be solely for terrain and dungeon generation, including all those complex generation routines.

I guess it's time for yet another refactoring moment. I'm not that worried, although it's going to be a big change for objects at least. It's also a big change in the way I used to think about maps. I wanted them to be just ints, but the experience with Teemu proved that object maps can be safe, if you don't try to do everything with them.

The journey of item data extraction

The item data is now extracted from the external data file to a text file that has matching enums for data, kind of automatic binary to source conversion. The reason I chose to use external data was not that bright, but I was much younger then. In the end I finally came to a conclusion that external binary data was causing too much problems in form of synchronization. It's not like impossible task to maintain two sets of data and keep them synchronized (I'm talking about the source codes of editor and Kaduria), but I think it's better this way.

I also try to minimize the manual data and see if it's possible to calculate the rest of data from basic blocks. Like estimating the weight of item by size and material. It's probably going to work good enough, but I don't know yet.

I'm now starting to think that even scripting is better idea than binary data, while I'm still convinced that it's possible to write a role-playing game without scripting.

Progress report

After creating some extra datatypes the amount of source files is increased. The count is now 205 source files including headers. I'm estimating the release version is going to have about 250 files, probably not more than that.

I have programmed Kaduria 42 times in this month. I think it's some kind of record. Refactoring has been much easier now, because the way new component classes work. Replacing old code has been easier than I thought and it has improved the data-driven style of the source code.