Jump to content
  • Advertisement
Sign in to follow this  
Spinewire

MVC Entity Deletion Issues (**SOLVED**)

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

Hi everyone! Currently I'm designing a 2D game in Cpp (can't show plus signs?) based around the Model-View-Controller model. This is implemented with three managers handing three lists of nodes. The Model is represented by a list of "Entity" objects, updated every 'tick' (regular amount of times per second) for in-game position, heading, age, etc. by their manager, called "World." The View is represented by a list of "Sprite" objects, with a pointer to an Entity and a flyweight-styled texture pointer, which passively acquires the Entity's game-world position and translates it to a screen position, where it draws the texture every frame. These are maintained and updated by an object I call the "Engine." Sprites can also receive their child entity's age and use that information to extrapolate which frame of an animation they should display. The Controller is a list of "Agent" objects, which receive key events as they are sent by the game's input handler, and use abstract interfaces (such as Accelerate() and Turn()) to manipulate the entity they point to. What's important here is that "Entity" objects are oblivious to "Sprite" and "Agent" objects that point to them, and "Sprite" and "Agent" objects are unaware of each other. Sprites receive their information passively, just from a gameworld X and Y stored in the Entity, and Agents call Entity functions to manipulate that entity. Entities only know when they have an agent and a sprite "paired" to them, set by internal boolean values. Sprites are updated every frame, entities are updated a constant amount of time per second, and agents are only touched when they receive a key (or mouse) event. This all works great, up to a point, and having the entities blind to sprites and agents is very freeing when it comes to engineering choices and encapsulation. Still interested? Well, now, herein lies my problem. Entities will (mostly) be killed when they update, probably as a result of collision detection, which is handled by the "World" manager. I would love to just remove them from the "World" manager and be done with it, but I can't do that, because I'd get access violations from invalid pointers. Since the entity isn't aware of the Sprite and Agents monitoring it, what I have to do is set its internal status to dead and wait for both the agent and sprite to update, see that the entity is dead, de-couple from the entity, and kill themselves. Then, finally, once the entity knows that it has neither an agent or a sprite watching it, it can delete itself. Still, that means the entity will be updating every tick doing nothing but checking whether or not it is free to delete itself or not, which seems like a terrible waste of time and memory. This is especially true since while the sprites update more often than the entities (and thus check to see if they should decouple very often), the agents update very infrequently, and could end up keeping that entity in limbo for the rest of the game if a particular key isn't pressed. Now, I wouldn't mind giving the entitity a pointer to the agent and sprite that are watching it, but I know that opens up the whole ugly bag of mutual dependence. Same thing if I give the entity a pointer to either the "World," "Engine," or "Controller" object. The less these individual nodes know, the better. I want to keep them as dumb as possible. That said, I know I can't have my cake and eat it too, so what's the best way to let the sprite and agent know that the entity is ready to be, or has already been destroyed, when the pointing only goes one way, and the agent updates very rarely? I know I have to sacrifice some of this convenient design, but I'm not sure where to draw the line. (I also tried a three-pointer "coupler" struct to abstract these relationships somewhat, but that was unbelievably clunky, as I have different kinds of agents, sprites, and entities.) Any help? I really haven't been able to find any source material on this part of an entity's life-cycle. Thanks! [Edited by - Spinewire on July 16, 2008 10:47:28 PM]

Share this post


Link to post
Share on other sites
Advertisement
Looks like a good system to me.

Instead of just setting a flag, you could do that but also extend it with some sort of notification system. You could use something like the Observer pattern, where Agents and Sprites register an interest with the Entity, asking to be called back when the entity is in the process of being destroyed. When the entity is about to be destroyed, you call all registered observers (ie. the agent and sprite associated with the entity, although the entity doesn't know that, as it just has a list of generic observer interfaces) and those objects can decouple themselves at that point. Then, the entity can proceed to destroy itself.

To summarise:
- Agent and Sprite both inherit from IObserver, which contains an update() virtual method.
- Agent and Sprite both implement their update() method by checking their associated Entity's flag. If the flag is set, do the usual decoupling, delete itself, etc.
- Entity inherits from IObservable or ISubject (pick a name that pleases you), which has an interface to add or remove IObservers to an internal list, and also to be able call update() on each of the IObservers in that list.
- Have Entity do that calling of update() on each IObserver when it's being destroyed, so that any observing Agent or Sprite is notified of this. Then delete itself normally, immediately after this notification.

Is that helpful?

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!