Author Archives: Micah
I know it’s a pain to write a DST. The dev kit is probably horribly out of date by now, plus you never really know how your DST will work until you upload it live and play with a real character. I try to encourage people from the start to get their code live on the site as soon as possible, but it’s still no fun to write and edit HTML (or any code) in a textarea. But, all that could change thanks to a recent update.
The ideal app
Unfortunately, the ideal app doesn’t exist, at least not yet. But, I’ve taken the first step and added DSTs to the API. All the puzzle pieces are in place to make this a reality. They just need to be put together.
Can you do it?
I’ve got the API updated, but that’s about as far as I can take it. It’s been ages since I’ve done a desktop app, and I wouldn’t even know where to get started. Plus, I’ve got more features and bug fixes to work on than I want to think about. I need someone to step up, grab the reigns, and take it from here.
If you’re interested, or have a better idea, please come join the forum discussion. I’m really excited about the potentials of the API, and I think this app (or a better one!) would be a perfect fit.
We’re experimenting with a “trash bin” for your wiki pages (and soon, characters & items). This safety net will allow you to delete something, then bring it back later if you wish.
It’s not perfect, as certain aspects cannot be restored (like tags), so don’t go throwing things away without a little thought. However, you no longer need to fear that one of your players will spend an afternoon maliciously deleting your entire wiki.
The next logical step is to provide versioning history for your pages. That’s definitely on our TODO list, but I’m not sure when we’ll get to it.
Progress on the API is moving so much faster than I originally anticipated. I’ve been working on it night and day, trying to get to a point where clients can actually do something useful with it. But, I’m not the only one who’s been busy!
mage-hand, Rubygem for the API
Ruby hacker shammond42 (@shammond42 on Twitter) has already created a Rubygem wrapper for the API, making it much simpler to interface with from your Ruby or Rails application. For any other Ruby hackers out there, take a look at mage-hand and make sure to follow it on github. Or, if you’re not a Ruby hacker but prefer PHP, .NET, or something else, you might like the next part:
Progress on the API has been much faster than I expected. After a week’s worth of work, we have a fully functioning OAuth provider and a few JSON response API methods ready to go. Before we go too far, though, I’d like to get some feedback on the basic OAuth workflow.
OAuth is a standard workflow for managing third-party applications that want to access resources on behalf of a user. Facebook, Twitter, LinkedIn, Netflix, and a whole slew of other websites have started using OAuth for exactly what we’re trying to do here on Obsidian Portal. Considering that there is a lot of library support (PHP, Ruby, Flash, .NET, etc) for OAuth, it seems like a good way to go.
Unfortunately, OAuth is significantly more complicated than other, simpler authentication methods. It requires a special procedure to authenticate the user, plus each API request must be signed with a special algorithm. What we’d like is some initial feedback on whether it’s accessible enough and works for the developer community.
If you’re interested in taking the totally unstable, soon-to-change alpha version of the API out for a spin, check out the overview page, then create an application. Giv the OAuth signup workflow a shot, and let me know what you think in the forum thread.
So what’s in it for you? Well, I’m giving priority to feature requests from people actively playing with the API. If there’s something you want to do, and data you need, then start playing around and tell me what’s missing. If I can add it easily, I will. Of course, everything is likely to change a bit in the coming weeks, but we have to start somewhere.
When I originally architected Obsidian Portal, I imagined that people would be storing and sharing characters, items, spells, locations, and all kinds of RPG-related data. I tried to create the ultimate generic data model that would hold all these things, and characters and items were the first implementations of that.
After using it for a while, I’ve come to realize that characters and items are fundamentally different in how they are used and even if they are used. For example, characters are a core component of every RPG. Items are a component of some, but not others. There are many systems that specifically try to avoid the “We loot the bodies” mentality that pervades D&D. Having played some of these games now, I can see why an Items list isn’t exactly necessary, like a characters tab is.
On the flip side, for games where looting is a central aspect, a raw list of items isn’t much help. Instead, you need something more like a spreadsheet, where you can easily track the items along with their quantity, perhaps the assessed value, plus a bag for currency. In many ways, it needs to resemble a computer RPG inventory screen much more than a raw list of items.
Unfortunately, we don’t have the time right now to give the Items tab the attention it needs, so we have to put it out as-is. We wanted to modify the top navigation to remove the Items and Characters links (which are pretty useless now that we have search), and that would have pretty much orphaned Items forever. So, that’s where we are today.
But! We’ve got plans for the Items tab to make it closer to what it needs to be. As I said, imagine an inventory screen or basic spreadsheet and you’ve got a pretty good idea. We’re not sure when we’ll get a chance to work on it, but it’s on our list.
Ryan made some awesome updates to search over the past couple weeks, and they finally went out last night. I thought I’d give a quick rundown, although the best thing to do is try it out for yourself.
The formatting for the results is much nicer now, with more text for the wiki pages and adventure log posts. Before, a search hit just showed the name of the page and a link to it. As a bonus, the contextual text displayed is text where the search term was found.
The search term you are looking for is automatically highlighted where found. This makes it much easier to quickly scan through the results.
By default, a search will return all kinds of results: characters, wiki pages, adventure log posts, and more. But, if you know exactly where you want to look, you can filter to restrict it to only the type of data you are looking for.
Go Ascendant for campaign-specific search
Remember, if you’re Ascendant, all your campaigns will have campaign-specific search enabled. This is much handier than using the sitewide search, since you can restrict the search to only your campaign’s content. It’s extremely handy, trust me! If you want to enable this awesome feature, tell your GM to Ascend Today!