I picked up and started reading Massively Multiplayer Game Development and Massively Multiplayer Game Development 2, both edited by Thor Alexander. I'm halfway through the first one, and am quite disappointed that I didn't know about these books before.
Not that I've found a lot that I hadn't known or determined, but it's good to see that others, especially those that actually do this for a living, have hit the same hurdles and come to the same conclusions that I have about various stages in MMO design.
The first section is about game design, which, if you've read previous postings, is something that I say will come much later for me. After all, MMORF is the foundation for building the games, not the act of making the game itself. Still, that doesn't stop the designer side of me considering all sorts of issues (and telling the developer side to make sure functionality is there to solve them).
The second section is about system architecture, with the first two articles titled Building a Massively Multiplayer Game Simulation Framework. Yeah, that's what I thought. There were interesting articles on open-source platforms out there for game development, and really, the whole section almost made me abandon this project.
But again, the point is to see if *I* can do it, not to have one done, so I kept reading and learned a few tidbits here and there.
Section three, which I've just started, is about server-side development. I've only just finished reading the first article, Seamless Servers: The Case For and Against. As my previous posts have indicated, I'm all for the seamless servers, and this article does a good job verbalizing the pros and cons that I had already determined. I did find his conclusion interesting, where he stated "the author's opinion is that seamless servers are not worth the effort involved."
I find that an interesting statement, because to me, the decision is one that would or should cause contention between the game designer and the game developer. I would imagine that, for the most part, game designers would want the world seamless, so their grand dreams are realized in an epic scape of whatever fits the genre. The developer, for reasons mentioned in the article, is likely to push towards instanced or segmented worlds, where events cannot cross over the boundaries, and thus programming required to handle this crossing (again, very well described in the article) can be avoided.
There are reasons, of course, that a developer might want an instanced world; in DDO, the dungeons are instanced so you and your party are allowed to explore without interference from others. Ultima Online added a similar idea with the Mondain's Legacy expansion, where a group leader can "tag" a group of others that are allowed to cross over and fight the end boss with him or her.
But generally, I wouldn't expect that it's up to the developer. With luck, the developer can point out all of the hurdles, and convince the designer that for time reasons, budgetary reasons, and reasons of sanity, the game needs to be designed around the segmented world. And if he can't convince the designer? I guess this is where the producer comes in, telling one side or the other what's going to happen, or how to compromise, or who gets to find a new job.
And of course, that's something that I'm hoping to avoid with MMORF. I don't want to have to tell a designer that they can't have their wide open plains of Saskatchewan in the Colonizing Canada Online game. I suppose that's one advantage to not having any money or backing from anyone to get this done -- I don't yet have a definitive target to develop for.
As for the rest of the book, we've got sections on Client-Side Development, Database Techniques and Game Systems coming up, which all promise to be as interesting as the first half. I haven't cracked open book two, but I'm sure it's going to be as good a read as this one has been.