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

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!

• What exactly is reflexivity? Do you mean reflection? – The Communist Duck Jun 8 '11 at 13:14
• On a side note, I am currently doing exactly the same thing as you (entities in the same style of XML) right now. That's kind of creepy. – The Communist Duck Jun 8 '11 at 13:15
• It is scary, actually. By reflexivity, I mean reflection. – Raveline Jun 8 '11 at 13:22
• if it's a casual game, you could write it in Lua (there's Kahlua for Java). Data files would already be runnable code, and you'd have one headache less. Also, I'd guess loading times wouldn't be horrible either. Just an idea. – Raine Jun 8 '11 at 14:14

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.

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.

• +1, I love data-driven systems, but I tend to agree with this, it's a sensible advice – Raine Jun 8 '11 at 17:11
• -1 I simply can not agree with most anything said in this post. You have to validate game assets regardless at load time so the compiler static typing etc argument is pointless to me (Its already being applied on the Breakable and Renderable components, you shouldnt have to then define every breakable and renderable setup you can think of in code... just makes No sense unless making a very limited content game like.. tetris or something). From there you just question the design that isnt even in question. So .. this just does not seem like an answer to me. – James Jun 8 '11 at 18:59
• @DeadMG Since opinions were asked for I will remove my -1. But in-code definition of component templates halves their usefulness. There are two main reasons to go with a component system. First is maintenance. This makes inheritance-trees wide not tall which helps in maintainability and extensibility. Second is asset creation. Designers can make objects with components without needing a developer (especially with a script component). This doesn't limit creation, removes the programmer as a bottle neck in asset creation and caters to the quick iterative nature that is game asset development. – James Jun 8 '11 at 20:52
• There's an entity system discussion waiting to come out of all of this, I know it – Raine Jun 8 '11 at 21:27
• @phtrivier: That would be the logical assumption. However, it's my experience that XML is like inheritance or indeed, dynamic types - people ejaculate it over any problem that it might possibly be tangentially related to just because they can, instead of genuinely evaluating if they need it or not. @James: If you're smart enough to write <Entity name="Window">, you're smart enough to write class Window {. Behaviours can still be scripted- especially if doing that was pre-provided via inheritance or some small example code- or even reflection. – DeadMG Jun 8 '11 at 21:44

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.

• Yes, I had the "200,000" objects problem in mind. And in another case, I would be very careful with this design. But I have two arguments in my defense ! First, I do not have 200 000 objects (it's a casual game where everything takes place in only one very small map). Secondly, those Entity do not take a lot of place in memory (they are, chiefly, a map of components made of integer and string, nothing fancy). And even though I like very much your idea of "on the flow object creation", if you use reflection, you're going to lose in performance since it's not at loading. – Raveline Jun 8 '11 at 14:01
• @Raveline It's a tradeoff between performance and memory usage. Not only should you avoid premature optimization, but it shouldn't matter which you choose - they are not going to affect the rest of the game, and so if you do find one is a bottleneck you can easily switch for the other. Reflection may be orders of magnitude slower, but slower than lightning fast is still very fast. – The Communist Duck Jun 8 '11 at 14:22
• Snail fast is slower than lightning fast... – Jonathan Connell Jun 8 '11 at 15:49
• Link to the Terraria web site (in case anyone's curious) which includes a video (after 3 minutes they show the characters building a house): terraria.org – Randolf Richardson Jun 8 '11 at 17:39

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).

• Scripting languages may be much easier to use, but it becomes much harder to spit the files out from an editor. – The Communist Duck Jun 8 '11 at 16:34
• @The Communist Duck, well, it's not too bad, really (the editing). Dynamic languages also do not benefit too much from Intellisense or similar technologies, due to their dynamic nature. It'd involve some degree of static analysis, and I doubt many editors do that right now – Raine Jun 8 '11 at 16:46
• Despite that, I think for any physical size project the time gained from using an editor as opposed to the small amount of time used from writing it shorthand in a high-level language is pretty much nil. I think the main reason I am using the XML way is to produce a nifty tool that I can show off. – The Communist Duck Jun 8 '11 at 16:52
• (I was thinking of something like developer.mozilla.org/en/Rhino/Serialization ) – phtrivier Jun 8 '11 at 16:54
• Since I don't know Lua (nor Groovy), and I don't want to spend too much time on this project, it seems that a Javascript (or more exactly JSON) solution could be quite interesting. – Raveline Jun 9 '11 at 5:13