I guess it's the term "View" that keeps getting to me.

I've often seen code that sits in a View Mediator, which has nothing to do with view/rendering.  For instance, sound management, application state, etc.

I'll split my objects in two.

- Shane

I have a WorldProxy.  The WorldProxy is responsible for managing WorldObjects, that includes their spatial structure, their lifetimes, their current state, and is also responsible for updating all of them at a set interval.  This all ticks, excuse the pun, along nicely.

When it comes to rendering the objects, I have a WorldMediator which uses the database held in the WorldProxy.  It takes care of visibility, a camera, all the stuff that's render related.

Historically, all of my WorldObjects would have a tick() and a render().  Currently they have a tick(), which is what makes everything work, however, I can't have a class that has one foot in the Model layer, and the other in the View layer.

The trouble is, the WorldObject really should render itself, because it knows about its internal state, which assets belong to it, etc.  If I had a separate class to render the WorldObject, it would be an outsider looking in, breaking encapsulation.

The only other way I can think of doing this, the PureMVC way, is to have the WorldProxy do nothing except hold the state data, then have the spatial structure held in the WorldMediator.  This feels wrong to me though, given the role of the Model in my case is to be a database.

How is this dual life usually handled in PureMVC?

- Shane

Sure, it's great at application state, however there is nothing fundamentally wrong with it being used for any state related activities.  For instance, at a macro level, managing Core state and application flow, but at a finer grained level, it can be used for UI/Dialog state mediation.

In other words, it's possible to have a set of states and their associated actions for the application as a whole, with another FSM managing a subset of a particular state.  Not exactly a HSM, but a simple hybrid.

- Shane

Hi Cliff,

I've modified my local version of the StateMachine utility to support multiple instances:

1. StateMachine constructor takes a name, with a null default.  The default lets it act as it does now.
2. Changed FSMInjector to support a name in the XML definition, which is passed to the StateMachine constructor.

e.g.

:

<fsm name="GameFSM" initial={AppFacade.STATE_BOOT}>
Works well.  The only gotcha is that the user has to be careful to keep the actions/states exclusive to each FSM.  If they do, then each FSM will ignore the states and actions of other FSMs.  I haven't found this an issue, but just thought I'd throw it out there.  One way around this could be to mangle a namespace into each set of actions/states.

What do you think?  Sound ok?

Cheers,
Shane

Great, I'm as happy as a clam in a mudflat now, thanks Cliff.

Ok, back to VOs.

I was actually unaware that there is a Value Objects pattern, I thought it was a PureMVC concept.  So I landed upon Martin Fowler's definition:

http://martinfowler.com/eaaCatalog/valueObject.html

VO: A small simple object, like money or a date range, whose equality isn't based on identity.

which in turn led me to Data Transfer Objects (DTOs):

http://martinfowler.com/eaaCatalog/dataTransferObject.html

DTO: An object that carries data between processes in order to reduce the number of method calls.

Very succinct definitions.

Further reading found more detail, but basically boiled down to VOs being small, mostly data-only, immutable structures; almost like C structs.  DTOs we slightly more heavyweight, the idea being that they can minimise the calls back to a model layer, which may be remote.

I have to assume that model != server, so in the case where the model == client (an in memory structure), what should I use?

Imagine again our imaginary game world.  This PureMVC app has a EntityProxy class, which is basically a replacement for a EntityManager in the more traditional sense.  This EntityProxy creates and manages entities, which mediators (amongst other things), render.  These entities also know how to handle their own per-frame updating (AI).

So now we've got an encapsulated entity which is more than just data, it has its own personal brain (logic) too.

So that means it's more than just a VO.  Should it still be called a VO? e.g. MyCrazyPacman.as or MyCrazyPacmanVO.as ?

When the Mediator wants the entity, I don't want to copy all of the data out of the main object to a temporary VO either.  That could be expensive (matrices, vertex data etc).  This is the same thing client/server OpenGL drivers do.  I really just want to ask the EntityProxy for the instance of the object I want (more like a unified memory model); i.e.

:


MyMediator extends Mediator
{
    private var _crazyView:CrazyView;
    onEnterFrame():void
    {
        var ep:EntityProxy = EntityProxy(facade.retrieveProxy(EntityProxy.NAME));
        var player:MyCrazyPacman = ep.getEntityByName("player");

        var _crazyView.renderPlayer(player);

        // Or I could put all of this in a command, but feels like overkill to me given it's so specific to this mediator.
    }
}

