capnjosh

We have a choice between adding new content and features or consolidating what we have and adding new features later. I’ve written about this before, but I worry it’s a decision that too often is decided in favor of new features.

I’ve taken a stab at this topic before in “Frustration of Reasonable Desires“, bince since the topic has had some time to stew, I wanted to revisit it.

A lack of features is only frustrating when the features that are missing are pretty essential to the game experience. A feature that does not work cannot be truly considered a feature. If the core features of a game do not work well, and since to some degree every other feature depends upon those core features, one could conclude the game does not in fact consist of features, and to opine that more features need to be added at the expense of bug-fixing is to ignore the fact that it is not “features” that will be added, but rather ever more elaoborate bugs.

I’m trying to make the point that there comes a point where one must cosolidate that which one has created. Create, Consolidate, then create again, and then consolidate once more.

I read recently that it is merely a matter of opinion and preference whether or not one fixes bugs in existing features. If the existing bugs are not utter game-breakers then they can (even should) be left as-is in favor of new features and content. I’m reacting to that. I believe bug-free systems, elegant code, efficient production tools, happy customers, and a happy bottom line all go together.

Some good food for thought on the matter has been posted recently at Zen of Design: “Triage and Extrapolation“.

What exactly is it that results in our tendancy to leave outdated tools as they are? What is the barrier that keeps us from immediately updating or fixing a tool that has become even a litttle bit outdated or broken? I betcha it’s linked right in with the preference to add new features over fixing existing systems/bugs/imperfections.

I think we’d all agree that letting some game operations tool remain “sort of broke” is not a good thing. The argument, however, then becomes “how much will it really gain us to fix it”.

Apple, iTunes, and the iPhone may help resolve this one. Every Apple product amounts to a subset of what, well, non-Apple products are. Apple products arguably don’t do as much and they restrict you to exactly what they designed the product to do and be. However, those things they have chosen to let you do are quite often a joy to use and as a result “it just works” resoundes from countless mouths. Apple has built a rabid fanboie nation on the habit of neglecting new features in favor of making a smaller set of features exceptionall well-done.

Faced with the question of whether to add new features or go back and make what we have exceptional, I choose the latter. I really think it’s the best route.

In my ongoing experience as a Game Master for Knight Online I have found an ever-present challenge: that of a distinct lack of in-the-moment relevent tools.
By no means am I griping. It’s just this need for effective, relevent tools to facilitate the Game Masters’ roles of maintaining and enhancing the in-game play experience strikes me as an [other] opportunity to distinguish one’s game from the rest of the pack.
By “in-the-moment relevent tools” I am talking about tools to help GMs do things like identify patterns of player behavior so as to respond most effectively. I’m thinking of activities like tweaking tool interfaces so as to allow for the most efficient possible GM activities, creating new tools to help mine through various metrics to find useful tidbits, and working with the technical producer to identify what metrics would be most important to track.
The Game Master crew can be the best direct feedback mechanism for ongoing product development/fixes, so exceptional tools will likely enable [more] exceptional work. I think this may even be important enough that sacrificing GM staffing levels in favor of a full-time [web] developer devoted strictly to the development and maintenance of GM tools would yield a net profit of surprising levels.

Over its shelf life a game changes. The community changes, and the challenge is to keep the game relevent to the customers. It’s an ongoing challenge, and the Game Master crew is in the position to play a significant role.

That’s a thought that’s been simmering for a while now. For the time being I am flexing Excel and VBScript as much as I possibly can to make the tools I find I really ned on a day-to-day basis, but I am hitting the limit of what’s possible outside of more serious development work. I’m seeing opportunities for some really useful metrics creation that can be done without the need to hassle the game development staff. Sara Jensen would be proud