Sounds like a fun project! Let me try and answer your
1) Yes, this is the appropriate way, because you're creating a
multiplayer game. The server should decide who is allowed to do
what and when something should happen, so it is the obvious choice
for a 'game controller'.
2) I'll give you a push into the right direction about
Robotlegs's MVCS implementation (going from most to least
View: renders the photo and the 'caption editor' and any other
necessary audiovisual feedback that is part of the game. Make sure
that is its only function: it shouldn't care about the
communication with the server. In this scenario, it would probably
be preferred to have Mediators only listen to events from the
Model(s) and other Views.
Service: connects to your Red5 server, listens for the required
events and dispatches its own events in response, with the
necessary data. This data is allowed to be 'raw' - Arrays, simple
Objects, etc. This way you'll keep your "Red5ServerService" clean,
which increases reusability (and maintainability, flexibility, and
Model: keeps track of the current game's state - the currently
connected users, a highscore list, the current player's ID / name /
score, etc. When these values are updated it sends its own events
Controller: commands handle the events that need more
processing. For example, the Red5ServerService might dispatch a
PLAYERS_UPDATED event when someone joins or leaves the room,
carrying a simple Object with the current players' properties. A
command could then create typed value objects (VO) of this data, so
it is easier to add to your Model and/or to be interpreted by your
Mediators. Another example, explaining view-to-server
communication: the current player enters a caption and presses a
'send' button in the CaptionView, its corresponding CaptionMediator
dispatches a SEND_CAPTION event in response along with the actual
text, a CheckAndSendCaptionCommand is mapped to this event and
verifies and formats the text and then calls the 'sendCaption'
method of the injected Red5ServerService, after which the service
sends the message to the server in the right data format.
I hope this has given you a clearer view of the different
Robotlegs elements and their corresponding functions.
I'm sure you'll have more questions, so don't hesitate to
4 Posted by Paul Borawski on 22 Jun, 2012 05:25 PM
I got another question for you. So I am working on the
CheckAndSendCaption command like you mentioned. Right now that just
cleans up the string and sends it along to the
RemoteSharedOBjectService. The service has a method called
addCaptionFromUser which sends this call to the Red5Server
So as you can see I need to send a user ID and a room ID to the
server as well.
My question is at what point do I get the userID and room ID that
are housed in their respective vo's? Do I inject my model into the
command to get the room and user IDs and send that along to the
service or does the service get the IDs from the models through
injection or a series of events back and forth? I hope this makes
sense. Thanks again for any help you can give!
5 Posted by Paul Borawski on 22 Jun, 2012 07:50 PM
Actually I was looking at an example on the Flex Mobile in
Action book, and he injects his model at the mediator level and
sends the info that way. I am going to try that but not sure if
that's the most effective way of doing things