Psychochild has an interesting post on stages of MMO development. While reading this, I realize that MMO development is not really different from any other web or desktop application.
Without any experience of MMO development, I basically followed the same path based on my experience at my day job. I have rarely seen posts linking traditional software development with games so I'm wondering why there's seems to have a line between the two.
Is it because game designers never did other software development? Is it because traditional software developers have never crossed the line over to games?
Between the two, I see little differences. I don't mean that someone that worked 10 years doing accounting softwares would automatically be able build a successful game, just that the steps of production are really the same.
The game designer is able to come up with something "fun" while the software developer is able to come up with something useful. This ability isn't related to stages of development so that's what telling me that someone with the right project management background would be able to go on either side of the line, with the right knowledge and interest (one that can manage the development of an acounting sofware doesn't mean he would make a game that people would enjoy even if development is done the right way).
So what's the point of all this? Well, I guess I'm just playing with it trying to see if I'm someone that comes from traditional software development that will be able to cross the line and finish my current project in a successful way (not talking about financial or numbers matters here, just about what is wrong and right with the project compared to another).
Of course, being the only developer in this project is blurring a bit each stages but over the years, I learned to work step by step just like an analyst and not "all-in" like a programmer. So far I think I did a pretty good job following each stages but what will be really interesting to see here is what could have I done better to improve the result. What can I learn here that will help me with the next project. Does my lack of "game development" knowledge have been filled back by my experience working with business web and desktop applications.
Oh, by the way, step 6 is right around the corner. Next week, hopefully, we'll see some more people in Golemizer!
Friday, May 23, 2008
Stages of MMO development with no experience
Subscribe to:
Post Comments (Atom)
Posts
3 Comments:
One thing to keep in mind is that my blog post was a very high level overview. As usual, the devil's in the details, and those details can be quite tricky.
The big difference between games and traditional software is the notion of "fun". The primary issue here is that the term isn't easily defined, and can even change from person to person. But, games have to worry about almost every other aspect of development just as non-game software does: operation, human interface, etc. In a traditional project, you can do tests to see if the program is working right. As I've quipped before, "there's no unit test for 'fun'." Of course, this can cut two ways: a buggy game that's really fun is often accepted more readily than a traditional software program that has just as many bugs.
Another issue to consider is that most of the "fun" bits of the game are what we often call "content". Your game Golemizer, for example, is the start of a fun game; however, it needs a lot more content before it's an entertaining experience that will last more than a few minutes as a diversion. A spreadsheet, on the other hand, doesn't need the equivalent amount of content to survive. An MMO, of course, has the benefit that content can (and must be) added on a regular basis to improve the game. But, notice how a lot of recent games have taken lumps for not launching with enough content.
The idea of "fun" is one reason why I point out the feedback problem: by the time you get enough people looking at your game, you are probably committed to the path you're on and will be loathe to radically change a system which may incur a lot more cost. So, a different project organization system may work better, but nobody has come up with one yet.
Another issue you have is just the nature of game development: everyone wants to have a say. Given the notorious way the industry underpays its employees, why would anyone work at a game company instead of a "real" company? One reason is to have input on the direction of the game. So, with so many people giving input, and the nasty role of politics in a lot of development situations, this can sometimes inject a lot more problems into the process than you might find in a more mundane technical project. A solo person working alone on a project doesn't have this same issue, though.
One thing we definitely do need more of in the industry, however, is better project management. A previous project I worked on had us working with an experienced project manager, and that was a huge difference in the organization system. Unfortunately, other events conspired to kill the project, but I really think it was a step in the right direction.
My further thoughts.
Reading this back, I guess I should have talked about how project management looks the same rather than the whole development process. Like you said, games have this stuff called fun that traditional softwares don't have to care about.
My question though (just a saturday morning thought!) would be, if I come to you with a list of what is fun to me in a game and ask you to build a game only for me following this list, wouldn't the notion of fun just become another feature on the checklist? Wouldn't the game be like an accounting software?
"Fun" is a problem because we can never be sure what it is (or not). I mostly done custom desktop/web applications and little "generic" work so I always had the chance to sit with the client and talk with him to know what he wants and what he really needs (that he might not know yet). For a game, you can't obviously do that unless my previous example would apply. So I can see the difference between the two kind of development and again like you said, it's high level stuff.
by the time you get enough people looking at your game, you are probably committed to the path you're on and will be loathe to radically change a system which may incur a lot more cost
On a small scale, I faced exactly this problem with my first game Chasing Tortoise. I worked for a long time on something I thought fun and when I finally had the chance to get some people look at it, I had to face that I was pretty much one of the only few that thought it was fun. I received a lot of feedback on how to change it to make it fun but the changes couldn't be easily made and would have required major recoding.
That's why this time I wanted to make sure to get more feedback before calling it "finished". I'm learning about fun and I have much to learn. Your comment about Golemizer needing a lot more content is exactly the kind of things I wanted/needed to hear. When you're almost alone with your code, you sometimes hear voices (I think as long as you don't answer them back you're still considered sane! hehe) telling "wow, that's so fun, you did great". The problem is that you might be the only one hearing those voices and that you need from time to time someone telling you "hey, wake up and look over there".
So finally, is a game with no players because it's not fun is still a game or should be called a spreadsheet? I must have read something about this comparison somewhere (maybe your blog? or another?). I think a lot of people are able to build games as spreadsheets but a lot less are able to turn a spreadsheet into a game.
Ok, where's this lists of things I was holding back for Golemizer? I got more work to do!
[I]f I come to you with a list of what is fun to me in a game and ask you to build a game only for me following this list, wouldn't the notion of fun just become another feature on the checklist?
No, because there's no guarantee that your list really is fun. Take this humorous example I've used before: I love sushi, and I love Taco Bell; but I would never eat sushi served at Taco Bell as we know it. If your list of fun elements had contradictory pieces, that could ruin the "fun" element of the whole system.
To see a "real world" example of this, look at EverQuest 2's crafting system: it is more interactive and therefore more interesting than pushing a button and waiting. However, this also ruins the social experience that most crafters enjoy while crafting. These two goals are contradictory.
[I]s a game with no players because it's not fun is still a game or should be called a spreadsheet?
No, because a game without players is worthless; a spreadsheet at least has a use, even if it's not popular. In most cases, the author of the game often sees the game as worthwhile, at least. There's nothing sadder than someone building a game they don't like to service an audience that doesn't exist. :(
Further thoughts.
Post a Comment