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.
Would you mind expanding on your idea for a data-driven terrain system? I would love to know more..
ReplyDeleteIt's just an OOP trick to wrap everything in one class, in this case more like user defined type.
ReplyDeleteWith "straight" C-programming you would write something like:
if (terrain==tWater) Do_Something();
However, if you add water-like terrains you need to add:
if (terrain==tWater || terrain==tWarm_Water) Do_Something();
With class programming the details are hidden inside the user defined type with verbose public interface, so you don't need to worry if you add a terrain tile. Everything elsewhere will work if the data type is modular.
Terrain_Type tt(terrain);
if (tt.Is_Water()) Do_Something();
Now if you add water-like tile it will be detected everywhere without need to refactor. Stuff related to terrain stays relatively modular and everything is controlled through that verbose public interface. It's really simple but a good technique in large scale programs.