This project has moved and is read-only. For the latest updates, please go here.

Tag questions

Topics: Developer Forum, User Forum
Mar 19, 2009 at 9:41 AM
Edited Mar 19, 2009 at 9:49 AM
Well i was building my game, and i went to add a particular feature. This just happened to require me using the tag of geoms, and i had a couple of questions:
1. I am converting the tag to (an IContraptionComponent is the base interface for all of my game entities) using the following code:
IContraptionComponent component = (geom.Tag as IContraptionComponent);
is this correct?
2. I started my game unaware of the benefits of tags, and thus have a game entity (IContraptionComponent) that stores references to everything it needs (textures, geoms, bodies, etc.) that i use when i want access to a specific part of an entity. Which method is best for handling data storage?
A: a tag based method, where i toss around geoms and "backpedal" to the entity when i need to;
B: a cyclic storage method, where the tag stores a reference to the entity and the entity stores a reference to the tag;
C: a conventional method, where the entity stores a reference to the geom.
Also, i noticed that in the body, the tag is a field while in the geom, the tag is a property.
Mar 19, 2009 at 7:09 PM
1. Indeed. That's one way of doing it. When you use the keyword "as", it will try and cast the geom.Tag object to IContraptionComponent. If it fails it will return null, so you need to check for null.

2. The Tag property comes in handy when you only have a reference to the geometry. Such as in the OnCollision event that only works with geometries, you will then have a reference to any other game object through geom.Tag. Using geom.Tag for anything else is a waste, both because it is of type object, and thus it will box and unbox everytime you access it. And because it easier to have a good game logic structure that is logically split up: GameUnit (base class) -> Trap (inherit gameunit) and so on.

Our samples is a great foundation for new games as it already have everthing in place. (Menusystem, drawing etc.)

As for the storage method, you should have a base class that contains both body and geometry objects. If you happen to do stuff inside the OnCollision method (where you only have a reference to the geom) you can use Geom.Tag to access the reference of your game object.

As for the tag property / field. Fields are "faster" than properties to access because properties are actually methods. We need to be high performance and everything counts. This of course is at some expense, but we just have to live with that. The reason for one of them being a property and the other a field, is that I simply forgot to convert the property to a field. (there is still a lot of properties that could be fields.)
Mar 20, 2009 at 3:56 AM
Thanks for the reply. I started out with a project that used a lot from the samples framework, but since i don't like the game state management you're using, i moved to a new project (and am going to write a menu system of my own). I am going to go with option B and store a reference both ways (since i use the tag very little, but its a good idea to have it on hand just in case).