This feels natural to me, but it doesn't fit the VO convention of PureMVC.  i.e. These are chunky reference objects passed over the Model/View boundary.  This feels more like Martin Fowler's DTOs.

So what to name my example entity, when it's actually the object, not temporary/transient/immutable copy?

I hope this all makes sense.

- Shane

From the perspective of PureMVC application design, I'd suggest putting those utilities into a separate library project and importing them into the project.

Ok, that's a good compromise I think, and in line with how I usually structure non-PureMVC apps.  Basically I'll keep all of the application itself in PurePVC, with any truly decoupled helper libraries separated out into their own SWC.  Is this what you meant?  If so, that's very natural, and standard, way to code.  I feel much happier with that.

As you suggested, I took a look at the more utility-like libraries - "Utility_AS3_MultiCore_Pipes", "Utility_AS3_StateMachine", "Utility_AS3_Loadup", and I see they tend to hang their code off

:

package org.puremvc.as3.multicore.utilities.*
This works for me, although I'll use our namespace.

However, after hunting around, I've seen other examples of people putting a 'utilities' namespace under their project.  One example is Renju I found here: http://www.emanueleferonato.com/2008/03/25/full-renju-game-with-source-code/.

He has a utils folder as a sibling of his mode/view/controller folders, which just holds a couple of filters.  This is an example of what I was talking about, in that these are small helpers, that don't live in the MVC pattern, are application specific, and are not good candidates for putting into a separate library.  Sure you could put them into a separate application-specific library, but that is starting to feel like overkill, no?

Or... based on your initial feedback:

You might start by simply creating separate util packages under each of the model, view, and controller packages in your app

Would you suggest, in this case, putting the utils folder under view, given they're view related filters anyway?  If so, I could live with that.

- Shane

I like your drawer story, Cliff.  We have one of those too, we call it the "Third Drawer"

Whilst I know where you're trying to go, not everything can ever really fit into 3 discreet tiers.  Classic utility classes are used across all boundaries, a good concrete example being math classes.

Math classes are truly used in everything from view components to transforming data at a model/data level. The code (e.g. matrix.cpp, matrix.as, matrix.m) has to live somewhere.  Sure it can be arbitrarily placed in one of the layers (probably the model layer), but it breaks the MVC pattern because now these layers have to know about the proxy. Worse, how would isolated view components access this math class?

The fact is libraries/utilities/helpers have a place in programming languages. They are a form of encapsulation, isolating an outside world from knowing about their innards, in a a reusable form.

PureMVC itself is using the Flash runtime as a library.  The Flash runtime is using the OS as a library, it's natural and necessary.

MVC is just a concept, a way of mentally organising data, control logic and display, and I've seen obsessive adherence to a particular pattern end up causing more trouble than it solves. I've witnessed this particularly with junior programmers who aren't code reviewed regularly, which happens because it's the nature of development.

Frameworks are great if they're consistent, structured, fit the needs of the purpose for which they're designed, reduce code, help thinking about data ownership etc. I really see that PureMVC has the right hallmarks, I just haven't seen it really pushed yet. I'm sure it is in closed source projects, but I'd like to see something more complex than a user admin app.

This is why I'm trying to really do things the 'right way', because once I find a way to make this all fit together, I'll likely open source a game example for other people to check out.  I'll do this because I've seen a lot of people interested in PureMVC and games.

As for experience and intuition, it's fair to say I've done my time (linkedin.com/in/shanestevens), but I'm always looking for a better way to do things.

Cheers
- Shane

Hi Deril,

Thanks for the reply.  What you've said is more or less in line with what I've done.  I've seen other people append DO (Data Object) to Proxy managed classes too.

So you didn't say whether you think the structure I'm building seems right?  What do you think?

The main problem I have with the VO concept, with respect to games, is that it's rare to have a simple VO data structure.  Sure, these can exist as aggregates of more complex classes, but ultimately they tend to have functions that operate on their data.

So this leaves me wondering if games are a good fit for PureMVC.  The idea of a UI (View - Mediator) that manages multiple dialogs/buttons etc (View - components) which request their data from a data managing Proxy (Model) is fine, but I question the use of Commands (Controller).

Also, I can't seem to find anyone using PureMVC in realtime games, not simple turn/event-based games (no offence intended to anyone making non realtime games ).

Anyway, I'll keep looking at a palatable structure, but I'm beginning to worry I'm trying to shove a square peg into a round hole.

- Shane

