The events of the past ten days are so were the catalyst for this article, which is all about making sure that the $#!# in your games works the way you tell your players it does.
The first event was my abuse at the hands of the local broadband internet service provider. This Kafkaesque nightmare began innocently enough with an apparently malfunctioning modem and escalated on through angry calls to customer service and culminated with a call to a local radio station that finally assisted me in getting a @@#$!%^#& satisfactory internet connection.
The second event involved a guild in a popular online game that did what the game designers believed was impossible. The guild was summarily disbanded and many of its players banned, on the dubious grounds that the players had exploited a flaw in the game's AI that would not allow creatures to move along the Z-Axis in a three-dimensional environment.
The last event was the release of yet another MMPOG into the market - a release that was nothing short of spectacularly flawed. Servers were unable to handle the load, the code required a 60mb patch on the day of release, and message boards exploded in a catastrophic public relations nightmare.
What all three of these things have in common is the powerful force of customer expectation. In the above cases, the customers believed that things should make sense, and should work in a manner that was consistent with what they were told by the employees of their service provider. In all of the above cases, the customer expectations did not match up with the reality of the situation, which resulted in a great deal of bad blood on all sides of the issue.
This is an important lesson for all game designers, and any developer should take heed of the warnings implied by the above situations. In each of the cases above, the customers were told things were one way, and then felt the stinging lash of disappointment when they learned that they had been fibbed to.
Which is why game designers must be brutally honest with their players and with themselves when it comes time for a game to see the light of day. It is one thing to plan on having, say, naval battles in your game, it is quite another to say that those things are already in the game. In short, do not say that a certain feature is in your game, unless it is. Seems pretty simple, doesn't?
The other lesson to learn from the incidents above is that it is important to understand what the goals are in your game design. Take time to understand what your game is about, and then plan features accordingly. This will not only help you to avoid the dangerous phenomenon known as feature creep, but will also keep your designs thematically focused.
And one last, important lesson can be gleaned from the above incidents:
Players are the lifeblood of your game. They are your customer and support system, they are truly the best friends of the game, and should be treated as such. If your design is flawed, and it allows players to do something they should not do, the fault is in the game, not in the tactics of the players. If you cannot fix the problem, then it must be addressed to your players, so that they will understand that exploiting the flaws in the system will result in some sort of painful punishment. Attempting to hide your own errors, or worse, to blame your players for the sins of your developers, will only erode player confidence and cost you dearly in the long run.
So, to sum up:
- Be honest about your game.
- Treat your customers with respect.
- Be very careful who you choose as your broadband internet service provider, because some of them really, really, really suck.
As always, use the link below to tell me what a raving loony I am - it's only true.
