MMO Development Lesson #3
No feature creep. It’s better to have a short list of tightly knit features than a long list of features that don’t play nice together. Even if you have 100 awesome features, if they don’t all work well together, they will actually make the game worse (not to mention less accessible, because it’s hard to learn that many features). It’s much better to focus on a smaller set of features, make sure they all play nice together, and polish the hell out of them.
It seems like a lot of our polish has actually come in the form of new features. A system that was pretty good can turn into an excellent system if we add just ONE MORE FEATURE. Of course we constantly have to fight the urge to add one more feature that doesn’t get us a similar bang for the buck.
I’m trying to think of a game where features got added that just didn’t fit, and I’m having a hard time coming up with one. I know they’re out there, but I can’t think of one.
This posting makes me think that somehow you mean games that are trying to provide a breadth of gameplay types are bad - I don’t think that’s what you mean though. For example, there’s no reason you can’t do a crafting/economic game alongside a standard combat game in an MMORPG, and in fact, there’s a lot of reasons why you’d want to (it aids immersion, helps community growth, etc). But what you do need to do if you add another type of gameplay to your game is make sure that it integrates well. It needs to feel like a part of the game as a whole to the player; it needs to make sense to everyone why it’s there. So if you add, say, a political minigame to your MMORPG, then that political minigame needs to have impact on the other areas of the overall game too, and not just be its own thing. Likewise, other areas of the game need to impact the political minigame as well.
I think “creep” is the key word here. You don’t want to keep adding features after your initial design, because you wind up with additional widgets that might look cool by themselves, but take away from the overall picture (and if they were added late, they’re not as fully tested).
Steven King calls the concept “kill your darlings”. You may have written the most awesome, mind-blowing feature, but if it takes away from the overall vision for your project, if it just doesn’t fit, you have to kill it.
Thermoses wrote:
If you’re using a waterfall model and have a point at which your design is locked down, I guess that would apply. If you do that, though, you won’t be able to take much input from your testing and use it to change the design of the game to reflect how it’s being received. On a project that takes as long as an MMO that seems like a terrible idea. We will have been working on PotBS for 4.5 years by the time it launches. If we had locked down the design after year 1 we wouldn’t have been able to respond to feedback from actual players, changes made to player expectations by new games that came out during production, or even discovering that the game itself wasn’t very fun in its early incarnations and needed different features to fix that.
It is hard to define where responding to feedback stops and creep sets in, esepcially in an MMO, where players expect new content and new features to be introduced over the course of the game. Different games will have different definitions of creep at different points in their development and release cycles. What might be creep when preparing for the first beta might become a core feature for a later expansion when proper resources can be dedicated to it’s development.
The biggest problem at my company was always feature creep. My boss, the owner, essentially refused to set release dates or use design docs… his philosophy was “If the customer asks for it, and its possible, we’ll do it. Now.” Finally, after two years beating him over the head that it was not a great way to run a project, he’s let us actually do design docs and set releases, when a customer asks for something new we evaluate it and either work it into the schedule or put it on the plate to be added to a future release. All of our point releases since then have been so much smoother, and us programmers are back to working normal human hours and not pulling our hair out at the roots.
New features should be part of your design cycle… the research, feasability, design, etc should be a step right after fixing known bugs in existing systems and polishing existing systems.
Joe makes a good point about different project planning models. In some, a clearly define succession of feature planning, design, testing, and review can allow for “features” that aren’t really “creeping.”
-
What I’m more concerned of is when people mistake “feature creep” for designs that lack foresight. A designer defines a task, but doesn’t take into account how it interferes with other elements at the design-level. They end up going back to repair the conflict with a cumbersome structure that could probably have been quite simpler if it had been originally planned for, then blame “feature creep” for the delay.
-
That isn’t feature creep. That comes from projecting estimates on an oversimplified concept.
When I think of “feature creep” in an MMO I think of EQ. Nearly every expansion has added some “great” new feature that you just “had” to buy the expansion for. Now, we have a huge game with lots of features and most of them don’t work together.
Example: Instances:
The original concept of instances in EQ debuted with LDON. Now, the whole idea of instances really has been good for the game, but they didn’t plan it out properly. Instead they threw something together and tossed it out to the players to chew up and show where all the flaws in the system were. Then, a few expansions later they release a new “questing” system. Which is what they should have had in the first place and they would have if they would have taken their time to plan it out properly.
Sadly, they still used both systems in their last expansion for raid instances. Which makes it even worse. They should decide on one system to use and revamp everything to use that one system for instances/questing instead of just throwing new things at us.
I’m going to agree with Joe here, the term “feature creep” is too ambiguous for MMOs because some features just need to be added for whatever reason. Adding features, even at a late date, isn’t always feature creep. The trick is to find features that won’t drive you wildly over schedule and/or budget.
One reason for this is that “fun” isn’t easily measured via unit tests. If you develop your game and meet the game design document 100%, but the game isn’t fun, you can’t tell your customers, “Hey, no feature creep!” and expect them to care. Sometimes you have to add additional features to make a game more fun. This is a hard position to be in because you are adding features in at the last moment without much serious planning. This is what Joe is talking about above when he says that sometimes that one additional feature adds a lot of fun to a system that didn’t have it before.
Further, some would argue that online games have to adjust to player feedback a lot more. How often was EverQuest criticized for “The Vision(tm)” when I’m sure it helped keep “feature creep” in line. Yet, it wasn’t satisfactory for many players. So, there’s a good and bad side.
Overall, I don’t think you can say “no feature creep” without some caveats. If you do, prepare for vision jokes to be resurrected.
My thoughts.
My strongest argument in the topic of polish points towards always improving the ‘interactive iterative process’ (Chris Crawford) which defines the communication between the user and the game. Some games do these things well (mainly Blizzard titles) and others less well (most other of the big games).
Many people will confuse a stage within this process of communication for a feature, that is in my opinion an incorrect perspective. The feature is the whole process through verb to reply. When aiming at making a popular game you will always benefit from completing the iterative process for all included verbs. For a game like an mmorpg some verbs enter an algorithmic thought process which does the processing for a very long time and spits out a reply far into the future, such mechanics are part of the genre and often the designers forget to make the computer tell the player that the answer will be delivered in the future. Leading to confusion and unhappy players.
Im getting a bit off track here so to get back to the foundation of the question. My type of answer to this question is to always complete the interactive process for every feature before adding new features. As long as you keep this in mind you will be able to adjust old mechanics to fit the new ones as they enter the whole system.
Desarrollo de MMO - Parte #3…
Nada de características mal implementadas. Es mejor tener una corta lista de funcionalidades bien entretejidas que una larga lista de características que no terminan de conjuntar. Incluso si tienes 100 magníficas características, si no interacciona…
[...] MMO Development Lesson #3 [...]