Take a look at the HelloFlash demo. Self-directed, mediated objects. Maybe a centralized game loop isn't really the answer for an event driven environment?

http://trac.puremvc.org/Demo_AS3_Flash_HelloFlash

-=Cliff>

I actually started to think the same thing, which is quite a shift away from a traditional game loop-orientated architecture, and have started on a framework around PureMVC to test a decoupled/notification-based main loop out.

- Shane

In short: Mediators are the only class that can send/receive notifications....

well.. no.  Commands can do it also.

 logic should not be in mediator or proxy, they must be in commands.
Mediators generally listen for note to tell them what to show, and it is best that they should do it ignoring any sort of logic.

Actually Mediators are the only classes that can send AND receive notifications.  Commands can't.

Hi,

Getting through the second week with PureMVC, and still really liking it.  I have another question, though:

Q: How do you name VO objects?

The issue I keep running into, making me feel all weird and uncomfortable, is that I find myself adding VO to the end of all of my data classes.

e.g.
- TextureProxy creates TextureVO objects.
- ShaderProxy creates ShaderVO objects
- SoundProxy creates SoundVO objects
- LoaderProxy creates LoaderVO objects

the list goes on.  This how I had it previously:

- TextureManager creates Texture objects.
- ShaderManager creates Shader objects
- SoundManager creates Sound objects
- LoaderManager creates Loader objects

So basically where I would have had 'naked' classes before, I've got VO appended to everything.

I can live with this, however here are some more examples of where it starts to get weird for me:

- WorldProxy creates and manages:
  EntityProxy, which manages EntityVO objects, MapVO, CollisionVO etc classes.

Now... EntityVO objects aggregate other, non-trivial, data objects that are really outside the realm of MVC.  They're game specific utility classes, amongst other things, that makes sense to that Entity.  So I'm not appending VO to them, because their logic will always stay in the Proxy domain (i.e. not be used in Commands or Mediators).

So, in short:

I've been appending VO to class names that tend to be created directly in the Proxy and exposed to the outside world (Commands/Mediators/Views), and everything else is under a 'do' (Data Object) folder under Proxies.  Is this how it's supposed to be done?

e.g. Here's a modified/trimmed version of what I'm doing:

:

- root
  - util (This is the namespace for all non MVC related code.  General framework classes for useful functionality)
    Pathfinding.as
    Collision.as
    Debug.as
    Math.as
    RenderUtils.as
  - mvc (This is the PureMVC application structure)
    - Main.as <- entry point
    - AppFacade.as
    - controller
      - startup
        InitCoreCommand.as
        InitDataCommand.as
        InitGameCommand.as
        LaunchGame.as
        StartupCommand.as
    - model
      - game
        GameProxy.as
      - world
        - vo (I have VOs for objects that tend to get passed across application boundaries)
          - entities
              EntityVO.as
              PlayerVO.as
              EnemyVO.as
        EntityProxy.as
        WorldProxy.as
      - util (Theses are utility classes that related to functionality not appropriate for MVC)
        EntityCollision.as
        EntityVisibility.as
    - view
        - components
          uiView.as
        UIMediator.as
        WorldMediator.as

Does this look ok to you?  I really want to nail this down, so when I explain the new structure to our other programmers, they know where to put old and new code.

When I've finished all of this, I might expose it to everyone as a full game implementation, in order to help the community.

Cheers,
Shane

Thanks to Cliff and Deril for responding.

Deril, with the TimerMediator you describe, you're starting to get at the question I was initially asking.  The issue being that non-view logic is being placed in the view layer, due to TimerMediator deriving Mediator.

This is heart of my issue.  Notifications float around the view layer, in that the view layer is the only layer that can respond to notifications.  In this case the TimerMediator could, and probably should, be a TimerProxy.  The TimerProxy (or maybe AppProxy is a better name) could listen for events from my own game library (game tick), and emit them for the rest of the system to consume.

In this scenario, I could mimic a traditional game loop by having a AppProxy that perhaps emits a macro command that sends the appropriate notifications in order, such as:

1. Tick.
2. Physics.
3. Begin Render.
4. Render.
5. End Render

