ActionScript Event Management...

Post here your questions about the Flash / Flex / Air API for SFS2X

Moderators: Lapo, Bax

Devon
Posts: 41
Joined: 12 Apr 2011, 16:18

ActionScript Event Management...

Postby Devon » 09 Jul 2012, 07:32

I'm still new to AS3 and have been doing a lot of reading on common practices and the best way to tackle certain problems. One of particular interest is the Event system and the fact that Events will only bubble through the DisplayList. While looking at the CannonCombat Flex example, I noticed that they tend to make everything extend Sprite or another displayList object. My question is this, why would you extend something that doesn't need to be extended when you could simply use one of your static classes or create an additional EventManager to register with your InstanceManager and then simply add and listen to events on that (essentially) global object?

I'm not trying to bash or otherwise discredit the work done by A51, I'm simply trying to form a better understanding on the reasons (if any) as to why the project was approached in the manner that it was.
Thanks :)
User avatar
A51Integrated
Posts: 240
Joined: 03 Jan 2012, 19:55
Location: Toronto, Canada
Contact:

Re: ActionScript Event Management...

Postby A51Integrated » 10 Jul 2012, 12:14

Good question and no offence taken :)

For the most part, Sprite is used or extended when display object functionality is required. Things like Event.ADDED_TO_STAGE are really useful so you don't start performing logic on something that isn't fully initialized. The Sprite class contains a bevy of useful methods and properties out of the box.

Static classes, while handy, are slow - sometimes up to 2000% slower. So while we'll use static classes for some things, we need to be careful and registering an event creates a reference to the object in question (although events are one of two places in AS3 where weak referencing is possible).

Specifically for CannonCombat, there is the issue of running multiple clients for development and testing purposes on the same machine. With Adobe AIR, you can't run two instances of the same app - even one in the IDE and one installed. So we developed the multiple window solution and instantiated a separate "app" in each. While this works, it has one limitation and that has to do with static classes - they are exposed to all instances of the app. So changing a property in one window (app) will change the property for all windows - which is certainly not desired.

I will admin, I took a quick look at the code, and there is one class that I think doesn't need to extend Sprite (PositionUtils) and that was probably left in there in error since it doesn't require DisplayObject functionality.

There are third party packages for event management or you could roll your own, however, for SFS examples we develop, the intent is to focus on SFS functionality and so we tend to try to not convolute the code with third party resources where possible and try and keep the logic simple so developers don't spend half their time figuring out how we coded some non SFS functionality (or we'd have to document it well which is another task).

So in short:
- Sprite is easy and rich and is the basic building block of AS3
- Static classes are great, but slower
- AIR only runs once app instance, so shared static classes are troublesome
- Examples are developed to be easy to follow SFS logic
A51 Integrated
http://a51integrated.com / +1 416-703-2300
Devon
Posts: 41
Joined: 12 Apr 2011, 16:18

Re: ActionScript Event Management...

Postby Devon » 11 Jul 2012, 10:08

Awesome, makes sense!

I'm planning/working-on a multi-user web-based application, rather than a game. Basically, the user will be able to maintain a position in the lobby - but also, they'll be able to join multiple rooms to chat and what-not. What specifically was the purpose of having a GAME_STATUS user var? Isn't the server already aware of when you enter/leave a room? That being so, why would you need to explicitly broadcast the GAME_STATUS from the client?

I'm going to assume you have a logical reason behind this as well and that I should also incorporate a similar approach into my application. Because I'm dealing with a situation where a single user may be in the Lobby, RoomA, RoomC, and RoomXYZ, all at the same time; how would you suggest I approach this particular scenario?

Thanks!

PS: Sorry for so many questions on structure, theory, and what-not. I have been doing (x)HTML/CSS and pretty fundamental things in PHP for the past several years. I've dealt very little with OOP, let alone trying to build anything of magnitude from the ground up. I've recently began looking into C++, but I've only skimmed the surface with things such as datatypes, pointers, bit-wise operators, ect. Therefore, design patterns continue to bewilder and are something that I've only, vaguely, read about...

I realize it's probably beyond the scope of SmartFox Support or your licensed duty with A51 to explain these practices to me. However, I do greatly appreciate all of the insight your willing to provide and I'm sure many others will find this theoretical and structural information very useful.
User avatar
A51Integrated
Posts: 240
Joined: 03 Jan 2012, 19:55
Location: Toronto, Canada
Contact:

Re: ActionScript Event Management...

Postby A51Integrated » 11 Jul 2012, 12:54

GAME_STATUS is used to identify per user what state they are in (whether they are in game, lobby or in limbo). That way, we can iterate through each user in a room and determine what they are doing. If in Limbo, they are waiting for an opponent, if in Game, they are playing, and if in Lobby, they are back in the Lobby. It's a simple way to determine and persist state.

If you have a user in multiple rooms, then using some kind of state identifier is a good idea (UserVariables work well for this because they can persist from room to room OR be dropped when changing rooms). THe key here is when to broadcast a UserVariable change or when not to. You can configure rooms not to broadcast the event and handle distributing the message to select connected clients from the server side. This way, you can control how many messages are sent. If you broadcast to all connected rooms, you may get into scaling issues when there are 2000 people connected - that's 2000 messages for a single UserVariable change.

So the trick is to determine which messages are critical to be sent to which users. There are numerous ways of distributing small messages and they each have different characteristics (User vs Room variables vs Object message, global, private, etc - see the docs for more info).
A51 Integrated

http://a51integrated.com / +1 416-703-2300
Devon
Posts: 41
Joined: 12 Apr 2011, 16:18

Re: ActionScript Event Management...

Postby Devon » 11 Jul 2012, 17:22

Oh, I would have thought that the SFSUser object would have kept track of rooms a user is currently in - apparently it doesn't from what I can find in the ASDocs... Could getUserRooms() not have been used to accomplish the same effect?
User avatar
A51Integrated
Posts: 240
Joined: 03 Jan 2012, 19:55
Location: Toronto, Canada
Contact:

Re: ActionScript Event Management...

Postby A51Integrated » 11 Jul 2012, 17:29

getUserRooms only gets the rooms array that the user is joined to. We're using User Variables to store info about what the user is doing. They could be in a game room but the game may not have started, so this gives us a way to get greater detail of the user's activity. It can be used for numerous things like current points, badges, power-ups etc.
A51 Integrated

http://a51integrated.com / +1 416-703-2300

Return to “SFS2X ActionScript 3 API”

Who is online

Users browsing this forum: No registered users and 13 guests