Anson the Gnome

In the year-and-a-half I've been on Dungeon Runners, we've gone through three Associate Producers and we've also spent a fair bit of time without any AP, leaving Stephen tearing his hair out. Why do we go so through many? I'm not sure. Coincidence, maybe, I don't think we're chewing through them like a chainsaw through a toothpick. Certainly, I hope we keep Cuppa around for a good long time, she's a cool person.

Sorry, not much else to say, but I'm really happy to have her on the team. :-)

The Dungeon Runners Retail Box is coming out tomorrow! Needless to say, I'm pretty excited, and I've been checking Amazon's page constantly, watching the sales rating (as of this writing, we're #29 in "PC Games," and it's been climbing all day).

I'm pretty excited, a bit nervous, and really incredibly curious about what's going to happen. Based on feedback from in the game and on the forums we're expecting a lot of existing players (both those currently paying, and currently playing for free) to pick up the box. But are we going to get a big influx of new players? Are the new players going to enjoy the game as much we think they will? How bad is the griefing going to be?

I look forward to knowing the answers to these, and other questions in the coming days. :)

Well, I was pretty hopeful about the extent to which we were taking additional information into account in PVP matchmaking, but a lot of it is getting pulled back. I still feel that we should take more than just ratings into account when matching opponents, but we don't have sufficiently accurate information on exactly how your level or power rating (i.e., your power relative to how powerful you could be at your level) affects the outcome of matches.

Also, with an upcoming patch, we're getting rid of unbalanced (size-wise) matches in rated PVP. This makes me sad, but the reality is that - try as we have - we haven't been able to really nail down the balance issues here. As we balance dominant strategies and level the playing field on a per-player basis, it seems that opponents of differently-sized groups boil down to two results: the larger team is well organized and wins, or the larger team is not well organized and loses.

The skill of the smaller team comes into play insofar as they have to be able to take advantage of disorganization in the larger team, but really, being in a bigger team and being even moderately organized is a very dominant strategy. We're leaving in the ability to participate in these matches via duels, and we'll be gathering data on them to see if we can do better in the future... but ratings (and rankings) won't be affected by these matches after the patch.

Similarly, we're going to gather more data before we put back in match-making adjustments based on level and power rating. I think it's the right thing to do - use all the information we can to make better matches - but in the absence of knowing just how much level and power rating are worth (and they might well not be linear adjustments!), a better adjustment is no adjustment.

Last Wednesday I attended a presentation in Austin Community College's on-going First Wednesday Video Game Seminar series on Mac game development. Their focus was Objective-C and Cocoa and (obliquely) iPhone game development. It was also fairly focused on what they were doing, and had done with Mac game development, rather than the breadth of development happening in the Mac game market.

I was kind of disappointed, though, because they didn't even mention Carbon, and were dismissive of ported games. Years ago I got to do Cocoa (and, previously, OPENSTEP) programming in Objective-C, and I really liked it. For a desktop application, nothing beats Apple's Interface Builder for designing interfaces and tying that interface to your code. But for games... Interface Builder doesn't really have anything to offer, and Cocoa doesn't have a lot to offer either. For cross-platform games, Cocoa has zilch to offer, because it dictates language choice. Indeed, even Apple documentation indicates Carbon is likely better suited to the task.

I really enjoyed the presentation, and I'm a fan of Cocoa, but I felt like everyone already working on a non-Mac game was left out in the cold by it. On the other hand, if you're interested in writing a game from scratch, and you want to target Mac users... Cocoa is definitely a great way to do it.

Folks have started talking about the Data Access API for Pirates of the Burning Sea. Of course, this is an area of interest for me, and I have expressed some minor opinions on it. Joe Ludwig was kind enough to respond on that same page, and Darius K weighed in at his official work blog. As usual¹, I'm going to talk in more detail here rather than somewhere else because it's easier.

Working on the XML for Dungeon Runners, we considered something very similar to what Flying Lab is doing, for very similar reasons - the ability to monitor individual applications, to revoke misuses of the data, and so on. Now that they and we are doing it differently, I don't mean to criticize them on the subject either... just discuss it, with the understanding that they prefer their solution and we prefer ours. :-)

One reason we forewent API keys and developer identification was the simple principle about simplicity: KISS. More moving parts means more maintenance and more points of failure (and given our budget, single points of failure). I suspected at the time - and this has largely turned out to be true - that if something needs to be designed or coded or produced for the Dungeon Runners XML system, I'm going to be the one to do it... along with everything else I do.

Another reason was that we weren't already providing a way to access this data in-game (e.g., using an /inspect command or something like that to view another character). We didn't want to create a situation where most of the players were waiting to get the data (either another player, or us). The raw XML is readable, so the players who write applications using the data can't themselves be gatekeepers deciding who can see what. Perhaps that would actually be desirable for Burning Sea's PVP, I'm not sure.

Of course, "low barrier to entry" is always a concern for a game like DR - one that probably isn't as big a deal for Burning Sea, probably - and we want to encourage as many people as possible to look at and play with the XML.

Finally, we feel pretty confident that we can accomplish the sames goals as Joe mentions on an IP basis - find out what external systems are asking for XML, how much, etc. See what sites are asking for XML, how often, etc., and block IPs if anyone gets rowdy. Not a perfect solution, but a pretty good one, considering the other tradeoffs we had to deal with.

And yeah, we're struggling with the questions of privacy and PVP data exposure too. We haven't exposed many of the things we'd like to, simply because we haven't hit on the right way to do it yet. When we have those answers, you'll see another surge in data exposure from us, without a doubt. :-P

---

1. It came up when discussing Cryptic's Cryptic DB, and it still holds true: LiveJournal provides much better word processing facilities - even when I'm using raw HTML and not their WYSIWYG rich text editor - than most blog software's facility for leaving comments. My posts also don't go through a spam/offensiveness moderation stage, and I can include links (I never know whether links are being accepted on most other blogs until after I've written the comment).

Also, the comment facility here is actually better (allowing links and images, providing a sizable text input window, threaded discussions, comment preview, etc.) for continuing discussions. Finally, thanks to OpenID, people can more directly connect their comments here with their blogs elsewhere.