Posts Tagged open source

Tabletop Roleplaying over the Internet

I have been playing tabletop roleplaying games since a fateful day when I was 13. I had gone with a friend to play Magic: the Gathering at a local video game shop that also happened to sell Magic cards. One of the players mentioned a gaming group starting up at the local Media Play.

Curious, my friend and I got a ride over to Media Play. There, I found a pretty large group of people playing Magic. I also saw an interesting sight: some people with books, funny shaped dice, and little painted figures arranged on a square grid. I watched for a few minutes, and quickly got the gist of what they were doing. I asked if I could join. The response? “Sure, we need a cleric.”

Thus began a hobby that has spanned half my life and cost a great deal of money. I have played a number of systems: World of Darkness, Cyberpunk 2020, Shadowrun, Rifts, Call of Cthulhu, Star Wars (the older edition that used d6s), homebrew systems created by various friends. But I always come back to D&D. It was my first system, and it remains my favorite through three editions of the game. In a lot of ways, it has grown with me.

In the last few years, though, I haven’t had many chances to play D&D. I was skeptical of 4e at first, and then spent a lot of money buying 4e books after Alexandra Erin convinced me of its merits in her repeated, impassioned blog posts about it (all of those links are excellent reading, even if you already know you like 4e). I sat on these purchases for months, planning games, even getting some people to make characters. But no game formed; the other players either didn’t have free time, or I didn’t have free time, or we were too far away.

The Search for a Gaming Table

Eventually I found a little free time to bring a game together, and since I couldn’t solve the problem of my friends’ lack of free time, I started looking to solve the problem of people who had free time, but were too far away. So I started looking for a solution to playing D&D over the Internet. Namely, what I needed was something known as a virtual tabletop. I started out with simple requirements: free is good, open source is even better. Since there was no good overview or comparison of the existing virtual tabletop options, I decided to make one. I’ll describe, briefly, why I didn’t pick each one (until I get to the one I *did* pick, of course).

OpenRPG – frustratingly deprecated

Years ago (about 10 of them), I tried using WebRPG as a virtual tabletop. I remember it having a somewhat cumbersome and over-engineered interface, and being frustrated with it on many levels. Still, it was the first thing in my memory, so it’s the first thing I looked up. Turns out it went open source a while back, and is now called OpenRPG.

Unfortunately, this was a non-starter. OpenRPG is written in Python (yay!), but doesn’t work with Python 2.7, which is the de facto standard in Fedora. I didn’t want to maintain a separate Python install for just one program (this is possible, but would be a pretty big hassle to set up), so OpenRPG was a bust.

Screen Monkey – expensive and cumbersome

The next program I discovered was Screen Monkey. Once again, Alexandra Erin was instrumental in this – she mentioned using it for her online games. Screen Monkey has one big advantage – for the players, it is browser based, so only the DM needs to install any client software. Unfortunately, that software only runs in Windows. So, I found an old install disk for Windows XP, and installed it as a virtual machine using KVM. Then I installed Screen Monkey Lite.

More bad news, though. Screen Monkey Lite turns out to be rather light on useful features. The biggest problem is that you can’t save your work – you have to buy the $35 version of the program to save and restore a session. The tools for hiding what the players can see was also fairly awkward. Awkward, in fact, is the word I would use to describe the program’s feeling as a whole. NBOS are terribly proud of their software ($35 proud) only to be outdone by multiple free and open source competitors. Sounds like some other software companies I know.

Gametable – RIP

Gametable looked promising, but doesn’t seem to be actively developed (there was a sourceforge project available a while back, and remnants of it are here, but it seems to be dead now), and it didn’t work very well for me.

Fantasy Grounds – pretty, but overpriced

Next up is Fantasy Grounds. I didn’t even try the demo once I saw the price tag – $40 for the DM-capable client, and $24 each for the players’ clients. One of my hard requirements is that my players not have to spend any money on the solution, so this one was right out. For a more affluent group, though, it might be a great solution. I will concede that it is gorgeous, and looks very well polished. Certainly a better contender for your money than Screen Monkey. And it has acknowledged, if unofficial, plugins for various game systems, including D&D 4e.

MapTool – the right balance

Eventually, I found MapTool, one of the applications created by the RPTools team. MapTool originally didn’t impress me – it seemed cumbersome and unwieldy. After working with it for a while, though, I found that most of its design decisions make sense, and that it is very powerful. Like most powerful toolkits, it is subsequently pretty complicated, and using it effectively took some practice. However, once I got the hang of it, it’s unbeatable. It’s more stable than any of the other open source offerings, and it runs well out of the box. It lets you use fog of war, individual player views (based on available light sources), and it lets you make maps in advance but have them hidden from the players until you are ready to show them.

Also invaluable was Dorpond’s 4e framework. This is a set of configuration settings and macros that work together to make MapTool work well with the D&D 4e rules. I have modified his macros a bit to fit my particular play style (notably, I prefer to let players roll their own initiatives), and am continuing to do so as I playtest them. You can find my latest version of the framework here.

