Thursday 16 April 2020

Plant simulation

It looks like I have to rethink plant growth simulation, because it was too simple to work properly. If you can set up plant simulation it's one of the only places in roguelike development where you can then reduce the work in random generation by some dramatic amount. But for that to work the simulation needs data which is consistent with the dungeon layout, everything that contributes to growth of plants.

That's actually all I have to say about it. Well, other than in Kaduria the plant simulation is going to be quite detailed, because the amount of data the environment has. I'm not looking forward in clearing the mess I made, but when it's done at least something should work in this project.

Friday 3 April 2020

Namespaces and enums

I think I have not yet figured out how to use namespaces properly. Previously I often created a namespace for enums, but it does create problems with names especially if you open the namespace. If you put an enum into class it's much safer that way, because it exactly ties the enum into that class. It also removes the need to add another namespace for stuff, which in large projects is important, because anything you add into the project makes it harder to maintain.

Currently I'm using more generic namespaces to store data and sometimes functions. For example there are low level text routines in 'codex' namespace and data in namespaces like 'creaturedata' and 'itemdata'. The data in Kaduria is often simple structs which again is probably not the best way to handle it, but it's what it is. The way I now see namespaces is more like a tool to keep track of data and not so much to isolate it from global scope which in C++ is a bit overkill anyway, because you can access only the stuff you include in a .cpp file.

I guess the "proper" way to use namespace is how std:: namespace is used in standard template library, which is to denote a super large library. But the way I'm using namespaces seems to work, at least it doesn't add more confusion.