However, creating and sending a notification, then having the GC destruct said message at 60fps stresses me out (I'm from a C++ background remember, where per-frame allocation is a disaster).  I guess I'll have to get over this.

Anyway, the main issue for me is putting too much logic in the view layer, when I think it should probably shift to the model layer, with the command layer used simply to coordinate the notification sending.  The trouble is that because the view layer is the only layer that can listen for notifications, it more or less guarantees that anything long running (i.e. something that needs to respond to notifications, such as a game state) needs to be a mediator.

In short: Mediators are the only class that can send/receive notifications, therefore anything that needs to know about a notification (such as onTick, or onRender, etc), has to be a mediator.  Hence, logic which isn't related to rendering (onTick for instance), ends up in the view layer.

I feel I'm close to having a model of what to do in my head, however I'm worried I'm trying to push a square peg into a round hole.  Has anyone else had experience in developing a real-time (i.e. continuous > 30fps update) game/app using PureMVC?

Shane

Actually, I am using the State Machine library, but it ultimately just emits notifications.  It doesn't address the structure questions I asked.

Shane

Hi,

Ok, getting to the end of my first week with PureMVC, and I have run into another question around architecture.  This time, my question is around Mediators for logic

In my previous, non-PureMVC, projects (games), I would create a task (my Controller layer) which would be long living, receiving all sorts of  'tick' messages and such.  That task, upon creation, would create a set of views (View layer) to display my content with it being the ViewDelegate, then sit there handling all sorts of messages until it was done.  At which point, it would kill itself, or be killed by another task/manager somewhere else.

For example, imagine a simplified 'GameTask'.  It is created after the player has left the front-end and is starting the actual game.

GameTask:
- onCreate:
  - Load assets (Model layer)
  - Create GameHUD View.
  - Create GameCanvas View.

- onTick
  - Update physics, player control, etc...

- onRender()
  - Render directly into the Game View.

- onDestroy:
  - Kill Game View
  - Kill HUD View
  - Kill assets

Ok, pretty standard stuff.

Now, when porting this to PureMVC, I'm trying to work out what goes where.  Because there is no such thing as a long running task/process (PureMVC Commands are transient), I'm not sure exactly where to put the game logic.  I could just pull it all out of PureMVC and have it running alongside, but that feels like it completely defeats the purpose of using PureMVC to begin with.

So because Notifications in PureMVC are sent through the View layer (i.e only Mediators can receive Notifications), I decided to make a State class that derives Mediator.  These states are sort of like my 'tasks'.  They can register, send and receive Notifications.  Still feels wrong though... I'm essentially putting logic in the View layer.

I then have a GameState (which 'isa' Mediator).  This is like my GameTask: long living, can access the Model layer via Proxies, can send/receive Notifications/Commands to do various things, can be registered and de/unregistered, and generally be the main man.

Here is cut down example of what I mean:

:

public class GameStateMediator extends State implements ITick
{
override public function onRegister():void
{
facade.registerMediator(new GameHUDMediator);
facade.registerMediator(new GameCanvasMediator);
// Register any Commands I need to talk to the rest of the system.
// Register itself with my game library to receive ticks.
}

override public function onRemove():void
{
facade.removeMediator(GameCanvasMediator.NAME);
facade.removeMediator(GameHUDMediator.NAME);
// Deregister any Commands.
// Deregister itself from my game library.
}

public function onTick():void
{
// Update physics, player control, etc...
// Anything that might be interesting to rest of the system, like the HUD, will cause a sendNotification(). e.g. COMMAND_PLAYER_HEALTH_UPDATED.
}

override public function handleNotification(n:INotification):void
{
// Respond to any other parts of the system sending Notifications.
}
}

public class GameHUDMediator extends Mediator implements IViewDelegate
{
override public function onRegister():void
{
// Create my custom library views, with 'this' as a delegate.
}

override public function onRemove():void
{
// Destroy my custom library views.
}

// From IViewDelegate
public function onViewRender(v:View):void
{
var gsp:GameStateProxy = facade.retrieveProxy(GameStateProxy.NAME) as GameStateProxy;
// render anything anything the view needs from data retrieved from the GameStateProxy.
}
}


Now, this all works, and seems ok, however I've got a niggling feeling the GameState could be a Proxy object, so all logic sits in the Model layer.  Also, should Mediators be registering other Mediators? Surely that's a job for a Command, but I want a persistent Command, not a transient one.

But even that feels odd, because it feels weird to say that any logic like gameplay, should reside in the Controller layer.

I'd love to hear what other people are doing here.

Cheers,
Shane

Anybody would think you don't like singletons!

Ok, point taken, and to be honest I do like the purity of the Facade as the only singleton.

There are really a lot of examples floating around in the wild that use static accessors to death in the data (proxy/VO) layer, so finding a consistent usage pattern can be somewhat frustrating.

Thanks for your responses.

Cheers,
Shane