Also, three caveat with maptool:
1. The network functionality doesn’t work with OpenJDK. Linux users will want to install the Java JRE instead. In Fedora, I just installed the jre RPM from Sun’s website, then edited MapTool’s startup script and added ‘export JAVA_HOME=/usr/java/default’ and ‘export PATH=\$JAVA_HOME/bin:\$PATH’ near the top of the file.
2. When starting a server, if you do not select ‘Use Individual Views’, the GM will not see an accurate version of the player’s view.
3. When you have tokens in the initiative list, players can only move their token on their own turn. Trying to move when they don’t have initiative will send them into an annoying endless loop of NullPointerExceptions. I’m hoping this gets fixed soon by the MapTools team, because it’s an obnoxious bug. Luckily, MapTools is Open Source – I may take a crack at finding that bug myself.

D&D Virtual Table – still cooking

Wizards of the Coast has recently announced a beta version of their own virtual tabletop – called, simply enough, D&D Virtual Table. It is only available to select D&D Insider subscribers. And, since D&D Insider is not worth the price for me personally (a topic worthy of an entire post unto itself), I have no idea whether it is any good. It would also certainly require every player to have their own D&D Insider subscription, so it breaks my stated rule. Still, it might be something to keep an eye on.

Adding Voice

So, now that we had a game table, we needed a way to talk to each other. Luckily, there is a readily available, cross-platform solution to this: TeamSpeak. Now, TeamSpeak isn’t open source, and it is not free if you want to host multiple teamspeak servers on one machine (or have more than 32 clients connected). But it’s great for a D&D game, which would never need those resources. It’s dead simple to set up the server in Linux, and the permissions management is very intelligent (and again, dead simple).

Let’s look at the options I didn’t choose for voice chat: Skype relies on a central server, and has a history of iffy privacy practices. Ventrilo offers a Linux server, but no Linux client. And the voice chat available in various Instant Messaging programs is either unreliable, or doesn’t work in Linux either. So, TeamSpeak it is, and it works great.

Passing Notes

The last thing I needed was a way to present textual information to the players. I do a lot of world-building and writing background material, and I want to make sure that is available to the players (at least, the publicly revealable parts). I also want to be able to give them things like notes that they might acquire, and possibly conduct some roleplaying between sessions if a session ends during downtime.

There are plenty of ways to simply share files, and these would be adequate. Dropbox could be used, especially for image files. Google Docs seemed like a pretty good way to share documents with players. After considering it for a while, I discovered a site called Epic Words. Epic Words gives you a journal system, so players can post in-character summaries of game sessions; this also works well as a means to deliver chunks of story-based text such as notes, riddles, etc. in a way that the players can easily access and remember.

Epic Words also has wiki-like functionality, and lets you define “references”, including NPCs and places, that will be linked automatically when mentioned in a blog post. This is an especially useful feature, because it lets me, as the DM, add content to the players’ writings without actually changing their creative work. It also gives you a private forum, which is perfect for the kind of between-session downtime roleplaying I have in mind.

Epic Words’ biggest problem is that it only allows you to run a single campaign without either upgrading, ‘retiring’ the existing campaign, or deleting it. And even with the upgrade, there doesn’t appear to be a way to share references / wiki content between campaigns (I don’t know this for sure, because I can’t really test that, but it appears to be the case). If I were running multiple campaigns, there is a slew of generic world history and other setting information I would like to share between campaigns. If you could make wiki pages independent of campaigns and then ‘link’ them in, that would be ideal. As it is, I happen to only be running one campaign at the moment, so I will have to cross that bridge if and when I come to it.

Final Thoughts

In the end, I ended up using three tools to interact with my players: MapTool, TeamSpeak, and Epic Words. I like this solution because it is very Unix-philosophy friendly – each tool serves one purpose. MapTool acts as our tabletop, TeamSpeak is how we communicate, and Epic Words gives us a handy place for wrap-up/reference/between-session play. The overall experience is pretty excellent; this is a good way to play D&D. It is better than I was hoping for, and even surpasses actual face-to-face play in some ways (I would love to find a way to use MapTool with a projector for face-to-face play).

Comments (3)

Then They Fight You

Microsoft threatens to sue the entire FOSS community

Where have I seen this kind of threat before? Hmm… SCO, anyone? Is MS really desperate enough for that? SCO only sued IBM because they were losing money in copious amounts, flirting with bankruptcy. Vista seems to be the straw that’s breaking Microsoft’s back.

Leave a Comment

Decentralizing Second Life

So, I’ve been thinking about Second Life, and it occured to me that it’s being done entirely the wrong way. Don’t get me wrong; I enjoy SL, and have no qualms with the experience itself. It’s the underlying scheme it’s built on that bothers me: one company controlling all the servers, one company responsible for keeping everything running smoothly. It seems to me that all technologies built on that model eventually fail on the Internet, while distributed technologies (Web, email, usenet) thrive.

