Happy New Year, everyone. No prognostication from me at present, I'm still figuring out what kinds of things I can talk about since I work for a publicly traded company.
Last night marked the end of Dungeon Runners; it is gone. I haven't been involved in the project, or really the community, since I left NCsoft a year and a half ago, but I am still very sad to see it go. There was something really special there, and there isn't even a hollow shell left to remind us.
Entries tagged as dungeon runners
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.
(Page 1 of 1, totaling 2 entries)
