Mediator to Mediator and Proxy to Proxy interaction in a game context

[houen]

Hi
I am in kind of a rut here, and any help on my basic architecture would be highly appreciated

I am trying a game architecture design where it would be valuable to have mediators update "child mediators" at a frame rate-based "View Update" method from the game loop, and have proxies update child proxies also from a global "Model Update" method (something along the lines of this article: http://blogs.msdn.com/etayrien/archive/2006/12/12/game-engine-structure.aspx , and the MVC chapter from Bill Sanders and Chandima Cumaranatunge's book of AS design patterns http://www.adobe.com/devnet/actionscript/articles/ora_as3_design_patterns/ora_as3_design_patterns_ch12.pdf

The benefit of this would be in my opinion to allow interpolated updating of the view, with visibility and depth management based on parent/child relationship, and allow destroy() events on proxies to propagate down and destroy all child proxies (e.g a ships guns, shield, etc.)

The downside is that mediators/procies hav a lot of knowledge of other mediators/proxies, although only for  update/destroy/visibility/depth purposes common to all view/model components

Is there a better way to manage proxy/mediator interaction and management for a game context?

[puremvc]

There's no real problem with forming  hierarchies of Mediators or Proxies that communicate downward through method calls. In an extremely dense tree, it could be more effective than notification which is a flat list of observers for a given note. If there are Mediators all down the tree that subscribe to the same note and have to discriminate whether they should act on a note, then you could be losing valuable cycles. Game architecture needs maintainability and code separation as much as the next progam, but you really have to count your cycles and make Time vs. Strictness   tradeoffs much more often. That's not to say sacrifice Maintainability at the alter of Speed. Its more like learning to ride a short board when you're used to a long board. Just a different balance.

Hang ten,
-=Cliff> 

[houen]

Ok, thx a lot for your reply. This is really difficult stuff for me just starting out with pureMVC
I am currently leaning towards creating a tree of entities (proxy VO) and using "[NAME]destroy" notifications to ensure child view components are destroyed when destroying a top-level entity through it's proxy (VO's and proxy/mediator components share the same name for a given object).

I'll post my final design when I have something i'm happy with and working

[Roustalski]

Awesome,

I'd be interestd in seeing your design when you're finished if you are still willing to share when that time comes [: