Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Author Topic: Pimp my architecture  (Read 10085 times)
Eric Arnold (umop)
Posts: 4

View Profile Email
« on: October 08, 2009, 12:53:13 »

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
        Function/http://adobe.com/AS3/2006/builtin::apply [no source]       

      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.

« Last Edit: October 11, 2009, 03:59:24 by Eric Arnold (umop) » Logged
Sr. Member
Posts: 139

View Profile Email
« Reply #1 on: October 09, 2009, 03:19:35 »

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.
Eric Arnold (umop)
Posts: 4

View Profile Email
« Reply #2 on: October 11, 2009, 03:54:05 »

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

Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #3 on: October 13, 2009, 09:02:39 »

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.

Pages: [1]