I’m opening the second Phyre beta tonight at 10:00 Eastern as soon as technical problems are dealt with, with a host of awesome features.  Among the goodies are:

• Live, editable chat with in-character and Out-Of-Character posting
• Private note-taking, publishable to notes the whole table can read
• Dice that are really, seriously random
• Character sheets from templates
• Make your own templates
• GM controls
• and lots, lots more!

Seriously, that’s just scratching the surface.  Phyre is crazy good and you need to try it.  There are bugs, but those are going away quickly and will be gone even faster if you report them.  There’s a bug-report button right there.  It takes like five seconds.

I would be equally interested in hearing what features we don’t have that you want.

Phyre currently supports the following browsers:

• Chrome
• Firefox
• Safari
• Internet Explorer 9

If you’re using something else, try it and see.  If you’re using Internet Explorer 8 or earlier, upgrade.  Other than the browser, you won’t need any plugins – though if you’re running with JavaScript off you’ll need to enable it.

But enough about that.  You should probably figure out what campaign you’re going to run.

The layout on this landing page is the only part that’s unaffected.  This is because the hacks I used to make the text wrap properly around Minerva is really, really fragile and by altering the positioning logic that breaks completely.  I’ll take another crack at it later, but for now I need to allocate my time more wisely.

It’s clear to me now that my decision to start the Phyre beta last month was really, really immature.  The sheer number of bugs that I’ve discovered since then are terrifying to behold, and it’s clear that only my very specific (and surprisingly, highly regular) usage patterns could get through typical use of the site without game-breaking errors occurring.  I’m chagrined, and I’ll do what I can to keep this happening again.  Sorry, I’ve never tried to release software before!

Once again the tactical map has slipped.  I don’t want to imply that I don’t know how important it is, but I can’t ignore that it, well, just isn’t that important to me.  My playstyle doesn’t work well with battlemaps, and it seems ill advised to add a feature that i won’t be testing as part of my daily routine when I’m still finding and fixing so many problems elsewhere.

I’ve created a bugtracker. Please don’t hesitate to use it.  You don’t need to sign up or log in, it just works.  The bugtracker is the absolute best way to get stuff fixed or ask for a feature.  If you aren’t in the Phyre beta right now, well, that’s probably for the best.  We probably won’t be actually, seriously beta quality for a couple weeks.

Obviously, that’s not acceptable.  I don’t really know how I put up with it as long as I did, other than that I just didn’t know how to fix it.

It’s kind of bittersweet, though.  I’ve ripped out about 300 lines of iFrame-specific code, and replaced it with about 40 lines of jQuery AJAX magic.  It’s nice and it’s slick and for the most part I’d abstracted everything enough that changing stuff in the JS library made navigation Just Work again. Still, it’s a wrench throwing out so much work (old work – the iFrame navs were put together in 2008.)

The downside here is that now I need to do something so that Phyre behaves rationally in the presence of forward/back controls.  Currently it’s completely history-opaque, so if you click on the wrong sheet and hit Back you go back to Google, or whatever.  Not cool either.

Silver lining: this actually fixes about half of my existing problems with the iPad version of the site.  iDevice rotation events don’t seem to propagate to iFrames properly, either through Javascript or via MEDIA-selected stylesheets, which is rubbish.  I guess in the case of iFrames deprecation is in full effect.

As an aside, I’ve finally had to switch from a PG4WP-wrapped WordPress instance to a standard one.  I’m pretty sure the old one had been compromised, and it wouldn’t let me, um, make blog posts.  Which is pretty important for a blog. It sucks because MySQL is running on my much slower development server, and that means loading time on this landing page is compromised.

Ugh.  Part of the reason I’m so unfocused is because there’s so much to do right now that Phyre could keep three coders busy for the next month full time.  The other part is because, um, I’m just unfocused.  But I still really wish I could afford to hire help.

As much as I would like to believe otherwise, Phyre is not an original idea. There have been numerous tools like it, all of which aim to “solve” the problem of RPGs online. There are even a few people who think that the whole idea is ludicrous, that if you have a computer at your disposal you can just play video games so who cares.

I obviously don’t buy that line one bit. RPGs are awesome, and I have without a doubt spent more time roleplaying than I have playing video games. And the bulk of that has been, appropriately enough, online!

