kooxoo.com

Of course, it is also anti-thetical to the game developer’s mindset which has been long focussed on “going gold” and shipping a fixed and final product. Which is why I give more credit to Live teams than to the initial developers. Anyone can build something. It takes true dedication and determination to successfully maintain something. This is also why I don’t like the mind set of having a different Live team from development team. They should be the same. There should be no “Crunch time” leading into the final release of an MMORPG, because MMORPGs are not sprints, they are marathons.

Interdependent systems don’t preclude micro-patches. Indeed, the best way to tackle an interdependent system is with micropatches. Learning from the effects of small changes is the best way to discover how those systems are interdependent. Because the changes are small, it is a lot less difficult to roll them back if they prove wrongheaded. On the other hand, if you try and change the interdependent system in one massive patch, it is almost guaranteed you’ll screw something up. The patch itself will be so interdependent you’ll have a difficult time figuring out what part of it screwed things up.

Finally, one key advantage of micro patches is that you can correct typos and similar stupid bugs *quickly*. This is essential if you want a game that seems polished to the end user. This may seem backwards to priority-based bug approaches, for the lowest priority bugs will likely be fixed fastest, but has a significant impact on the feel of the package as a whole.

You could build a design that was more decoupled, and then your game will emphasize the “playing alone together” effect much more strongly; you would be there with other players, sharing a space, but not necessarily any gameplay.

there’s such a higher level of interdependence

Isn’t that the real problem here? Not “what if we built MMOs with daily patching”, but “what if we built MMOs suitably decoupled to allow for daily patching”? The answer to the second is something that I tend to rant about, and its hard not to point to Guild Wars for at least having some very pretty technology. As an outside observer (and I would love to be inside someday), I am just amazed at how much poor design is “obvious” in the end results, and that get in the way when/should I try to “play”. Admittedly, I realize that not all design can be “perfect world”, but there are some fairly obvious things that can be controlled. For instance, one of my big gripes is in the use of these seperate RTPatch-based pre-game Patchers. Why should you, on every patch, apply deltas across all several GBs of a game directory? Why isn’t there better asset management than that? Not all of the art assets are going to be loaded into memory at once, on game start, are they? (…and if they are, you have even bigger problems. Bad asset management extends just as equally to RAM needs as well…)

I could go on, but I fear I might not get the point across: It’s very possible to have good release cycles if you have good coding standards, good asset management, and a good team, which in the end are keys to most Software Engineering efforts.

If you can manage players’ expectations to the point where they expect gameplay changes on a regular basis, do you think they’d be more receptive to them?

While not an MMO, GalCiv2 bases a lot of its success off of daily interaction with users, and constant content updates. I’ve seen similiar situtaions like those described in the article where bugs really become a non-issue because the game players are aware that a patch will be coming shortly. In fact, the content updates are used as a form of anti-piracy (loose installation requirements in exchange for the fact that users will want to use a serial to get all of the new content they would be missing out on otherwise). I think that this works for them because their audience isn’t on the scale of something like WoW (niche, if you will), and can cater to many more individual requests (protecting long term customers and keeping word of mouth positive). It should also be noted that their creators have a lot of experience in non-game software as well.

I am skeptical that a model like this could work well with a large community due to magnification of “just 1% complaining or leaving”, but would be very interested in seeing someone try to make it work. Great food for thought, anyway.

If you can manage players’ expectations to the point where they expect gameplay changes on a regular basis, do you think they’d be more receptive to them?

People only like changes if they, well, like them.

This bothers me a little, this talk of managing players. While I understand it to a degree, it’s important to remember that people don’t like to be managed. And they are keen to sense it, even if they don’t quite understand the details of what it is they don’t like. Of course there’s that whole social consent thing.

I think developers would be far better off to work with the goal of serving the players with a good game, instead of the players serving them to make a good game.

If you can manage players’ expectations to the point where they expect gameplay changes on a regular basis, do you think they’d be more receptive to them?

I’m really surprised by comments I’ve seen made by MMO devs about how hard it is to add content into a game.

I sometime gets the same comment from the people I work for (web applications, core business applications).

When you start a new project, you always tell yourself “This is gonna be the best software I’ll build, got to keep it clean”. Then you got deadlines, budget constraint, new critical features asked in late development process and more… It’s at that point that you somehow lost focus on your primary objective and that you end up with something “harder to improve”.

I still haven’t to met someone that is coding to put food on the table that hasn’t gone that path, at least in major development.