Gabe and Tycho managed to step into a big discussion today on used game sales. I sent them a response over email, but it seems like a decent thing to discuss more widely (and perhaps get more game developers discussing, in particular), so I'll share it here as well. I wrote it up pretty quickly, and did my best to be brief, so I didn't follow my normal practice of adding copious foot notes and discussion on my main points - I'd be happy to support more of what I say in comments, but I also wanted to post exactly what I mailed them, below. And yes, there is a limit to how brief I can be - even these comments aren't as short as I think they wanted.
Note, as usual, I'm stating my personal view, and not those of my employer. I think they are entirely consistent with things like EA's Project Ten Dollar, but I'm not discussing that - just my own views.
Continue reading "Open Letter to Penny Arcade" »
Entries tagged as blogosphere firestorm
Wednesday, September 16. 2009
Dungeon Runners postmortem
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.
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.
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).