In the summer of 1999 I visited my grandparents in California. Though the specifics are lost – I was about 12 at the time – I somehow found myself at a small, dimly-lit shop which sold all manner of roleplaying supplies in addition to the standard array of miniatures, fake trees and foam hills, and Magic cards. I was enthralled, and with the $20 in my pocket I oggled the boxed adventure games for nearly ten minutes before asking for the Dungeons & Dragons set. It was that or the Diablo RPG, you see – it could have gone either way.

The lady at the counter told me that if I could come back next week, they’d have the “three-ee” sets in. I explained politely that I would have gone home by then and that the second-edition set would be very fine, please and thank you. With the sort of look that city people give strange
children who are too pleasant and don’t know what they are buying, she acquiesced. And so began my love affair with a social hobby that is usually enjoyed in basements, by antisocial young men wearing cloaks.

I was excited as anything, so obviously I wasn’t going to wait until I got home to play. So when I tried to play with my brother, at my grandmother’s house, over the large dinner table – things didn’t go well. Though excitingly illustrated, the character sheets were filled with arcane calculations that I could scarcely comprehend, let alone calculate, and the rulebooks were paradoxically both pregnant with possibility and illegible in its presentation. It was a struggle, and I think we got as far as the discovery of Ironstone’s Dog before dinner was ready and we had to set the table and what were all these things doing on the table those are the strangest little dice, what, why are there so many pencils and that was that.

After that, it took me about four years to find a group to play with. When that happened, it was with kids about two hours away by car, and we got to play maybe every third month. It wasn’t the best thing ever, but I lived in the middle of nowhere. What was I going to do about it?

And more than anything, that’s the biggest problem with the hobby today. Forget about market saturation, forget about segmentation – if the reason you aren’t playing is because your group can’t settle on 3.5 versus 4e, you just don’t have a GM who’s interesting enough to remind you that it doesn’t matter. No, the real problem is making games happen at all.

The first version of the setup that would become Phyre was simple: a page with a pJirc client embedded, and an iframe referencing a forum. It was almost slick, and my group was suitably impressed. You could seriously just open it up and type stuff. I added some greyed-out text below the chatbox, explaining some basic IRC commands like /nick and /join. I set up a mIRC dicebot. Man, I was clever.

And it was a failure. It turned out that Alex’s computer didn’t have Java installed. We tried to make it work properly, found out that AOL didn’t actually let that sort of funny business happen, and then Keith’s machine decided that the iFrame should point to Google and nothing we could say would convince it otherwise. Damn.

Over the years my solution changed many times. CGI-IRC? Latency problems, plus it sometimes just eats posts. mIRC for everyone in the group? Apparently some of us couldn’t install software due to system policy restrictions. Oh, and one guy was on a Mac. Eventually It became apparent that even with client issues aside, IRC was just too complicated for most of my players to enjoy.

And so, eventually, it comes to this. Though there are loads of solutions to this problem, they all either run on Java, are costly and proprietary, or just don’t work right. It is a problem so intractable that I had to learn about arcane nonsense like variable scope and SQL injection to solve it properly. And now, you won’t have to.

I used to assume that, since gamers are smart people, they could figure out a complicated solution. I was wrong, though not about gamers being smart. They are, you guys are often brilliant people, but – crucially – not about making The Internet behave properly. And now you don’t have to.

And now the rest of you can do what you’re best at – tell thrilling stories, have amazing adventures, and roll the strangest little dice.

You guys are awesome.

IRC is short for Internet Relay Chat, a protocol that has existed since roughly 1620 and is notable for being the medium through which Richelieu and D’Artagnan negotiated the signing of the Magna Carta (itself a treaty that was important because it led to the legal creation of America,) which should give you an idea of just how old IRC is. Many, many online roleplaying groups use IRC, and though claiming that they’re the majority might be wrong it remains incredibly popular.

This is partly because of the protocol’s age, which means that an IRC client can be found for basically any computer or phone – but it also means there are drawbacks, like that it has a long and vibrant history of exploits and hackery. IRC is not and never has been particularly secure, and supporting it makes preventing name spoofing and other villainy kind of difficult. Switching to a homegrown solution would alleviate all of these issues.

But getting rid of IRC has its own drawback. Many existing groups already use IRC, and for a lot of people trading in a utilitarian chat app for a browser-based web app isn’t appealing. I get this – in fact, one of my group’s founding members is a diehard IRCer who does all his roleplaying from a textmode console in Linux. Heck, I still roleplay with xchat now and then, especially on my netbook (which despite being purpose-built for the Internet, doesn’t do Internet very well.)

