 TraceWord is a multiplayer word search game built on the Native Cloud Software Engine (NCSE), which has helped speed development, ease complexity, and lower the costs of deploying and maintaining this real-time mobile application.
The game is written in Objective-C, using XCode, but since it is a multiplayer game that requires real-time data sharing between players, a server-side component is required.
It makes sense to use cloud computing resources for this purpose, and the standard option is to provision a virtual server on a cloud service, update and tune the operating system, and write the server-side processing code required to support real-time multiplayer game play. For TraceWord, this is where the NCSE comes in.
TraceWord requires several types of server-side functionality that are achieved instead by using Native Cloud Objects coded into the app. These objects are defined and called from right within the Objective-C in XCode and utilize cloud-based Native Cloud Servers. For the version 1 release of TraceWord, the NCSE manages the following functions:
|
Player Matching: TraceWord games are configured with several parameters. A player setting up a new game gets to choose a word list, select whether it will be an easy, medium, or hard difficulty level, and designate a minimum and maximum number of players. Or the player can select to randomly generate these game parameters. In either case, players showing up to join a game can also configure their game parameters. Once a player clicks the Join button, an object is created and sent to the server in search of other objects that match the selected criteria, and the server adds the person to a game, if one exists, or notifies her that no games match the criteria. This is known as Player Matching. It is something that Apple’s Game Center can manage, but only up to four players and with severe graphical and configuration limitations. TraceWord is able to match up to 10 players in a single game, and with the NCSE, it could theoretically handle an infinite number of players.
Object Sharing: Once all the players connect to a game, the shared word list must be distributed, along with the layout of the randomly generated game board. Other data that needs to be shared during the course of the game includes what words have been found so far, which players found the words, and what state the game is in. This information is basically stored in NCOs during the time a game is running and discarded once a game is over.
Real-Time Network Communications: Of course, after a game starts, the players need to be notified as words are found and scores increment. The NCSE has a notification system built in that sends updated objects to each of the players as changes happen. This means the game does not have to be constantly asking the server for the latest data, and much less bandwidth is used by limiting communications to an as-needed basis. It is the ultimate in efficient real-time data exchange.
Scaling: This isn’t something that the TraceWord development team actually needs to worry about but is worth mentioning because without the NCSE, they would most certainly have to. Because the Native Cloud Servers are distributed and inherently parallel, they automatically scale up and down as required by the load at any given time.
|
Benefits of Using the NCSE
The most obvious benefit of using the NCSE is faster development time. Entire server components that would each take weeks to develop are replaced by a few lines of code. The time it takes to provision, configure, monitor, and maintain a virtual server infrastructure goes down to zero because the NCSE provides that layer. The only time required is the time required to define and configure the Native Cloud Objects.
A by-product of removing components from the development list is less complexity. Server-side code, for one thing, is likely not going to be written in the same language the client application is written in, and that already increases complexity. For each function the server needs to serve, in fact, a different language--or even an entirely different framework--may be required, and at that point complexity abounds. The NCSE made it possible to fulfill all of the object definition work from within XCode, the same development environment used to program the game with. No other language or environment was necessary.
Not to be overlooked is the lower cost required to support the server-side part of the game. A traditionally provisioned virtual server must run 24/7/365, and cloud service providers charge by the minute. This means if the game only has 100 players in a day that added up to five hours of play, the server running the game is sitting idle for 19 hours and yet still racking up charges. The other side of that coin is that if the game suddenly has a spike in players, more virtual servers are going to have to be brought online, adding even more costs.
The NCSE, on the other hand, keeps track of the number of transactions it processes for TraceWord and charges just for the time it took to run game-related transactions. Simply put, TraceWord is charged only for the computing time it actually uses. Add that savings to the savings achieved by cutting out unnecessary development and infrastructure operations and costs are cut significantly.
|
| |
© 2012-2015 Native Cloud Systems, Inc. All rights reserved