To that end, I’ve been thinking about how Second Life could be successfully decentralized, without adversely affecting the experience that everyone has come to know and love. I’ve identified key elements of the user experience that would be difficult to decentralize, and possible ways to handle them. First, though, we’ll talk about the basics; how could decentralization even work.

First, LL releases the code for the Second Life server. Now, anyone who wants to can host a Second Life sim/sims of their own on a server. A central repository would keep track of the existing sims, in a vaguely similar fashion to DNS (see The Grid, below). This would allow Second Life to grow without bound, with sims run by a multitude of companies and even home users.

So, how do we keep that Second Life experience without the centralized monolith of Linden Labs?

Economy
First and most importantly, the Second Life economy must be preserved. The economy has become the most crucial element to the experience; the ability to use real money, diluted down to a virtual quantum, to purchase other users’ custom created content. This breaks down into two sub-problems:

a) Managing the money. The most likely way to do this would be to set up a “bank”, wherein a single host (or several different hosts) manages all of the banking transactions. I’m thinking basically a system like paypal, where you buy L$ (“Linden Dollars”, Second Life’s currency) from the bank, or sell $L back to the bank for real currency. Each SL server would use this central bank system to check a user’s account balance, and make withdrawals/deposits, with proper confirmation on the part of the user, naturally. A public/private key system to ensure the user actually sent the confirmation could prevent abuse here, so no worries on that score. The SL bank could even be controlled by Linden Labs, as this would be a lot easier to handle than the entire grid, and still give them opportunity to have a strong stake in their creation.

b) Protecting Intellectual Property. This is a tricky problem, and the single hardest element to decentralizing SL. Since a huge portion of the money in SL is traded for users’ creations, there must be a way to prevent them from being stolen. Under a decentralized scheme, when a user rezzes an object on a sim, all the data for that object (textures, sounds, scripts) would necessarily be available to the owner of that sim. The most obvious solution I can find for this is to keep the object data elsewhere, and have a rezzed object be a pointer to that data. The advantage is that compiled scripts, raw texture data, and sound files stay on a secure server independent of their rezzed location. But where is this mystical server? I see two options here: either the data is on another sim, perhaps the user’s “home sim” (see User Accounts, below), or the data is in a central “asset server” (essentially the way SL works right now). Using the former approach, the client would have to make tons of connections to different servers to get all the data. Under the latter, the asset server would have to be extremely load-tolerant and robust, and all the data is stored by the same group of people, whose ethical integrity the SL user base would have to trust implicitly. Since both of these are flaws in the *existing* Second Life system, however, it is acceptable for the hypothetical exercise we’re attempting here. Also, under either system the sim owner’s creations could be stored on-sim for lower lag.

One other solution would be to create some DRM scheme that encrypts this data until it reaches the client. Of course, in all of these cases the client could be modified to steal the data. However, here we again reach the fact that these flaws are already inherent in SL, and there’s no easy way around them.

The Grid
The ability to bring up a map and scroll around, or teleport instantly to another part of the world, is an exciting part of SL, and another crucial part of the SL experience. Fortunately, the Internet already has a great system that we can build on – DNS and hyperlinking. We simply define 2 kinds of link: “landmarks” and “neighbors”. Each sim can have 4 neighbors, and neighbors must mutually agree to be neighbors (for a neighboring to work between sim A and B, A would have to set B as a neighbor and vice versa). The neighboring agreements would be stored in a central server system, modelled on DNS. A few recursive calls to this system and each sim can cache a portion of the overall grid map. Want a private island? Simply don’t neighbor your sim with any others. This creates user-level “peering agreements” that could create a more logical terrain (snowy areas linked together, etc) even if the landscape does shift from time to time.

The other kind of link would work just like landmarks in the current SL system. Pretty self-explanatory, except this system would make “click to teleport” objects a necessity, finally.

If a user searches for a sim on the map, the client can grab that sim’s cache of neighbors, and display more of the grid. The client could be configured to keep any amount of that information cached locally, for a more immersive experience.

User Accounts
There are two ways to handle user accounts: a centralized account server, or a sim-based account system. Under a centralized server, all accounts would be handled by, say, LL. This simplifies the system greatly, and aids in managing the asset server. With “home sims”, you’d have a system similar to Jabber, where user accounts are essentially user@home_sim. I believe the centralized system will work best, given that the asset server system seems to be the most logical way to do things.

Instant Messages
Well, LL is currently planning to re-implement the IM system in Jabber, so we’re pretty much covered there :P

So, in summary, we have a system that uses a centralized server for accounts and user-created assets, as well as a DNS-like neighboring system to create the world map, but grids are controlled by individuals, and hosted by companies just like web servers are now.

Comments (1)

Related rant

I have a Free/Open Source software related rant posted over on my personal journal. It’s vaguely related to this journal’s purpose, hence the link. Enjoy :)

Leave a Comment

Follow

Get every new post delivered to your Inbox.

Join 136 other followers