So to a large extent I feel like I’d be crazy for dropping IRC. And yet, all the features I mentioned in the opening paragraph are going to be infeasible to implement in the near timeframe and with any degree of reliability. I would need to make a number of change to the IRC server’s core code, which means – assuming everything worked and I didn’t introduce crippling timing issues or crashes – means that, at best, I would have one more piece of software with proprietary changes that I’d have to continually merge back as the developers improved the original software. Not good.

The third option is to do both, to use a homegrown chat system but allow IRC chat on a per-game basis. This may be what I ultimately go with, although it rather nastily increases the workload ahead.

I was hoping to get it working in 8 as well, but it’s looking like that will be prohibitively difficult for now.  Basically none of the CSS works, and for some reason IE8 gives typeface.js fits.  Well, that sucks.

But according to our stats package, only 23% of you are using Internet Explorer at all – and of those, 19% are already using IE9.  That’s pretty fantastic, because compared to earlier versions IE9 is almost civilized.  All told, just 5% of this site’s traffic is with a legacy IE version.  And that really isn’t worth developing against when there are so many legitimate bugs and missing features!

So going forward, you should assume that IE8 support isn’t coming.  Maybe in the future when things have settled down, I’ll throw together a minimalistic template for the cavemen.  Sorry, cavepeople. Don’t want to be insensitive.

Just don’t count on it.

In any case, here’s a new and updated compatibility chart:

Works well:

• Firefox 3
• Chrome
• Internet Explorer 9

Works with visual issues:

• Opera 11
• Safari iPhone
• Probably Safari Desktop

Does not work:

• Epiphany (Javascript entirely broken)
• Internet Explorer 8 & below

Howdy, guys-

We’re working to address some compatibility issues right now, specifically with Internet Explorer.  I should state up front that making IE behave will never be a priority, but that said I’d like it if it at least mostly worked.  I’m going to tentatively project that it should be running in IE9 by tomorrow, and maybe IE8 as well.

Here’s a list of compatibilities:

Works well:

• Firefox 3
• Chrome

Works with visual issues:

• Opera 11
• Safari iPhone
• Probably Safari Desktop

Does not work:

• Internet Explorer 9 (Chat is broken, other elements mostly work)
• Internet Explorer 8 (Totally broken)
• Epiphany (Javascript entirely broken)

Never to be supported:

• Internet Explorer 7 & below

Except that isn’t quite true – as was mentioned earlier, it’s not actually called that anymore.  It’s Phyre, because, as you might imagine, it’s rather hard to name something well when all the words that describe it revolve around dice, erasers, and pretending you’re an elf.

Anyway, as of right now Phyre is a usable system.  The only piece that’s missing wholesale is the battlegrid, which needs a bit of attention before it joins the gestalt.  I’m hoping that won’t matter; I intend to have the grid back within the month.  We’ll see what happens.

Right now I am looking for a few groups to begin beta-testing, ideally groups that plan to meet and play at least once a week. If that’s you, or it sounds like it could be, drop me an email at wk@eurge.net.

If you’re an individual, that’s okay too.  You should also send me an email, and I will see if I can’t find you some folks to play with.

I’m excited.  I hope I’m not getting ahead of myself!

-WK

…Yeah, I know.  I’m sorry.  It seemed like a good idea at the time!  As far as I could tell from sort-of exhaustive googling, flatfile wasn’t all that slow.  As of now, I’m not really sure about the speed – it sure SEEMS faster now that everything’s humming away inside postgres, but given the time expended in making that happen I’m pretty much required to feel that way.  Overall I suspect it’s a wash, but that will probably improve once

a) usage increases past current 1+1 concurrent users, where the first 1 represents me and the second 1 represents a second browser open logged into another account to test concurrency
b) I get around to implementing searches more advanced than games-by-name and “ID” .

When I started organizing the data into MySQL – yeah, I started with MySQL and switched to Postgres halfway through – I realized just how powerful a database was.  I’ve worked with them before, usually hacking new features into existing software like PHPBB or CMSMS, but the flexibility it’s given me here is astonishing.  It’s hard to explain it if you aren’t used to arguing with a computer through a parser, but being able to update a given snippet of data without needing to read the entire record, edit the relevant bit, and write it all back is a boon.  Imagine needing to print out a copy of your calendar, update it with pen and white-out and then scan the whole thing back in each time you wanted to add or remove a date. Now imagine not needing to do that anymore.  (It must be weird imagining you’re such an eccentric dude.)

