Quote:Original post by coder84
So... Is it OK to use reflection or is it totally bad? ( I didn't understand =/ )

If its bad, what do you suggest without sacrificing versatility and flexibility?

It is not bad, my original reply was to kazes assumption that it would perform almost as well as statically linked classes. (it doesn't unless you only use the basic parts (then it can get quite close but isn't really that flexible))

Versatility and flexibility comes at a price, Reflection is one of the cheapest ways of getting it(it is cheaper than interpreted scripts) but it is still far from free.

My advice is to make things as flexible as you want it first, then profile it to see if it is too expensive and reduce flexibility in the areas where the cost is too great compared to the benefit. (In a large project the benefits are huge)

One thing that I don't really get, Coder84, is how much of the AI Behavior are you actually scripting. You should use stuff like variables to control the behavior:

Your example was a wolf that, instead of attacking the player, would just stand there. Then why not add an "agressiveness" variable to your class so you can control whether it does attack or not? You can follow with this line of thought: add a variable to control almost every behavior of your entity, so you script only what is really necessary.

Then, if that is not enough use scripting to "override" the default behavior of your entity. I think the rule of thumb here should be, if you are going to have a certain class/behavior instantied too many times in your game, then have it hardcoded. Specializations or specific stuff that happens only every once in a while can be put aside and cached during the load or even on the fly.

I believe that even goes to textures and models. You can speedup a bit of loading time by hardcoding a model that is used a 1000 times on your application. The tradeoff is that it'll take longer to open your application (since it's executable is fully loaded into memory before execution), and you also lose memory and control over where will your data-structure be (parts of executables can be paged and stored on the pagefile, I think).

And another sugestion: you can use precompiled assemblies and use then as "plugins", the same way that dlls goes on C++. So, that's the same as having scripts in C#, but the difference is that you compile everything before actual run, which speeds loading time and execution performance. Link with then through reflection during run-time so you still gain flexibility.

If you follow my last suggestion, I suggest you think about a 4 layered application (or think that your application 2nd layer have two sub-layers):

1. Engine Core
2. Customization Layer
2.1 Hardcoded Customization (base class to use inside your MMO)
2.2 External Customization (derived classes declared inside assemblies)
3. Scripts

This way you can balance performance and flexibility. If you think a certain NPC or monster have to act in a very specific way, just add a script to it. If that monsters is going to be instantiated 1000 times each 10 minutes, consider moving the script to an assembly. If the monster will be used in future games or can be used as samples, you can move it up to the Hardcoded Customization layer.

Becareful not to overcrowd layer 2.1 or you might endup inflating your executable. Load 2.2 only during runtime.