RTsoft Wiki

“Update and Render functions? Where we're going we don't need hardcoded Update and Render functions”

First of all, a disclaimer: You don't really *HAVE* to use the Proton Entity System to use the framework. If you already have a system you like, or are porting existing code, you can safely ignore most of this section.

I've made a lot of engines and a lot of game frameworks and for some reason I'm constantly trying new methods, mostly because it keeps things fun and interesting.

Here past methods I've tried when creating games:

• Not knowing what I'm doing and hacking everything (see, Dink source) VERDICT: JUST, NO.
• Create a giant entity class hierarchy where each kind of thing gets its own class. A bird might be derived like: Object→Visual→MovingObject→NPC→Bird or something ridiculous like that. End up using virtuals everywhere. VERDICT: Slow to add new things, too difficult to refactor, maintenance is a hassle.
• Create one SUPER HUGE Entity class that does everything, possibly having it initialize sub objects. It ends up with 200 functions and bloated beyond belief. (See Novashell's entity class) VERDICT: Probably the most productive and easy to work with, but becomes a horrible ball of twine to work with where each entity is like a 20KB object when initialized.

Using all of these, this is how it went:

(Ladies, look at your game development cycle)

(Now look at mine)

What if we could trade some initial complexity in the beginning for a more sane experience over all?

Aka, my version of “my interpretation of how Unity internals sort of work after I used it for a few hours”.

If you take a look at Entity.h you'll see some functions but nothing about thinking/updating or drawing. So what can an entity do?

Well, not much, alone. It's fairly lightweight at about 200 bytes.

Instantiate an entity

Let's do some real code to give you an idea of how to use these things, feel free to type along. (you could write it in App::Update() from the RTApp example)

Entity ent; //instantiate it
 
//Ok, now  we've got one.  We can name it if want.
ent.SetName("DeLorean");
 
LogMsg("The entity is called %s", ent.GetName().c_str());
 
//Shortcut: we could've just done Entity ent("DoLorean");  Check the .h to see what else it's got.
 
//Yes, I like printf formatting, so sue me.  I also like std::strings.  So you'll see a lot of those .c_str() conversions around.

Is it an entity or a database?! This “Delorean” has something powerful under its hood - a Proton VariantDB object. This is a tiny but powerful name/key database that internally uses a stl hashmap for quick look ups of not only variables, but also dynamic functions. Let's store some arbitrary data in our entity.

ent.GetVar("gigawatts")->Set(1.21f); 
ent.GetVar("trivia")->Set("Doc pronounced giggawatt wrong in the movie");
 
//retrieve the data like this:
 
LogMsg("Gigawatts: %.2f, trivia: %s", ent.GetVar("gigawatts")->GetFloat(), ent.GetVar("trivia")->GetString().c_str());

Great. Notice that to retrieve the value, you have to already know what it is. This type safety is important to keep your game bug free. If you try GetFloat() but the data inside is a string, it will assert to let you know.

Types the database understands are float, string, uint32, CL_Vector2, CL_Vector3, CL_Rect2f, *Entity, and *EntityComponent.

VariantDB's can Save()/Load() to disk as well, I use one for my app preferences in my games.

**