Tag Archives: portability

Campaign Backups – A Happy Ending

This should be the final chapter of the campaign backups saga (see Part 1 and Part 2…or don’t, it doesn’t really matter).

After implementing the basic version, I posted a challenge to the community to come up with an XSLT for the backup to make it look like something other than computer vomit. I think it was well under 24 hours later that Kyle had a working stylesheet that did an awesome job of formatting the backup.

Now, when you download your backup, it comes as a .zip file that contains everything you need to view and navigate locally. Just unzip the file and load the .xml file from there in a browser. Voila! A totally slick local copy of your campaign.

This closes the book (for now) on the campaign backups, as they now cover the main functionality (ie. you get your data), with the added bonus that your data is actually in a usable format. In the future, we may revisit things to see about adding images and maps, but for now, I’m going to put a big check in the win column.

Thanks again to Kyle for all his hard work. If you download a backup and like the way it looks, drop by his blog and tell him thanks!

Downloadable Campaign backups – part 2

In Part 1, I discussed some of the possible formats and asked for feedback. The response was very positive, and it was clear that many, many people were excited about getting backups of their campaign.

Version 0.1

Taking the custom XML schema route (based very loosely on Atom), I worked on this over the weekend and made quite a bit of progress. I’m happy to say that we’ve launched version 0.1 of the backups. Why 0.1? Well, I’m not ready to say that it’s fully complete, yet. It contains all your wiki pages, adventure log posts, campaign forum posts, and characters. However, I’d like to get some feedback on the XML schema, and also let me know if there’s anything else that is missing and should be included. Remember: At least for now we’re not going to mess with uploaded images or maps. Maybe in the future.

How to do it

To get your backup, click on the Edit Settings link on the campaign sidebar. From there, scroll down near the bottom of the form and you’ll see a place to download your backup. Click the button and save the xml file.

HTML? PDF? I’d pay for that!

A lot of people wanted an HTML or PDF version, and that’s too much to ask at this stage. However! With the source as XML, it’s fairly straightforward to convert or translate to HTML, and I assume it’s not that bad to go to PDF (I’ve never done XML -> PDF, so I could be wrong there). If there’s anyone in the community who wants to step up and create an XSLT (or the equivalent for translating to PDF), we’d love to have it. I’ll offer a free 1 year Ascendant membership, a t-shirt, and our eternal gratitude to the first person to do it. However, hold off for now, until I can say for sure that the schema is locked down.

Update: The prize has been claimed by Kyle. He has created a kickass design for displaying the backups, and we’re working on figuring out how to integrate it into the download package.

Feedback welcome

Give the backups a look, and tell me what you think.

Downloadable campaign backups

An often requested feature is for the ability to download all your campaign data locally, in the unlikely event that Obsidian Portal implodes or the staff is replaced by evil dopplegangers who want to restrict your access to your own content. We’ve finally bumped this feature up to our short-term goals list, and I’d like some input on what people want.

What you’ll get

First off, let me clarify what I mean by a “backup.” I’m speaking primarily of the text content: wiki pages, adventure log posts, forum posts, and characters. We’re going for a “good enough” solution here, so we’re not going to include uploaded images. Finally, there’s no guarantee that hyperlinks will be preserved, either.

Backup, not import/export

Another point worth mentioning is that this is not intended to be an import/export feature. It’s only 1-way. We don’t intend to support importing a backup file, since that’s a big technical issue, and we don’t think it’s necessary.

Formats

We want to make this a useful feature that allows you to take your work elsewhere if you choose, but we’re not familiar with any particular formats or standards. I’ll toss out a few ideas, but I’d like to hear suggestions from the community.

Atom

It’s no secret that I’m a huge fan of the Atom protocol. We use it to syndicate our campaign data to Pen & Paper Games, and that’s been a huge success.

Considering that the Adventure Logs would fit an Atom feed, it’s got something in its favor. However, things like wiki pages and characters don’t fit nearly as well. I could cram them in without too much trouble, but it’s definitely not a perfect fit. Plus, there is no good way to split the GM-only content from the public data. The worst fit would probably be for the campaign forum, where it would be very difficult to manage the parent-child relationship between forum posts and topics. I don’t think Atom has any support for that kind of thing.

Custom XML

If we can’t shoehorn everything into an Atom document, then we just give up and make up our own custom XML schema. This is kind of the default answer to most things, and while it works, it’s not great. It just means that if anyone ever wants to import the data, they’ll need to write a custom parser.

CSV

I’m just kind of throwing this out there as a straw-man argument. CSV would be a horrible export format for this kind of data, but maybe someone disagrees?

Zip of HTML files

All the formats so far have centered around cramming everything into a single file. It’s also possible that we could generate HTML files for each different page, then provide a zip containing everything. The upside here is that you would be able to open the pages in a browser without needing any kind of import tool. The downside is that HTML has very little semantic knowledge in the markup, meaning that anyone who wanted to write an import tool for the data would have a difficult job. It’s much easier to consume semantic XML than HTML.

Plus, this approach would be considerably more difficult, technically. We would have to generate the files on the server side, zip them up, then pass them off to the browser to download. I’ve never done that before, and while it intrigues me, I’d rather be working on other stuff. I’m sure most of you would also prefer me to work on other features.

Others?

If anyone knows a good standard for this kind of thing, please toss it out there. I’m always interested in learning new standards.

No promises!

As always, there are no promises here. We may decide that it’s too difficult or not valuable enough, and put the idea back on the Someday pile. But, if we can come up with a solution that is the right mix of useful and quick, then we’d love to do it.