What would the architecture of a social media enhanced roleplaying game look like? This article attempts to answer that question as well as provide some ideas on how to implement comparable controls across many dissimilar social networks. This is a continuation of the discussion initiated by Jonathan Jacobs with a post at The Core Mechanic[1] and my response[2] from yesterday. If you haven’t read the first two articles, I encourage you to read them before continuing.
In Bridging the Gap, I explored the possibilities of how to embed a roleplaying game into social networks while still maintaining the elements which define roleplaying games. Today, I wanted to look at the technical hurdles of actually implementing such a game.
Core Technology
There would need to be a central hub where users would create accounts (and register the social networking accounts of their choice). This would ideally be a website (with a mobile version) that would offer the most powerful and comprehensive tools available for the game: character generators, virtual table top, chat, audio/video conferencing, campaign wiki, searchable databases of resources (rules, monsters, character options), etc. It would be the DDI[3] that should have been.
Network Penetration
One of the goals of a social media roleplaying game (SMRPG) would be to hook into as many social networks as possible. This has two large advantages: presence and accessibility.
Wide network penetration would establish a highly visible presence that can help draw users in. Game data presented across networks would obviously be branded (think about an “updated from SMRPG 5 minutes ago” tag), so anyone playing the game would be advertising it for free. Even though the platform would have at least some monetization, the goal is not about money, it is about building a user base (the money comes a natural by-product).
The accessibility means that players can retrieve information in the fashion which most suits their current online behavior. It means they don’t need to create yet another account or buy into the latest cell phone fad or purchase expensive data packages. Chances are they will already have something that works with the platform.
There are also a number of social media networks that would not necessarily enable player participation but rather could be used as tools to enhance the game itself. Examples include embedding custom movies you have uploaded to YouTube for introduction or cut scenes (like a custom Star Wars Crawl[4]), taking advantage of Pandora[5] or Last.FM[6] for mood music, or using Flickr[7] to host maps. These social media networks can be instrumental in offloading both functionality as well as storage space, making the platform cheaper to host.
Functionality Limitations
Of course, the more networks the platform hooks into, the problems with maintaining equivalent functionality across those networks. The Application Programming Interfaces (API) will not support the same functions and some networks will be more powerful than others.
It would definitely be a challenge to be able to replicate all the controls that are available on the Facebook[8] SMRPG widget in Twitter[9]. For one, there are a few dozen clients that people use to interact with Twitter and asking them to use a new client might not be easy.
Yet, Twitter might be able to be used as a primitive command line interface for an SMRPG. I can imagine utilizing keyword hash tags to accomplish actions that are recognized by the game engine. Of course, Twitter could also just be used as a text dump that the game uses to publish concise descriptions of current game activity. Obviously, the platform would need to understand each network’s strength (comprehensive communication is not one of Twitter’s strong suits).
Platform Components
The diagram to the right illustrates very simplified, top level view of a possible SMRPG platform. Each block is really a distinct architecture that would likely be comprised of several smaller modules. The foundation of the platform would be a massive database which would store all the characters, current progress, adventures, activity logs, images, rules, and whatever else necessary to run and record games.
The next layer up from the database is the business logic, which in this case is the game engine which validates of all the data coming in and out of the database against the rules and saved user preferences. The logic makes sure Suzie’s action resolves before Larry’s because she has the better initiative (or waits for GM approval before continuing).
The layer above the game engine is dual interpreters; one that handles incoming traffic and one that handles outgoing traffic. These interpreters ensure that the data received from the client interface is formatted in into something the database will understand and vice versa.
Everything up to and including the interpreters would most likely be built within the database itself using a combination of stored procedures, triggers, and data transformations all reacting to inbound and outbound data. The next layers would most likely be services or daemons that wait to relay information to the appropriate destination(s).
The client interface communicates with the social networks asynchronously, sending and receiving information as needed. The interface would likely be comprised of processes that interface with network APIs. Finally, the very top layer is the social media networks themselves which may or may not need additional front end user interfaces (most like things like Facebook widgets).
Conclusion
My possible SMRPG platform is essentially a product of quick and minimal brainstorming and I thought of additional detail and design improvements as I was writing the article. A project of this scope really would entail a lot of work and starting capital to really apply the support needed to launch such a platform. Thus, I wouldn’t expect to see anything like this realized from with the traditional roleplaying game industry.
The Core Mechanic continues the discussion of social media and roleplaying games in Social Media Role Playing Minigames.
References
[1] Roleplaying Games, Social Media Games, and the Shared Fence. The Core Mechanic. 2010-01-12.
[2] Bridging the Gap: RPGs and Social Media. Mad Brew Labs. 2010-01-14
[3] Dungeons & Dragons Insider, an online suite of tools available for subscription.
[4] Ten Minute Star Wars Crawl. Mad Brew Labs. 2008-09-21.
[5] Pandora, automated music recommendation and Internet radio service.
[6] Last.FM, an internet radio and music video site.
[7] Flickr, an image and video hosting site.
[8] Facebook, a social networking site.
[9] Twitter, a micro-blogging service.
Two interfaces as well – one for players and one for GMs. Going back to the old Neverwinter Nights game might be worth thinking about. Also, the players interface would have two modes (at a minimum) – game table mode where the PCs are actively involved in group play and minigame mode where the individual PC for the player is engaged in a variety of minigames that can be played away from the (virtual) table. Also – for real flexibility – there should be a mode where the game can be updated in real time as it is played at the table using traditional table-top roleplaying. Perhaps the GM clientsoftware could fast forward the story (“OK, we left the town of Munchkinville and now we are in the wilderness travel to Whatchamacallit Land.”) THe next time the players chekc the forums, FB page, iPhone, twitter feed, or whatever interfaces that are supported they cn continue the story from there until they all can meet up again at the game table.
.-= jonathan´s last blog ..Social Media Role Playing Minigames =-.
@Jonathan: There would definitely have to be a lot of thought about how time is managed, especially when dealing with events where timing is an issue (combat).