Entity Properties Protocol

Hi all,

The entity manager is complete as you all know, but whats worrying me is that when an entity obtains another entity, it doesn’t know what the other one contains in terms of information and variables stored.

So ive concluded that some sort of protocol is needed to make sure that one entity can read another.

So the question is, is this an application specific thing? or could jME provide for that?


I guess it would depend on how generic the protocol is. What do you have in mind?


to be honest, I haven’t got the faintest! I was hoping that someone here knows the answer

By a protocol i mean something like this:

every entity has : Health, armour, speed and manoverability. But you could also have type of clothing…etc. Hence the need of a protocol.

I am leaning towards leaving this up to the user to decide…


You can try having the entitys have a type property witch the others can use to see what one contains. I think puting in a mandetory armour ext. would be a bad idea beacaus not all games use it. (Like a car racing game).

oh no it wont be mandetory at all. It will be customisable down to the very last variable. I like your idea tho about list what types it has, but then again, what use is it if it can’t make sense out of the variables it obtains…


Hmm… doing this generically is going to be tricky. Ultimately, you probably won’t be able to do everything… but you might be able to make it easier on the application programmer by providing some utilities. Just tossing out some ideas…

  • PropertyReader/Writer class/interface that you give to every entity so it can serialize/deserialize its own data in a standard way. (Meaning, it combines all its data into a parsable format (like a String) that it can give to other entities to look at) You could create a couple default reader/writers to help the user, but it would ultimately up to them to create a reader/writer combination if they need anything complex.

  • Create a standard way for certain types of properties to be found from other entities… like ‘getStringProperty(name)’ or ‘getIntProperty(name)’… Entities can then ask other entities for the specific properties they’re interested in. Point being that you define the allowed object types (String, int, float, ‘Object’?) and provide standard methods to get them.

  • Use reflection to call specific methods on the fly. Eg: ‘getArmor’ could be defined… The guy who needs the property from that entity could use reflection to call the ‘getArmor’ method on an entity he knows defines it. (Icky bad… there’s got to be a better way)

  • Similarly, you could use ‘instanceof’ to type-cast the entity to what you need it to be. Don’t think this could be supplied generically, though.

  • Stipulate that you always pass properties as Strings. Leave it up to the application code to decode them as needed. (Might as well do the getIntProperty or getStringProperty or whatever instead, though…)

  • Use XML (or some simpler home grown equivalent with less overhead) to pass around attribute-value pairs.

    That’s all I’ve got off the top of my head.


I can see what your saying Shmooh. And I think ive cracked it…

public class JanitorBehaviour {

  public static final String JANITOR_HEALTH = "health";
  public static final String JANITOR_STAMIA = "stamina";

Now when one entity gets another:

Entity t = (Entity)EntityManager.getEntityFromName(message.from);
if (t != null) {
  int health = ((Integer)t.getProperty(JanitorBehaviour.JANITOR_HEALTH)).intValue();

What do you think of that? Very extendable, easy to use, and simple.

Any thoughts regarding this proposed system?

PS. The above code is pseucode and not actual code. Because you would not know if its returning an Entity or an EntityNode in the EntityManager call...


My idea was somthing like:

Entity t = (Entity)EntityManager.getEntityFromName(message.from);
if (t != null) {
           int health = ((Integer)t.getProperty

I see, so your checking if its a Janitor before doing anything Janitorish. Glad we’re on the same wavelength Badmi.


Just a couple quick notes… (Don’t have a ton of time this morning)

If the ‘Entity.getType()’ thing is an int, you can make that a switch statement instead of an if-else chain. (Rerferring to what Badmi posted). Switch statements are very quick… and it looks like this will be used a lot, so might be ideal. Problem could arise from the behaviours having to each define an id that you can guarantee will be unique.

Another thought is the ‘Entity.getProperty’ thing. Not sure how it’s storing those properties… a map of some kind, I assume? t.getProperty(…) will return an Object, yes? You could provide other mechanisms for getting properties instead of just one single method:

getPropertyString() → String

getPropertyInt() → int

getProperty() → Object

Basically, you do the type-casting for them. The reason for this would be that you might be able to do it more efficiently than they could. Ie, if you end up storing things differently in the future, you might not need to do the type cast. If you’re always returning an Object, the user will have no choice but to always type cast. Only problem comes in when returning native types (eg, ‘int’, ‘float’) because there’s no ‘null’ value if the property happens to not exist. May want to stick to real objects like ‘Integer’ and ‘Float’.

It’s generally preferred to have a strongly-typed system (returning String, Integer, Float) rather than weakly-typed (returning Object). It usually makes code more readable and is less prone to errors (both programmatic and runtime).

Anyway… again, I’ll try to look at this more later, but it looks like a nice, simple, and easy to use solution.


The thing about this "protocol", is that we cant force the user to use it. Which is a plus and a negative at the same time tho :?

However, my gangster demo will use Behaviours and I will try and emphasis their use as much as possible.