RE: Entity system in Lua, communication with C++ and level editor. Need advice.

[<jgiors@...>]

> -------- Original Message --------
> Date: Fri, 7 Jan 2011 09:58:48 +0000 (GMT)
> From: HexDump <hexdump2002@yahoo.es>
> Subject: Entity system in Lua,	communication with C++ and level
> 	editor. Need advice.
> To: lua-l@lists.lua.org
> Message-ID: <963360.88736.qm@web29703.mail.ird.yahoo.com>
> Content-Type: text/plain; charset=utf-8
> 
> First of all as this is my first message to the list I wanted to say hi to 
> everybody.
> 
> Before expose my questions I would like to note that I don't want anybody to 
> expose a silver-bullet for all my probs, just need some inight about how peopple 
> ussually do that in orther to let me start rolling and develop my own system.

I'm glad you have a realistic expectation, since there is no "standard"
component system. It's a high level design idea which each person/team
implements differently.

My comments are based on some experience working with component systems
on "triple-A" titles (more realistically, near-triple-A) and my own very
small game prototypes.

> I have a 2D basic editor written in Qt, and I'm in  the process of adding 
> entities. I want the editor to be able to receive  RTTI information from 
> entities to change properties, create some logic  being able to link published 
> events to published actions (for example, A  level activate event throws a door 
> open action), etc... . And here is where lua enters the game.
> 
> On the other hand I want to use a component based design for my entities, and 
> here starts my questions:
> 
> I have decided to create my components in C++ side and export needed things to 
> Lua. Making lua define entities by composition of C++ components (Entity 
> templates). Don't really know if Entity class (just a container for componentes) 
> should be a lua class or C++ class.

What size/complexity of game are you working on?

For a small to medium-sized game, I think you can go with either Lua or
C++.

For a larger game (e.g. a "triple AAA" title), I would be reluctant to
recommend Lua as the representation in the engine -- not because I know
of any issues, but because I have never heard of anyone using Lua in
that manner on a large scale. It doesn't sound like you want to be a
"trailblazer". There are also other issues, like efficiently
parallel-processing component data, especially for PS3 SPUs. Lua would
still be fine as the data description format, and possibly as the
primary internal representation in the editor.

> How are engines like cryengine, etc... have all this rtti information exposed in 
> their editors? 

One of the most common component systems references are these GDC slides
for Dungeon Siege (even though it's from 2002):
http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf
This page also has more info:
http://scottbilas.com/games/dungeon-siege/

Dungeon Siege has its own scripting language (called Skrit), but if you
did things in Lua, it would probably be similar.

[BTW, I do not have any experience with Dungeon Siege]

Component systems are usually highly data-driven. In the "triple-A
titles" that I worked on, the component system was more-or-less a
specialized database. Components were described in a data file which was
used to generate both the C++ structures for the engine and the data
schema for the editor (achieving RTTI). Each level had it's own data
description (separate from the component schema description). The
generated C++ structures were compiled into the game engine, while the
editor could track data in any way it wanted -- it only needed to be
concerned with C++ structure on "level export". One of the systems
described data structures with Lua while another used C macros.

Each object and component had a GUID which could be used to retrieve it.
IIRC, even in the engine, relationships between objects/components
required querying the component system to obtain the referenced object.

For my small projects, I've been writing everything in Lua except for
the lowest-level functionality. I've created a simple data-driven system
which isn't inherently component-based, but I create components in the
data-driven system and then compose them into objects within the same
system.

It also supports "templates", which provide a data description which can
be instantiated. Templates can inherit from each other and can override
components/properties. Templates are "flattened" into the instance.
Other systems use "prototypes" or other methods to achieve the same
effect (I think Dungeon Siege calls these "archetypes").

> I have some ideas but don't know how feasibles they are. For example, I have a 
> Health component, I have come across I could expose the Health component to Lua, 
> and two methods getHealth() setHealth(), this way the editor could ask the 
> entity with this component all "get"XXXXX and show in the editor the XXXXX as a 
> property the designer can change. Does this makes any sense?

Usually things are treated differently in the editor than in the engine.
To the editor, health is just a property (or set of properties) which
you can set to any value (possibly limited to some range), while in the
engine, the Health component probably has additional functionality, e.g.
triggering an event when Health falls below some threshold. You probably
don't want that event triggered when the user modifies the value in the
editor.

My point here is that although getHealth() and setHealth() are fine for
the engine, you don't usually want the full functionality of components
in the editor, and hence you don't want to instantiate the component
itself, but (most likely) treat it as pure data.

With a data-driven system, the engine can read the data and instantiate
all the functionality of the game, but the editor can read the same data
and do something different with it. All data can probably be edited in a
tree-view, while the editor's "world view" will use a subset of engine
features to render only certain details of objects (or even just render
a placeholder).

> To bring some more information I have to say that my editor is external, not 
> ingame editor.
> 
> Thanks in advance,
> Notbad.

I hope that gives you some useful information to get started.

John Giors
Independent Programmer
Three Eyes Software
jgiors@ThreeEyesSoftware.com
http://ThreeEyesSoftware.com