Jump to content
  • Advertisement
Sign in to follow this  
Martoon

Thoughts on object creation order and setting object properties before creation

This topic is 4093 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

An issue I come up against every so often is the problem of setting some property (or otherwise manipulating an object) before the object has been created. This is usually in the initialization of a game/level/area, etc. It's often a script that's trying to set the property. For example, yesterday we needed to have the camera in an area start with a different FOV. Due to the chain of dependencies that ultimately ends up creating the camera, it turned out to be difficult to have this set in a convenient, reasonable place. Ultimately what I ended up doing is putting the set function somewhere else, where it would store the value, then check for the existence of the camera and set it if there. The camera, on initialization, would also query for this value. So the value could be set before or after the camera's creation. This is an ugly, non-generalized solution, but we were in a bit of a crunch so it just needed to work. Here I'd like to start a discussion on general approaches to this problem. I do have a technique I use for delayed game object loading. When an area is pre-loaded, the area definition file is parsed, and all of the game objects are instantiated immediately, but they don't load their content (3D models, etc.) or do any other initialization. Each object has a Loadable interface, which stores name-value pairs (a value can be a string or a number). So an InitLoad() method stores these values. Then, over time, the queued up objects have their Load() method called, which retrieves the stored values by name and uses this to actually load content and initialize the object. But what about a more generalized solution for objects? What if objects were never instantiated or had properties set directly, but rather had this done by a factory and manager that reacted to messages? If an object didn't exist yet, it's messages would be queued until it did. Or is this just asking for more trouble? Obviously, this couldn't be used for things that required a response or action from an object before continuing. But for things like the flood of creation and initialization that happens when a level or area is instantiated, could a system like this work? I honestly haven't put much thought into this yet, but I wanted to see how other people deal with this.

Share this post


Link to post
Share on other sites
Advertisement
Usually, the best approach is to figure out why the chain of dependencies is the way it is. Try to rearrange it into something less problematic.

In some cases, though, two-phase construction is called for. This is basically the approach you are taking; but a neater approach is to

(a) just create a "dummy" camera which can have its properties set, but that's about it. Do it *right away*.

(b) Let the script set properties.

(c) Call a member function that "does the rest of the creation work", once your dependencies are settled.

Otherwise... I think the problem is not well enough specified to start thinking about "more generalized solutions".

Share this post


Link to post
Share on other sites
Basically, the solution is to get the dependencies right. These problems generally come up for two reasons:
  1. Circular dependencies -- class A depends on class B which eventually depends class A. There are various methods for breaking circular dependencies depending on the cause.
  2. Poor (or the lack or) software design. This might seem easy to fix -- just figure out the dependencies -- but frequently the fix will require a major rewrite because the dependency problems are just the symptoms.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!