Now, I had the data laid out more or less responsibly before, flatfile or no.  Each user had a directory with a definitions file containing their password hash, permissions, email, and so on.  That directory had a directory for character sheets and sheet templates.  Adding a character to a game involved creating a symlink between the character sheet and the game’s directory, and joining a game meant linking the game’s directory into the user’s games/ directory.  It was all reasonably not-terrible (I tell myself) for a flatfile solution, and for any given lookup the system would be no further than six or so lines from the relevant data from the initial read.

The problem was that looking data up by anything other than name was an unbelievable chore.  Want to get all the users of a given level? Open every single user, parse their data and make a table of their levels, then return the array.  Want to search game descriptions? Do what you did a second ago but open bigger files and then loop through string comparisons for however long feels appropriate.

In order to make listing games by name less than a complete chore, I’d (in addition to the actual storage system where games are all in a directory listed by “ID” number) had a second lookup directory where game directories were symlinked to their names.  Some games are public and some are invitation-only, so in order to make that distinction visible on the listing and search pages I had to add a symbol to the end of games which required an invite.  To facilitate browsing games by tag, I had another directory with subdirectories representing each possible tag, and linked game-names into those as well.  This means (if you’re counting) that a game actually had a minimum of two filesystem objects, plus one per tag the game possessed.

It was somewhere in the middle of writing a complex locking system to prevent a game’s metadata from being corrupted when reads and writes occurred at inopportune times that I muttered something like “Fine, FINE, I’m doing it already, Mom” and opened a new database on the server.

By the way, as much as I liked to pretend in certain earlier posts I’m the only person involved in developing Luminar (name change soon.)  I’m only sort of even a professional, but boy howdy do I ever procrastinate like one.

Security is tricky.  The user’s actions, though initiated by the user and submitted by the client software on the user’s computer, are actually carried out on the server.  The server has control over everyone’s data, which is where privilege comes into play.  If I try to delete a sheet, should it let me?  The server should check to make sure that my account either owns or has write access to the sheet, that the sheet isn’t shared exclusively with anyone else, and that my account actually issued the delete order.  The problem is, the server needs to be specifically told to do this.

The situation gets more problematic when you’re developing, because the underlying security model (“Who can change what data, and under what circumstances?”) can change a lot, or God forbid isn’t really that well defined to start with.  Since I’m a tool, this latter case is what is going on here.

Ironically, this is (yet) another reason why Luminar and TikiWiki didn’t work out together.  TikiWiki’s security is a big selling point, but it isn’t really something I’d ever want to buy into.  I don’t want to gripe too much about Tiki, because it’s software that continues to serve my private campaign setting well – but still, the security model is bizarre, contradictory, and redundant.  Security settings exist in multiple places that do almost the same thing and which interact with each other in unpredictable ways.  Some settings require modules to be loaded that aren’t by default, and the software doesn’t tell you about the dependency – it just transparently fails.  Unraveling it all as an outsider is a nightmare.

Worst of all the security rules, which are supposed to be flexible so that they can serve many purposes, aren’t even particularly well-suited to one purpose.  It’s hard to protect a wiki page so that it can’t be edited by the wrong people and can be edited by anyone who isn’t an admin, and coaxing it into doing the kind of duty I needed for roleplaying games is probably impossible.  The contrast, though, comes in the form of the current build of Luminar (26, for the record) which operates mostly on the “please don’t edit the GET-parameters to do stuff the UI doesn’t allow” model, which is to say it uses the honor system.

The issue isn’t that security itself is particularly tricky, it’s that I was pretty naive when going into development.  Security at an actual pen-and-paper game is pretty basic.  You don’t pick up and read your friends’ sheets without asking, and if you look behind the DM screen your character loses a level and swaps genders.  And so I thought that I’d be able to plan security intuitively, and have it work more or less the same.

Nope, wrong.  There are roughly a hojillion ways it can go wrong that I didn’t take into account.  How should sharing a sheet work?  Does the recipient get a copy, or do they see a “live” version of your own sheet? Can they erase it? Delete it? Should the original owner be prompted to accept outside changes?  What about the GM of your game?  Surely he should be able to edit at will, but then maybe that’s only a given in my games.  What about campaign notes? Visibility of party members on the battlegrid?  Holy balls, this is getting complicated.

There are a lot of ways of going about this that I know are wrong, that are obviously mistakes. There probably also isn’t any one right way to do this.

All this sums up with me having a version of the software that is less feature-complete than the old and abandoned Tiki branch, but which does the things which ARE implemented much better.

If in the least secure manner possible.

And there it is, at the bottom of a very long, very daunting list.  Security audit.

It’s going to be a while.