For the last year, I've been working on an unannounced strategy MMO based on an IP I can't talk about.
But, that project ended today. Maybe I'll have time to finish more blog posts now ;-)
edited for... clarity.
Wednesday, October 14. 2009
the joys of managing your own web server
The data center my web server resides in moved recently; I - and everyone I share my rack with - had to move our equipment some time between the beginning and end of this month. So that happened today, and I'm sorry for the downtime (to anyone that noticed) but it's stuff like this that, honestly, keeps me wanting to run my own server.
I remember once at NCsoft something similar happened; I don't remember (and may not have ever known) the "why" but data centers changed; I just noticed because... wow, all those sysadmins and network admins and other operational staff sure seemed tired and cranky. But as I recall, it didn't actually translate to significant game down time - certainly not the 8 or so hours this site had today (to be clear, everything in the rack was being moved at once - I didn't do such a terrible job that it took me 8 hours to move one 2U system across town).
That's something I should keep in mind, in my opinion. Can the systems I develop be easily migrated if they have to be? Not just for the (generally rare) circumstance of the entire data center moving, or contracts changing, but even the day-to-day of machine failure.
At nearly midnight, having been home for about 15 minutes, I'm certainly not of the right mindset to make a list of proper steps or describe an architecture or any such thing; but I can at least try to remember this feeling later, because I don't really wish it on anyone. :-)
I remember once at NCsoft something similar happened; I don't remember (and may not have ever known) the "why" but data centers changed; I just noticed because... wow, all those sysadmins and network admins and other operational staff sure seemed tired and cranky. But as I recall, it didn't actually translate to significant game down time - certainly not the 8 or so hours this site had today (to be clear, everything in the rack was being moved at once - I didn't do such a terrible job that it took me 8 hours to move one 2U system across town).
That's something I should keep in mind, in my opinion. Can the systems I develop be easily migrated if they have to be? Not just for the (generally rare) circumstance of the entire data center moving, or contracts changing, but even the day-to-day of machine failure.
At nearly midnight, having been home for about 15 minutes, I'm certainly not of the right mindset to make a list of proper steps or describe an architecture or any such thing; but I can at least try to remember this feeling later, because I don't really wish it on anyone. :-)
Friday, October 2. 2009
After the conference
A web developer friend of mine is thinking about conference "back channels." Folks who attended AGDC this year (where the Twitter traffic was heavy and constant, and #agdc09 was everywhere) might want to participate in a brief survey he's conducting on, I guess, making it easier to find and participate in.
Friday, September 18. 2009
A Quick Review of "GDC Austin"

Austin Game Developer, eh?
It's interesting that I never heard it actually referred to as GDC Austin; the old names, AGC and AGDC, are still fresh in people's minds.
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.
previous page

