In the July RPG Tech Talk column, I talked about the concept of the Open Roleplaying Platform, or ORP. Briefly, this is the concept of a suite of software tools that together form a viable platform for computer assisted table-top roleplaying. A key feature of such a platform is that it is ‘Open’ ,and that multiple products could be offered to provide various components of the system, unlike the all-or-nothing approach of current products.

So what does this mean in practice? Well, let’s take a look one classic requirement (or use case, as we say in the trade…):

Rolling dice is a key component of any game, whether it is the simple classic six-sided die used in a game of Snakes and Ladders, or the combinations of polyhedral dice and ‘modifiers’ used in many table-top role playing games. In essence, dice are a tried and trusted method of introducing chance into our games.

In software terms, ‘rolling’ a die is pretty simple – simply producing a random number between 1 and n, where n is the number of sides. You can achieve that in at most a couple of lines of code in most modern computer languages. In roleplaying terms however, there are a multitude of modes in which such functionality might be used:

• Dice roll entry: a gaming group might still want to physically roll their own dice (let’s be honest, this is one of the most enjoyable actions RPGs, as your damage dice clatter across the game table…), but they want to utilise computer tools for other aspects of the game (e.g. Combat and damage tracking). All they need is a simple utility app to enter the results of their roll.
• Virtual rolling: in lots of cases you might want the software to hide the actual roll. For example, if you have an initiative tracking app, you might want simply to click once to roll initiative (including modifiers) for combatants in the encounter, and have them magically sort into the correct order!
• Snazzy Dice Rollers: there are a plethora of lovely 3d dice rollers out there that can simulate the physics of dice rolling (e.g. check-out the Apple App store). You might want to use such an app on a iPad at your gaming table, but have the results automatically appear in your Combat Manager app.

There are many more possibilities I’m sure, but I think you get the point: in each case,  what is required us consistent – the game rules require a die, or a group of dice, to be rolled and produce a result; however the how and where are markedly different.

In enterprise software, a service implies a contract to provide certain functionality, but allows for significantly different implementations to be provided that can be used seamlessly by a client application. So here, we have the concept of a Dice Service.

This is of course similar to the concept of the interface vs the implementation in object-oriented languages (C++, Java etc), but the key difference in enterprise software development is the potential to integrate service implementations across different  language and OS platforms, as well as different physical or network locations. It also allows flexible choices to be utilised in the client application. For example, a GM might want all the dice rolls for his monsters to be generated automatically, whilst all his players’ rolls are conducted via real dice rolls, with a smartphone-based entry app. Because the Dice Service contract provides identical results for the client app, regardless of which implementation is used, this can be easily provided as a selectable option.

Another advantage of a well-defined service model is the potential for the growth of a community of service providers. As a developer, my primary experience is in server-side enterprise software architecture using Java – I’m unlikely to turn my efforts to a 3d simulated physics dice roller – but there are plenty of developers out there who can (and have!). If they can be persuaded to implement the ORP Dice Service contract, suddenly there’s another great addition to the platform.

Next time, we’ll take a look at other potential services in the ORP!!