MM-Game Thoughts: Difficult Implementation vs. Redesign

One of several deep considerations of the mechanics and themes of LARPs prior to writing Gnostica. (Ed. 10/1/2023)

Today’s topic is kind of broad: can difficult implementation be eliminated by design and redesign.

At what point should a difficult implementation of a concept or offering in a massively multiplayer LARP or online game be taken off the plate and redesigned?

Examining other LARP’s and MMORPG’s I can easily point out design choices that have resulted in literally thousands of work hours spent clarifying, enforcing, disciplining, and arguing over the change; the net result being an unhappy customer base, frazzled administrators, and the initial benefit of the offering or decision is lost in the “churn” that it’s implementation requires. MMORPG’s and MMOFPSs have the advantage in this regard in that being online and computer-moderated the “enforcement” of a change is automatic, however, the churn continues on in the members anger and frustration in forums and in discussions amongst one another. This is detrimental to an organization on a fundamental level that I don’t think enough people realize, even though you still have the mindshare of the customer it’s a mindshare the customer identifies with frustration, stress, and anxiety. They may not leave, but they will not associate happy emotions with the current situation. You can only bank on historical positive experiences for so long.

In thinking of my own mistakes in this area I’m reminded of decisions I made in LARP’s that took several pages to explain, numerous hours of discussion to clarify, and constant attention to moderate and enforce over an extended period of time. Did my decisions really benefit the members given the hardships required to adapt to the changes? Can design, and redesign (and redesign if necessary), eliminate this churn? Using new combinations of rules, methods of presentation, technology, simplifications, and “smart” systems lessen the churn. How do you judge when something has gone on long enough that it needs to be taken back to the blackboard? There’s also the challenge of what’s good for the game vs. making everyone happy, ideally, you do both because both are critical to success. I don’t take it as gospel that you can never make everyone happy, but I do realize that it is one of those goals like zero-defect management that can end up taking more incremental work per diminishing return on the result.

I guess my thoughts (today, ask me again in a few years and I may be wiser on this issue) are that any change is going to require some adjustment period for folks to get accustomed to the new way. But if the adjustment period expires and the churn remains, becomes a fixed part of the organization, even requiring positions to be appointed to deal with it, there’s a flaw in the design. Pilots can and should be used to test changes but I doubt it’s almost impossible to fully test the impact of a change until it goes live in front of hundreds, if not thousands (or in Planetside’s case 20k) hard-to-please customers. A successful design change results in minimal churn and if players are unhappy about it a compensating factor either takes their mind off of it, or they have an option to work around what makes them unhappy (respending spec points in DAoC when a spec path is substantially changed for instance).

Part of the design process must then be not only a consideration of how the design benefits the game but the consequence of the design choices made and their impact on customers and the organization. What will it take to manage? What will it look like a year from now if people are still arguing over it, will it still be worth what you originally intended? I started with this topic because it effects and interweaves with every other element I’m working on for Project Kneecap. Comments welcome…

Tim C.

Discussion

I suppose the question boils down to whether the pain of a change out-weighs the pain of not making the change

I’ve read a lot on change management and have to agree. Wherever possible frivolous changes should be eliminated by forethought in design. But I really believe massive games are far too complex to honestly think you can get it “all right” in the first shot.

Change gurus stress the requirement to respect the existing social contract and enable “ownership” of the change at all levels in an organization. Continuious management puts forward that if change becomes frequent enough, that it becomes ingrained in the culture, it can be seen as an ongoing positive. Machiavelli warns there’s nothing more dangerous than changing the order of things and advises to inflict all the pain sharply in one instance so that it’s forgotten over time rather than dragging on.

Perhaps it’s best if there are core “pillars” of a system or game that you put forward at the creation and keep the hands off from changing them. Even if the pillars set forth regulated change at expected periods then at least members are aware of the possibility up front. Once set however you better hope you did your design right because making changes to these pillars will cause a lot of friction with the membership base.