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

Why do most games save the players team as a short in the player class and not as a pointer to a team object. As far as I know both methods have their advantages.

Short method:

  • Saving it as a short is smaller;
  • Syncing players will be faster because of the first point.
  • Syncing players will be easier because the memory location can be different on another PC.

Pointer method:

  • You could for example save a team name. That way you don’t need to look it up every time you need it;
  • It’s more OOP.

I saw a lot of engines saving the team as a short. What are the reasons that they save the players team as a short and not as a pointer?

share|improve this question

closed as not constructive by Byte56, Le Comte du Merde-fou, Trevor Powell, Sean Middleditch, Josh Petrie Mar 22 '13 at 15:17

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

thats a weirdly localized question – GameDev-er Mar 18 '13 at 22:27
I think it's actually a good question, depending how you interpret it. It's current wording invites discussion, but read it as "which should should I use?" and it's good and useful; certainly not too localized as it's a crucial point for any client/server architecture. – Le Comte du Merde-fou Mar 19 '13 at 0:35
How do you know what most games do? – Trevor Powell Mar 19 '13 at 2:32
@Trevor Powell There are a lot of open source engines and there is always the reverse engineer option. – Laurence Mar 19 '13 at 16:29
The assumption is that if you're asking a question on this site, it's in relation to something you're doing. If that's not the case then maybe it does fall into the "invites discussion" category & should be closed. Can you please clarify? – Le Comte du Merde-fou Mar 19 '13 at 18:34
up vote 4 down vote accepted

The most common reason is, there simply is no Team object, a int or enum will suffice.

But your assertions are slightly flawed. So let my iterate on them and finally tell you why an int is also a good idea even with a Team object.

First, yes a short may be smaller than a pointer. True on a PC, but it is nowhere guaranteed. (Yes, this is sort of academic.) I doubt that saving or sending 16 bits or 64 bits makes such a difference really and you do not want to send the pointer's address anyway. If you have an IP network to sync over, the network's structure will certainly determine how fast you can sync the player state.

As noted above, you never want to send the address of a pointer over a network or save into a file. You need a way to represent this information in a stable way, thus you give each team and id (int) and store/send this. The receiving/reading end then looks up the team from that id.

At this point you can put a pointer to the Team into the Player object. It has no or little effect to storing or syncing objects.

There may be a reason why you still don't want to refer to other game objects by pointer, but this depends on your engine design. For example you may have some delayed message mechanic. So you send a message to the object (maybe even to itself) to be delivered later, but in the meantime the object is deleted. By using a unique int it is possible to safely handle the message, the lookup fails and the message can be silently ignored. If it was a hardcoded pointer it would have crashed. You see this type of safety or weak references can often be found in code. (Google "Handle" for more info.)

And on a closing note, "It's more OOP". We are software engineers and not software zealots, thus we don't adhere to dogma. Any design discussion must based on real principles that have a well defined gain. Any person that says this is the right way to do it should get their brains unwashed. It don't want to say that OOP is bad, no it is great, but "this is the right way to do OOP" is a non starter.

share|improve this answer
"We are software engineers and not software zealots, thus we don't adhere to dogma." For the love of God, this! If we had signatures in our posts, that would now be mine. – Nicol Bolas Mar 19 '13 at 6:44
Thank you very much. – rioki Mar 26 '13 at 14:23

Are we talking about short int? If so, the main advantage is data serialization. Int is a POD (plain old data). It's way easier to save and load an ID (short int in this case) rather than recreating the OOP pointer to class.

Btw : Speed is negligible in this case

share|improve this answer
This is about a short int indeed. – Laurence Mar 18 '13 at 16:16
The "OOP pointer" could very well be void**** (I've seen this before). How OOP is that. – bobobobo Apr 28 '13 at 16:02

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