Thursday 18 November 2010

Client-side code for SmartFoxServer

At the moment, we're writing our client-side code in ActionScript 3.0. How to access the libraries in your swf is covered in a different blog post.

I'm intending to wrap the calls to the SmartFox client API in a set of local classes. This is a bit of insurance, so that if we decide to change our server part way through most of our code will be left unchanged.

What I've done is create a server class, that has functions such as login and sendRequest that can be accessed by the main game. Behind the scenes, this class then deals with connection and all the SmartFox classes. It then dispatches custom server events as required. These can be listened for in the rest of the game, with no dependancy on the SmartFox events.

The other part of this is to dress up the request parameters so they can be sent in the required format. I've defined a RequestParam class, that holds a name, a type (e.g. Int, String etc) and a value. The server class can then interpret these to add them to the proper SFSObject and send them to the server. I've actually started creating subclasses of the RequestParam class for each type of parameter, so initially there's a RequestParamInt. This sets the type of the parameter automatically, and hopefully keeps the code pretty clear and a bit more free of constants than otherwise.

Logging in
To create a connection to the SmartFoxServer, the game creates an instance of Server.as, starts listening for the ServerEvent.LOGIN_SUCCESSFUL event, and calls server.login with the appropriate parameters.

The server class checks to see if the client is already connected to the server, and if so it performs the login. If the client is not connected to the server it calls the connection code, listens for the connected event, and when that event happens successfully triggers the login code again.

When the response to the login is received, if that login was successful the Server class dispatches the ServerEvent.LOGIN_SUCCESSFUL event that the game is listening for, and the game can carry on with whatever it needs to do next.

Extension Requests
Sending an extension request is similar. Walking through the add example given in the Server side extension doc  the client creates two instances of RequestParamInt. One has a name of 'n1' and an integer value (e.g. 3), the other has a name of 'n2' and an integer value (e.g. 4). These are added to an array. The client calls on the server object to sendRequest. SendRequest takes a string parameter of 'add' as the request name (which matches the string name given in the server-side extension when the request handler is added) and the array of parameters.

Even if there is only one parameter, the server object is still expecting an array!

The server class goes through the array of parameters and adds them to an SFSObject, using the type parameter to work out which of the SFSObject methods to call (e.g. putInt, putString etc.) and creates a new request which is an instance of ExtensionRequest. This uses the request name and the SFSObject as parameters. This request is then sent to the server and we wait for a response event that gets bubbled up to the main game structure.

Server Responses
The request that comes back includes a params object. Each type of event uses the params object slightly differently, and a full description can be found in the Client API Javadoc under com.smartfoxserver.v2.core -> SFSEvent. I think we might want to set up some kind of response handler structure for the Extension responses in a similar way to the server side does - each response is sent back with a command name to allow different things to happen with the results, so it may be useful to use that.

This structure will get added to, as needed!

No comments:

Post a Comment