Drawbacks of using reflection for a component based system at loading-time

Question

I'm coding a little casual game in Java using Slick2D.

This game use a lot of different "objects", managed in a composite way. So, firearms, furniture in the map, NPC and player character will be composites objects using components to define their behaviors.

Since I'm going to need a lot of, for instance, "shotgun" object, I'm using a sort of prototype pattern. When the player starts the game, XML files are read, and from those XML, typical objects are built and stored in a "EntityPool" class' hashtable. Then, when I'll need a shotgun, for instance, I'll ask for it to the EntityPool, which will give me a clone of this object.

My problem is as follow : I'm using JDOM to parse my XML. I don't know how many components I'm going to use, nor their exact methods. So I'd like to use reflection; a Class.forName(nameOfMyClass) in order to get the exact component for this class, and then a Class.getMethod("set" + propertyName) to fill the information I need.

So my XML can be like that :

<Entity name="window">
  <Component class="Breakable">
    <health>12</health>
    <newEntityAfterBeingBroken>brokenWindow<newEntityAfterBeingBroken>
  </Component>
  <Component class="Renderer">
     <tileset>object.png</tileset>
     <imgnum>2</imgnum>
  </Component>
</Entity>
...

There are obvious drawbacks to using reflection, particularly the lack in performance. But this is done only once, when loading the game. Do you see other problems with this method? Would you do it differently, and how? Thanks in advance for your advice!

Answer 1

There are no drawbacks really. What you have described looks like not only a perfectly valid way to do it, but the way that I would recommend to many people when working with a component based system.. They are designed for situations just like this, where a new object can be created in an editor as opposed to in code.

To chime in a bit with The Duck, you may want to look into an instancing-beyond-xml-definition method. Use the XML to load up base templates of components (default values instead of tracked values) then instanced versions placed in a level or an inventory or a characters save file.. whatever. This might just save you on the amount of processing you have to do. (This is more for memory concerns however, not load speed performance)

Now, those are the main reasons to use this kind of system. Load speeds should not be a deterrent from this as there are many Many ways to improve load speeds. Having an asset pipeline and an engine that can understand the assets in a few ways is very handy for development. The raw text XML version is nice for editors as well as being human readable for quick iteration and debugging if need be. Having a production or compiled version of the assets (instead of raw text load binary data directly) will remove any concerns over load speed. If you still want to be faster then you compile assets to their complete run time format, they can be loaded into memory, their pointers fixed up, and away you go.

While it is always good to try and look down the road, this one is free and clear with many solutions if your concerns ever do become an issue.

Answer 2

You're moving a bunch of error checking and such that could occur in the compiler to the run-time, which is both unsafe and slower, and you're going to have to waste serious time writing all the boilerplate code to make it work. Static typing and compilers exist for a reason, and it's because when your program compiles without error, then it ensures that it doesn't have certain kinds of error- something that you can no longer guarantee. Performance isn't the problem here- it's correctness. Oh, and performance is going to bite you in the ass (nom nom!) when it comes to testing, because your testers are going to have to wait for your game to load in order to test it.

And for what benefit? You haven't mentioned any plans to change the file after deployment, so it may as well be static data anyway. I mean, what benefit are you hoping to get from the system, exactly? If you need an object pool, those exist independently of how you choose to define your objects.

You need to pick a system that matches your requirements. You don't mention any requirements for dynamic entity definition, and the costs of doing it are very obvious, so logically, this system is way overkill for what you've said you need, and I can only recommend just getting a normal object pool and ditching the XML altogether.

Answer 3

There is a slight loss in performance in using reflection in general, but if you claim it is only going to happen during loading you should have no problems (I can't say for Java, but I have seen benchmarks putting reflection at 10 million queries in 3 seconds in C#). Terraria has the slowest loading times I've ever seen (painfully slow), and that has been incredibly successful - thus showing slow loading times aren't a problem as long as your game meets standards.

It has the advantage of making everything much more flexible - no Register methods to remember to call, no dictionary keys to add..you can just plug and play.

The problem I can see in your design is that you will have to create one of every object at loading time. If you have 200,000 different objects, that's a lot of wasted memory. I personally am using a Factory method for mine, like:

Entity e = Entity.Create("shotgun"); //load up the file and do it on the fly rather than at loading time

I may switch to just loading the XML into memory and arranging it as commands - XML is not hugely fast to load.

EDIT: You mentioned the speed of reflection. This benchmark shows the time may be 15x slower, but 1 million calls in 450 milliseconds is not slow.

Answer 4

I would second Raine suggestion to use a scripting language with a decent object literal syntax (Groovy, Lua, Javascript... anything that is supported on the JVM). It would save you having to write the mapping between your XML and Java beans (which is probably automated, for sure).