Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

 

Building apps with the SilverStripe Framework

Nick is an avid gamer and computer programming geek.

Comments 1

by Nick Koirala

Posted 13 September 2012

Read post

Nick is an avid gamer and computer programming geek. He launched LittleMonkey, a Wellington based company specialising in mobile app development and game programming, over five years ago. He’s been working with SilverStripe since 2009 to program a range of products, not just websites.

I am sure that many of you will have seen numerous examples of well-designed websites that are based on the SilverStripe Framework and SilverStripe CMS, and I started using both of these to develop websites too. However, I found with a few tweaks here and there that these tools can be used to develop a whole range of software products.

Over the last few months, the team at LittleMonkey has been working hard to develop an to support learning the Maori language through gameplay. This app is due to be launched next month and the unique thing about it, while the game itself is a native iPhone application, the backend is built entirely using SilverStripe.

The app is an interactive, multiplayer mobile game to enabled highscool children to learn Maori language through enganging, fast and competitive gameplay. It has no front end web interface and all content is presented to the players on their iOS devices via an established 2D game engine.

It consists of a suite of games, each with different rules, text, image and audio content and difficulty levels. Players are school students, and can build their own avatars and in-game profile. There are shared online highscore tables and players can challenge each other in real time multiplayer games.

While multiplayer mobile games might not be the first thing that springs to mind to developers who try out the SilverStripe demo for the first time, the framework is powerful enough to support the full range of features we need for this project. Even better, we have most of the components we need out of the box.

 

 

 

 

 

 

 

So how do you get started?

The bread and butter of communication between DataObjects and mobile devices is RestfulServer. It provides a ready to use RESTful API with JSON support which is ideal for basic creating, reading and editing of data. In our game it is used to push new game content out to existing users, register and edit user profiles, submit high scores and read back high score tables and push analytics data back to SilverStripe for reporting purposes.

As mobile platforms generally have support libraries for REST and JSON parsing, integration at the client end is straightforward and robust.

RestulServer is included out of the box in SilverStripe 2.4, it has been separated out into a module for SS 3.0 but in either case it’s a simple matter of enabling API access in your data objects, and tweaking permissions for create, edit, view and delete. You can even expose an API covering data from your website and allow third party developers to put mobile apps together for you.

For our game we leveraged the CMS as much as possible to avoid reinventing the wheel. Even though we do not have a front end website for this project, the advantages of an online interface to game content, user management and reports is invaluable to our client. Game content can be managed with minimal effort and extended after the game’s release to push new challenges out to players. The site tree has been repurposed to group game elements into modules and difficulty levels and provide a clear overview into an ever expanding set of game data. In fact we have found it so user-friendly our client has been updating and adding content to the games, as quickly as we have been developing support for them.

ModelAdmin is the next essential feature for this project. There are a wide variety of DataObjects with increasingly complex relationships to define content, rules, and levels for 5 different game types included in the app. During development we want quick and easy access to mess with these DataObjects to fine tune their behaviour, and we also want to be able to pass this interface on to our clients to let them continue to extend and manage the game once it is in the wild. ModelAdmin has improved in 3.0 and our customers all seem to ‘get it’ faster than before. With the automatic scaffolding we don’t need to invest a lot of time in building the admin interface and can focus our time on the game development on the mobile devices instead.

The most challenging requirement is the real time multiplayer. Generally PHP and a CMS system isn’t your go-to platform for this kind of thing but with everything else covered so well with SilverStripe we were determined to find a way. Our multiplayer system needed to cover relatively quiet periods of traffic (waiting for players to join, viewing scores between rounds etc.,) and relatively busy periods (four players in the game; each tapping, matching and flicking as fast as they can).

Polling is the obvious starting point - PHP and HTTP fundamentally lend themselves to request/response type architecture. However, if we we're to naively poll the server for game updates throughout a multiplayer game (say every five seconds) we would end up sending a lot of redundant requests, consuming a lot of mobile data and actually producing a significant delay between an event occurring and the players being notified.

The solution we used was ‘long polling’. We created a custom controller that delivers messages when polled, but where there are no pending messages it doesn’t return immediately, instead it keeps the connection open for as long as practical. This way as soon as a message needs to be broadcast the connection is already open and the message can be sent immediately. If there are no messages for a long period of time (30 seconds) the server then returns this and the client can immediately poll again. This means we can poll as little as twice a minute (saving traffic) and still get responses from the server in less than a second.

Obviously for World of Warcraft-like numbers of players or Crysis-like levels of action, PHP isn’t going to cut it, but with 3-4 players in medium paced and competitive little games, it works perfectly fine.

(Another solution might’ve been websockets, which are very interesting to play with, however our ISP – who shall remain nameless – blocks websocket connections so this wasn’t an option).

We have found by using SilverStripe to build the server for this game, that whilst the Framework and CMS are excellent tools for building websites, they are just as effective and flexible to be used to program a multitude of other applications.

We regularly use SilverStripe to provide data to our mobile applications, but this is the first time we’ve pushed it further to add multiplayer game play and dropped the web front end entirely.