It was announced today that Dungeon Runners won't see 2010. Obviously, this is a project I haven't been involved with for a year... but while I was there, I did everything I could. I crossed a lot of bridges trying to make that game everything it could be; gaps everyone knows about like the one between developers and players, and gaps that are harder to see like the one between live staff and development staff.
I've seen a lot of discussion around the game industry that developers should never talk directly to players; it's probably a good rule of thumb. However, if you want your developers to know exactly what's wrong with the game, so they can fix it, they have to play the game. If you want your players to know that this is happening, they have to see developers in the game. If there's any one thing I think we got right on Dungeon Runners, it was being open and honest with players, and listening to them.
The other divide is interesting; it's broadly true, not just a part of games. Customer support, NOC, server administration... there is often a very large gap between the people who make the product and the people who keep customers happy. Talking with these other teams about what they needed, what problems they were seeing, and what they wanted is actually really important, sort of like having programmers and designers talking to each other. Obvious, but it still seems to get lost in the day-to-day.
But... that's not really enough. Making a fun game isn't enough. What I've come to believe is that to reliably make a successful game, everything has to be in place. You can't make a perfect product, but at every step if you accept "good enough" you are accepting a potential point of failure. Business plan, marketing, game design, user interface, operations, customer service... better is better.
That kind of leads toward the attitude of a control freak; everything is your job, and if someone tells you that some aspect isn't part of your job description, a red flag goes up. On the other hand, it goes the other way too: if anyone is concerned about your contributions to the project, and thinks that you are doing something wrong, you have to listen. They might just be right. If they are right, getting called out by a co-worker is infinitely better than being called out by players or reviewers; the earlier you can correct a mistake - yours or someone else's - the easier it is, and the sooner you can move past it.
I'm grateful to everyone I worked with on Dungeon Runners, because they helped me learn these lessons in a positive light; the layoffs, and now its ungracious end, have emphasized the danger of letting anything slide.
Entries tagged as blogosphere firestorm
Sunday, April 12. 2009
New Blog!
Go ahead and leave feedback about how much you hate the new site, hated the old site, hate me, etc. here. I look forward to it. :-)
Sunday, March 15. 2009
Craftsmanship
Joe Ludwig has been talking about continuous deployment recently. The basic goals of continuous deployment are two-fold: minimize downtime, and minimize the time between writing code and finding out it's wrong (it could be wrong for a lot of reasons, not just bugs).
An interesting counterpoint came from Ben Ziegler a couple of weeks later (I'm just following the trend in writing my take on the subject a couple more weeks on), arguing that downtime - and bugs, and lag - just don't matter.
First, let me point out that this isn't a new discussion, by any means. As of this writing, Bug Free Doesn't Sell is a wiki article last edited almost three years ago... on this exact subject1.
On the one hand, I think Ben is right: "Stable, fast, fun. In that order" is not a mantra for a great game. "Fun. probably stable, and fast enough" is a better mantra. It's hard to see the direct benefit to maximizing stability and minimizing downtime, and it's always possible to over-think technical challenges and lose focus on the game itself in solving them.
On the other hand, I think there are a lot of indirect benefits. Doing things right attracts people who are interested in solving new problems (or old problems better), it reduces operational overhead (manual steps and emergency downtime require hands on deck - costs I'm probably more aware of, having worked down the hall from NCsoft operational staff), and it's another defense against the motivation-sapping attitude "nothing works right around here."
Hell, to some extent, you don't even have to succeed at minimizing downtime to see the benefits (c.f. Blizzard's launch of World of Warcraft). Mistakes were made, but they came more from inexperience in MMOGs specifically than bad culture, lack of investment, or having bad programmers. Now, though, that doesn't really apply; we have to create technical failures in other ways. We know better than to make the same mistakes, we'll recognize the same old mistakes coming... and if we do nothing but let them wash over us, we'll see our motivation and investment in the game disappear.
And then the game will suck, and people will argue about whether the problems were technical or not.
1. Incidentally, any programmers who aren't familiar with the Portland Pattern Repository's Wiki - it might be the oldest web-based programmer community around, and is the original Wiki. It can be hard to read at times, but there is a ton of stuff and it's easy to get lost in there for hours.
An interesting counterpoint came from Ben Ziegler a couple of weeks later (I'm just following the trend in writing my take on the subject a couple more weeks on), arguing that downtime - and bugs, and lag - just don't matter.
First, let me point out that this isn't a new discussion, by any means. As of this writing, Bug Free Doesn't Sell is a wiki article last edited almost three years ago... on this exact subject1.
On the one hand, I think Ben is right: "Stable, fast, fun. In that order" is not a mantra for a great game. "Fun. probably stable, and fast enough" is a better mantra. It's hard to see the direct benefit to maximizing stability and minimizing downtime, and it's always possible to over-think technical challenges and lose focus on the game itself in solving them.
On the other hand, I think there are a lot of indirect benefits. Doing things right attracts people who are interested in solving new problems (or old problems better), it reduces operational overhead (manual steps and emergency downtime require hands on deck - costs I'm probably more aware of, having worked down the hall from NCsoft operational staff), and it's another defense against the motivation-sapping attitude "nothing works right around here."
Hell, to some extent, you don't even have to succeed at minimizing downtime to see the benefits (c.f. Blizzard's launch of World of Warcraft). Mistakes were made, but they came more from inexperience in MMOGs specifically than bad culture, lack of investment, or having bad programmers. Now, though, that doesn't really apply; we have to create technical failures in other ways. We know better than to make the same mistakes, we'll recognize the same old mistakes coming... and if we do nothing but let them wash over us, we'll see our motivation and investment in the game disappear.
And then the game will suck, and people will argue about whether the problems were technical or not.
1. Incidentally, any programmers who aren't familiar with the Portland Pattern Repository's Wiki - it might be the oldest web-based programmer community around, and is the original Wiki. It can be hard to read at times, but there is a ton of stuff and it's easy to get lost in there for hours.
Wednesday, August 13. 2008
movin' on
Yes, I was laid off today. Lots of stuff going on, but mostly things about which I should or would rather not say. I'm planning on renaming the journal, to cut out 'nc,' but I'm still trying to decide on the new name ('anson' is already taken).
Sunday, April 20. 2008
Other people's XML
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 usual1, 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.
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.
at
07:50
| No comments
| No Trackbacks
Defined tags for this entry: blogosphere firestorm, xml
Current mood:
accomplished
