Jump to content
  • Advertisement
Sign in to follow this  

Should internal objects communicate by references or id?

This topic is 1743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm building a utility/support assembly that maintains data & state for any tile-based board game: it should be able to model everything from checkers and chess to a Civilization-esque game (no visuals, just state & data).  They're just boards with height, width, and stuff that goes on the board.

 

Consumers of the assembly wont have access to domain object instances, but will have lists of ids for the various entities active in the model.  The public interface is in domain terms only (create a boardpiece, move a boardpiece, set value for an attribute of a boardpiece, etc).

 

I'm stumbling on the internal implementation: is it sounder for domain objects to have references to each other (easier to code, but could also result in code that invalidates the model; a BoardTile shouldn't mutate the Boardpiece it may contain), or to mirror the public interface, and only reference other objects by "domain entity id" (seems overly restrictive, and a little more work to implement, but may be better for enforcing compliant code)?

Share this post


Link to post
Share on other sites
Advertisement

Might have answered my own question: why create two different systems for the same thing?  If I'm going to build the id-based system for the external interface, might as well use it internally as well.

Does this seem reasonable?  Seems reasonable to me...

Share this post


Link to post
Share on other sites
Yes. It sounds reasonable to use IDs. Unless you need to do specific things that require your program to have actual pointers, the ID approach is very sound.

Share this post


Link to post
Share on other sites

It depends a lot on the game and the engine.

 

In my experience, game engines that allow the player to load/save at any time also have a side effect that most code must use IDs rather than pointers.  In this type of engine you can only use pointers for 'instant' processing, for calls that are run immediately and never yield control back for animations or other events. In this scenario a pointer for any non-instant processing will not persist properly between saves and can become invalid unexpectedly.

 

Because of that, I am in the habit of using handles or IDs for everything.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!