|
There are a few places where 'dynamic' datastructures are appropriate. When you don't know at compile-time which variable you're going to be accessing, you've got a pretty good indicator that you should be using something dynamic since it's impossible to get any better. But if you're talking about something silly like: get_property(ch, "hp"), it is most likely to your advantage to simply throw the "hp" variable onto the character datastructure, as this prevents the typobugs that plague dynamic systems. If you need programmatic access to the variables (e.g., looping through them all, translating their values to strings), you should probably look into reflection devices for compiled datastructures.
I use a combination of the two. All variables that I need compile-time access to are static, embedded directly into the class. I allow scripts to access these variables through a meta-object interface that reflects the variable's name and value. Game-specific values are not static at all.
You are in quite a predicament because most of your game logic is likely hardcoded. It is not a bright idea to write hardcode that depends on a dynamic variable like this -- if static code needs it, why shouldn't the variable be static? You gain so little with dynamic variables (the ability to add independant new properties can easily be given to scripts, and programmatic access is available through reflection) and you lose so much (compiler-checking of your code's integrity) that it's probably not worth it unless everything that depends on the dynamic variable is dynamic as well, e.g., it's a softcoded game like LP.
|