Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking for a method to script the creation of entities (arrays of components) for delivery through my entity factory, i.e scripted creation of .net objects.

I have looked into Lua but it seems dynamically creating CLR objects is a somewhat impractical.

Is there another method I could use to achieve this? Is there a general pattern / approach to take towards scriptiing out functionality in this context?

My factory provides an abstracted EntityComponent[] per request, so the scripting platform would need to be aware of and be able to construct the component types defined within the c# namespace.

I want to be able to define the components of an entity and the components relevant properties in some declarative form within a script. To give some background information, I was let onto this when I found deserializing entity definitions from XML was going to be very awkward. Reflection within C# is an option but if it is not my only option I would very much seek to avoid it.

EDIT: Turns out I was very wrong about Lua! It is unbelievably easy to achieve what I was describing once you get the LuaInterface DLL up and running, importing types from your C# application into Lua is simple and effective.

share|improve this question

I've been writing a few blog posts about this recently. Specifically for entities data files, and the just published post for taking those data files and turning them into entities.

Essentially, you write your own parser for a custom script language. The parser reads components into "blueprint" form for your factory. Each entity will have a set of component blueprints that can be used to generate a unique entity. When you want your factory to create an entity of that type, it creates a component for each blueprint it has, then adds them all to an entity object.

It's not really likely you'll find something pre-built. Since there are so many ways to implement an entity component system, your solution will need to be specific to your implementation.

share|improve this answer
Do you then have to make changes to your parser every time a new type of component is added to the domain? – Drew R Feb 14 '13 at 22:03
The component contains information for parsing itself. Then I just need to add a reference to the parser so it knows about that type of component. I wasn't too worried about this since there's not going to be a whole lot of components (30ish?). This also provided me the flexibility to have some aspects of the components set by the current game state, where a script couldn't be pre-written with that information. – Byte56 Feb 14 '13 at 22:06

If you're using C# (it's in the tags) you might be able to take advantage of the Xml.Serialization in-built parser to serialise/deserialise your objects:

In theory (probably a big in-theory) it's as simple as passing the object to a serializer and letting it do the hard work. Especially if your entities are just bags of components, which should just be a list of other objects to create. If you store Direct3D resources inside your components you might need to augment it a touch by customising the serialization of those parts. There's a fuller reference for the serialisation methods here.

Hope that helps.

share|improve this answer
Thanks for the answer Matt. I have looked into deserializing XML but unfortunately it is very awkward when it comes to inheritance. The serializer must be told what types to expect when it is constructed, this is something I want to avoid. – Drew R Feb 14 '13 at 22:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.