Pimp my architecture

[Eric Arnold (umop)]

Hi Folks,

I am in the process of finalizing my (AS3) architecture for a game, and I just wanted to get a sanity check / some ideas to make sure that I made the best decisions and reduce the number of factors that I'm not considering.

This is a multiplayer game.  The entire game is a single component, not architected with PureMVC.  I put it together before I decided to go the PureMVC route, but it seems to work just fine this way.

Here is an example of the life-cycle of a drag of an item which is supposed to create a holder (I'm calling a "stack") for the item during dragging on both players computers:

• Drag event happens on an item (view component).
     
  • View dispatches an event which is caught by the game mediator in the function onUIStartDrag
• gameMediator:
     
  • onUIStartDrag figures out details about the drag (what is being dragged and the parameters - whether it was  a part of a selected series, etc) and then sends a LOCAL_STACK_CREATE notification which executes the LocalStackCreateCommand command.
• LocalStackCreateCommand:
     
  • Gets an id for the new stack from gameDataProxy
     
  • Creates a new stack visually by calling gameMediator.createStack(...) with the new id which creates the stack visually via the view component.
     
  • Calls gameDataProxy.remoteCreateStack(...)
• gameDataProxy.remoteCreateStack:
     
  • Constructs a message with data and sends it to the server
• gameMediator.onUIStartDrag sets up this stack as the dragging stack, locally so that it follows the mouse until it's dropped.

*** meanwhile, on the other computer ***

• Server transport dispatches an event with the incoming command which is caught and handled by gameDataProxy.handleCommand
• gameDataProxy.handleCommand calls gameDataProxy.handleRemoteStackCreated which send notification REMOTE_STACK_CREATED which executes RemoteStackCreatedCommand command.
• RemoteStackCreatedCommand calls gameMediator.createStack with the stackId from the server which creates the stack visually via the view component (see above call on other computer)

My immediate questions are:

1. I could have (and even started to) put the logic currently in onUIStartDrag into a command UI_START_DRAG.  I reverted this because:
    a. Debugging with
        org.puremvc.as3.core::Controller/executeCommand       
        Function/http://adobe.com/AS3/2006/builtin::apply [no source]       
        org.puremvc.as3.patterns.observer::Observer/notifyObserver       
        org.puremvc.as3.core::View/notifyObservers       
        org.puremvc.as3.patterns.facade::Facade/notifyObservers       
        org.puremvc.as3.patterns.facade::Facade/sendNotification       
        org.puremvc.as3.patterns.observer::Notifier/sendNotification 
      strewn all over the place is kind of a distraction when you trying to see what's going on in the stack, and I wanted to minimize it.
    b. Creating each command takes extra time to code
    c. Refactoring commands if I change my mind mid-project takes more time than refactoring a single method
    d. I figured that if I do have a business case for a command over a method, I can just move the code over then.
2. I decided to not create a command for the gameMediator.createStack either, for the same reasons.

What are y'all's thoughts on this kind of sequence?  I appreciate those who have read this far and any and all feedback that you have on this.

Thanks,
umop

[philipSe]

Just one little thing; be aware that you can choose to have a mediator interact directly with a proxy or proxies.  Cliff has posted eloquently on the design choice of mediator versus command elsewhere in the forums.
----Philip

[Eric Arnold (umop)]

Cool.  Good to know.  But architecturally, this sequence looks alright?  (ie. It's not cutting corners on the using commands vs. local methods?)

Thanks,
umop

[puremvc]

I try to encapsulate as much of the behavior of the view component in that component. So unless there's a good reason to run a thread all the way out through the mediator into a command, etc, I avoid it. As you said, you can always refactor your local method logic into a command if need be. But also don't put scads of logic in the mediator either, it's not a code-behind construct, it's a communications facility. Respect its role and responsibilities.

-=Cliff>