Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 39
Текст из файла (страница 39)
The characters appear more detailed than would be expectedon the relatively low-end phones on which this game runs, because theywere rendered with desktop graphics hardware.5.3.2 Challenges of Implementing a Game ServerSo what is needed to develop a client-server game? As has been hintedabove, there are a number of challenges in the mobile space; so justusing a standard HTTP server (or something like that) might not work asdesired.
Here are a few problems that would need to be considered whendesigning the game server.What protocol is used to talk to the server?Some sort of custom protocol running over TCP or UDP gives the mostflexibility. If using UDP, then reliability might need to be implemented ata higher level, but it can be turned off when reliability isn’t required.
Alternatively, all messages could be tunnelled over HTTP. Then, a standardHTTP server and the Symbian OS HTTP stack can take care of the protocolstuff, but the disadvantage is that, arguably, they are not very suited to thetask. The message headers are relatively verbose, and all communicationsmust fit into the model of requests from the client with responses fromthe server; the server cannot send unsolicited messages to the client.How is the player (or the handset) identified?If the connection briefly disconnects or idles out, how does the handsetidentify that it’s the same session as last time? If using HTTP, we couldhave some sort of registration request which delivers a cookie used toidentify the session, which is then sent with subsequent requests.
Using acustom protocol, something similar probably needs to be invented.AIRPLAY ONLINE: A MULTIPLAYER SDK AND SERVICE SOLUTION165Does the server need to be scalable?That is, is a cluster of more than one machine necessary? And whathappens in the case of failure? Here, the question of where data is storedbecomes quite important. Storing a set of backup data in a database isprobably a good idea, since backup, clustering, and failover of databasesare well understood. Different machines in the cluster will immediatelyhave a consistent idea about the current state of the data.A number of other questions present themselves, including:• How is data to be serialized for transmitting over the wire?• Do any operations, like downloads, need to be resumed after errors?How does the client do that? Does the integrity of downloads piecedtogether from many attempts need to be checked?• What expertise is needed to write this? Does your development teaminclude anyone with network programming experience, experienceof managing redundant server clusters, or database programming andadministration experience?It is clear that developing a mobile online multiplayer game is actuallytwo development projects in one: a client-side game that runs on thehandset and communicates with the server, and server-side code andmanagement.
Remote multiplayer mobile game development requiresadditional skill sets to those required for single-player mobile gamedevelopment.4Explaining all these different areas properly here would turn this bookinto a very heavy server networking book. What many developers need is aseparate product that will deal with all the unfamiliar networking stuff andlet the development team get on with writing games. The next section willlook at one such product – Airplay Online from Ideaworks3D – whichwas written by a team that included Leon Clarke, the author of thissection.5.4 Airplay Online: A Multiplayer SDK and Service SolutionAirplay Online can be thought of as solving three problems, each ofwhich we will look at in turn:1.
It provides a set of ‘services’ to perform standard operations like downloading assets, managing high scores, tracking the user’s identity, anda lobby for setting up multiplayer games.4In addition to the extra skills required, writing and maintaining an online multiplayergame has an ongoing cost, in terms of server hardware, hosting, and bandwidth costs.166MULTIPLAYER GAMES2.It provides a transport protocol designed for the requirements ofmobile gaming, and a server and client libraries that implement thisprotocol.3.It makes it as easy as possible to extend the standard services or writenew custom services, if either the standard services do things in thewrong way, or if game-specific logic is needed on the server.As Figure 5.1 shows, Airplay Online servers run on a cluster of Linuxservers, although the entire system works on Windows for developmentpurposes (meaning that server-side code can be developed without needing access to a Linux development machine).
Games can either be hostedon Ideaworks3D’s cluster, or on a cluster owned and run by the gamedeveloper or publisher.Airplay Online ClusterHandsetsServerClusterDatabaseClusterFirewall/Load balancerInternetFigure 5.1 An Airplay Online server cluster5.4.1 Standard ServicesAirplay Online comes with everything that most games will need ‘out ofthe box.’ A game that just uses standard services simply needs to providea data bundle to upload to the server and call the relevant APIs to accessthe services. Programmers with a fear of server-side coding can write amultiplayer game with no problems. The range of standard services isAIRPLAY ONLINE: A MULTIPLAYER SDK AND SERVICE SOLUTION167growing, but currently includes a login service, a download service, ahigh score service, and a lobby service.The login service associates the player’s online identity with the IMEI ofthe phone.
This login happens automatically when the user first connectsto the server. This also keeps track of a user’s tag/name if the gameneeds players to have names (for example, to identify players on the highscore service). Apart from anything else, player identification is importantbecause it enables publishers to know how many people are playing thegame.The download service resumes downloads that have been interruptedand uses digital signatures to check the validity of downloaded files. Thisis combined with a utility library for keeping track of a game’s use ofstorage space, which works by claiming all the space the game will everneed when it is first run. Before downloading a new file, the utility willdecide which (if any) files need to be deleted to make space for it, andcreate a file of the right size.
The download service then over-writes itwith the data. In this way, the game doesn’t unexpectedly run out of diskspace.The high score service allows games to create any number of differenttables (for example, to represent different levels). As well as simply storingthe scores and who scored them, the high score service can store a bufferof information with each score, which can be used to provide informationneeded to re-play the record-breaking runs, or other general informationabout how the score was achieved.The lobby service is used for the setting up of multiplayer games, bycreating challenges, letting other players search for created challenges andjoining them, and then starting off the game, setting up the communicationbetween the players and synchronizing start times.5.4.2 The Transport Layer and Basic Server InfrastructureAs far as is possible, the transport layer is designed so that it ‘just works.’In simple usage, the game developer can be almost unaware of it.
Thegame simply needs to create a session with the server at start up, thenstart using the services. Errors may get propagated up via the services,and that’s about it.Figure 5.2 shows the typical sequence of performing operations usingthe polling style of the API. The general style of interaction (e.g., connect,do things, poll for the status of the thing you’ve done) is the same for allservices and operations on the service. There is, in fact, an alternativestyle of API which uses call backs instead of polling, if the game developerprefers it.However, when doing slightly more advanced things, more facilitiesare needed.
Airplay Online attempts to ‘make everything as simple aspossible, but not simpler’ (to quote Einstein) by providing increasing168ClientMULTIPLAYER GAMESAirplay CoreLogin ServiceServerHighscore ServiceServer Login ServiceServer Highscore Service1 : Connect()2 : Connect()3 : Start()4 : Login Message()5 : Login Message()6 : Login Response()7 : Login Response()8 : Fetch Highscore()9 : Fetch Highscore()10 : Fetch Highscore()11 : Highscore Response()12 : Highscore Response()13 : Highscore Status()Simplified diagram of a typical simple interaction.The client connects to the server (1-2)Which initiates an automatic login (3-7)Then the client fetches a highscore table (8-14)14 : Results Returned()Figure 5.2For simplicity, services are shown talking straight to the server,not via the airplay core. Also, only 1 highscore status request ismade; in fact the client would start polling the moment it madethe request.The highscore request could be made before the login has complete,in which case it would be queued.A typical Airplay Online interaction sequencelayers of complexity that can be used, and worried about, if the gamedemands them.All traffic is multiplexed over one socket, to make life easier whenconsidering firewall setups and when explaining what ports the gameuses.
It will run over either TCP or UDP. For everything except real-timemultiplayer, TCP is probably best. The protocol implements reliability ontop of UDP, which used to have the major advantage that it worked roundvarious eccentricities in different TCP implementations, but nowadays allthe major mobile operating system vendors have properly working TCPstacks.
For real-time multiplayer games, running over UDP has the majoradvantage that the protocol can turn off reliability for any given packet.You might think that reliability would inherently be a good thing, but ifthe data is real-time, it is usually better to send new, up-to-date, data thanto spend a long time attempting to re-send out of date information.Several kinds of messages can be sent over the link. There areordinary one-way messages in either direction, or transactions (i.e.,request/response pairs).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
