Posts

Posted on

Elegant Solutions

Juice Analytics posted a synopsis of an article  on “Elegant Solutions” from the Change This web site.  Here’s a quote that sums up the “elegant solution” ideal:

Elegant solutions avoid the traps of: 1) Swinging for the fences; 2) Getting too clever — i.e. too many bells and whistles; 3) Solving problems frivolously.

…An elegant solution is one in which the optimal outcome is achieved with the minimal expenditure of effort and expense…[and is] is recognized by its juxtaposition of simplicity and power.”

It strikes me that game design, especially MMO and Virtual World design, has as its goal elegant solutions to everything.  The breakthroughs I experience in a challenging design problem are most often a result of asking things like “What are we already doing that has something to do with this system?  Can that already-existing sytem or mechanic be the solution to the problem at hand?  How can that already-existing system be extended to solve the problem at hand?  Let’s take a step back and restate what exactly we need to solve in this case.”

I think the best solutions are [nearly] categorically elegant in nature.  And besides, there’s something so very satisfying to creating an elegant solution.

Posted on

Newbies, Tutorials, and Teaching the Game

I just read Sara Jensen’s post Teaching in the Newbie Experience.  It’s a must-read.

In short, nobody reads the tutorials.  Nobody reads the manual.  Nobody enjoys ambiguity in how things work.  Nobody enjoys stuff that doesn’t work the way they think it should work.

 I read either a forum post or a blog post recently that talked about some now-defunct MUD.  The author seemed to glorify how arcane, non-intuitive, and “brutal” the entire game was.  Also, in some old MMO post mortem, the author mentioned a design decision to require manual editing of a text config file in order to play the game, so that no “stupid people” could play it.

It’s been my experience that, like it or not, there is a slight superiority complex that very “computer people” can easily develop.  On occasion, or more often, I can’t be sure, this frustration with “the masses” at their inability to grasp the simplest of “logical computer concepts”, whatever they may be, squirts out in some aspect of the user interface.  Sometimes it’s a nod to some arcane old-school MUD (just like “literary nerds” drop references to obscure classic literature).  Other times it’s full-blown “normalized database-style” interfaces.

I don’t think it’s any different than how people in any specialized field feels toward “the masses” who continually mess up what seems quite self-evident.  So, that just means any and all game mechanics MUST be designed and revisted over and over and over again with the view of “make it stupid simple and make it stupid obvious how it works”.

Oh, and good job, Sara.  You said it better than I.

Posted on

Stage Gating Development for MMOs

Joe Ludwig wrote about how stage gating applied to game development won’t work.  I think the gist of his objection is that the game development process is inherently different than ones that will work with stage gating.  Since, stage gating requires  similar processes in all the “stage gated products”, and each game has a relatively unique process, they won’t work with stage gating.

For game development to be a defined process, we would need to have the same goals for a game that we had for the game immediately before it. We would have to staff the teams exactly the same way, with at least the same levels of experience and training if not exactly the same people. We would have to want the same game to come out the other end of the process.

It was interesting to read another person’s response to the article published at Project Horseshoe on stage gate development procedures.  I read through the reports a week or two ago and I was excited at the potential for new approaches to the development process.

My take was that inherent in the design phase the game’s components are identified, and these components are ideally independent of each other (they are not too interrelated).  Then, we identify those components that are most “new” or “advanced”, and set the early stage gates to be the successful development of at least working prototypes of those “newest” or “most advanced”.  Clear and aggressive goals must be identified in these stages, such as “scalable advanced AI for independent creature control”, complete with test results demonstrating as much as well as focus group reactions to the promise of such a system.  Then, the more familiar game systems are set to later stage gates.

The design process must include very clear identification of exactly what it is that makes the game unique.  Likely, that boils down to one or two game systems that are either “new” compared to other games or “more advanced” than other games.  Those one or two “distictifying” systems must be the first few stage gates.  If they can’t be done by a certain date, then there is no point in continuing the project, because without the “distinctifying” systems, the game is going to largely end up a differently-skinned <fill-in-the-blank-with-game-title>.  If a project is given the deep-six, that’s when we heavily document the code, write a detailed post-mortem, and archive everything with the goal of making it easily “pick-upable” some time in the future, or at least easily understood as to exactly what challenges proved to be too much.  (this could actually be a pleasant experience for the team)

So, all that to say that it still seemsto me that stage gating can indeed be applicable to game design.  I think exactly how is a bit of an unknown, but charging into the unkown is exactly how the newest, greatest stuff comes to be.

Posted on

Mid to Long Term Goal

When I decided to succomb to the “Game Design Bug” I started looking around teh intarweb for information on how to get jobs in the game design field.  Low and behold, there is tons of stuff out there on just such a topic.  One of the tips that struck me as quite important was the one about having a portfolio to show.  So, that’s what I’ve been doing.  Primarily I’ve been working on design documents.

Design docs are not easy as one may initially think.  You find that your grand game system idea has a lot more to be spelled out than you realize, and that’s even when you’re an experienced game designer.  However, that’s exactly what you need to do and I find I rather enjoy coming across unforseen problems with game mechanic interactions.

Sorry to delay.  Here’s my current project.  I want to develop a dynamic creature population system that essentially takes care of all creature population maps.  The ideal is that we don’t need a person to manually place every creature spawn spot, all the creature spawn spots take care of themselves, and over time each species as a whole will end up being located in the general vicinity of preferred terrain types.  So, a map designer can think in more general terms in regards to creature population maps and how the map as a whole will “tend” towards.

I will be using the Realm Crafter MMO game engine for this project.  I’m not a programming whiz so this is a bit of stretch for me, though I will be using a scripting language built in, so it shouldn’t be too much.  I will update as things develop.

Posted on

MMO Beta Testing

On days where I’m a bit less-than-motivated to write, I usually surf around MMO-related blogs and sites in hopes of coming across something that catches my interest.  Many times these things get my mind working.  This entry is the result of one such sojourn.

MMORPG.com has an article in September of 2006 about Richard Vogel talking about beta testing these days.  I think the thought that most stood out was that the MMO beta tester population is not being utilized to its potential.

Richard mentioned that the MMO beta tester population today is different than it was in the past.  Currently, many people join the beta test simply either to play the game for free or to try it before they buy it.  Those participants who are truly testing the game and submitting reports are fewer than they were in the past.  Having been in the opposite extremes of this “beta test motivation” continuum, I hope to throw out a few ideas on how to further improve upon the existing beta test programs.

One poster on the forum thread commenting on the article captured a few techniques that could vastly improve the beta test process:

You want opinions of the non-vocal majority?  Implement in-game polls.  Ask.  Randomily send tells and request feedback.

In my beta test experiences, I’ve always been “one of the masses” with the test assignment of “just play the game and report any bugs you see”.  As a result I felt a bit aimless, and knowing that anything I do in-game will eventually be wiped, I don’t particularly want to grind xp.  I wanted to have some kind of assignment, even if that assignment is only “do whatever it takes to buy a house and decorate it somehow”.  Also, I wanted some instruction as to how I could submit the most useful bug reports.

So, by simply sending out in-game messages to beta testers requesting the “testing” of certain types of activities as well as certain areas to especially pay attention to, a few things could happen: an increase in the “testing” aspect of the beta, intense testing of particular sub-systems, as well as a likely increased depth of reports.  Imagine an occasional tip on how to best use the screenshot or video capture utilities to create bug reports.

Some forum commenters mentioned what amounts to more enhanced in-game bug reporting tools.  I think it would be quite beneficial to include a small package of relevant utilities with the beta client download and updates that give the typical non-techie-type the ability to easily make screen shots and videos.  For me it took more time than I really liked just locating programs to take screen shots and videos, much less figure out how to use them and then figure out how to create useable reports.

I recognize the beta test period can be simply a stress test opportunity, meaning general player comments and even bug reports are not particularly going to be helpful, especially if you already have a great QA team.  However, even if it’s only a stress test, tell everyone.  Send in-game messages and tells requesting people to try to do as many inventory open-close-move-delete operations as they can over the next minute.  This way you can get focused use, and I bet this focused use could allow for some highly efficient stress tests on top of the regular ad-hoc stress testing.

Posted on

First Post

I’ve tried blogging in the past, but in each case I didn’t have any kind of enthusiasm for it.  I was just trying to do what all the cool kids were doing.  I think that may have changed on this go.

About 1 month ago, after a prolonged series of “what do I want to do” crises, I finally justified to myself that enjoying life, enjoying how you spend the majority of your days or at least having a passion for the goals toward which you spend the majority of your time working, is rationally the most fundamental rule one can hold on to even in the midst of absolute uncertainty about anything and everything else.  Inherent in the “enjoy life” rule is a compatibility with every school of thought that I am aware of, whether it be religious, atheistic, economic, etc.  I suppose you have to add in there a certain awareness that ”long-term” enjoyment will generally yield better results than “short term” enjoyment.

I think the tipping point, as it were, came when I read “Now, Discover Your Strengths” by Marcus Buckingham and Donald O. Clifton, and incidentally, I think everyone should read this in high school.  The premise is that we tend to describe ourselves in terms of negations and abnormalities:  “I’m not good at sports.”  “That person is agoraphobic.”  “I have a problem with math.”  As a result of this negative-based vocabulary, in general we have developed an ability for astute identification of weaknesses, and that skill, combined with the ideal of the “Renaissance Man”, brings us to focus on our weaknesses and how to improve them.  The problem with this “weakness-fixing” is that we tend to ignore our strengths.  The theory goes that by the time you’re around 16 your brain has largely “wired” itself, and as part of that “wiring” process it has pared down the diversity of neural pathways to a handful of primary ones, around 5.  Those primary neural pathways entail the easiest and quickest ways your brain can process information, implying that when presented with information that needs processing your brain tends to send it down one of those 5 processing pipelines.  Combined with the fact that endorphines are released when neural connections are executed, use of these pipelines allows for quite a lot of “feeling good”.  In short, the book says each of us has around 5 of the roughly 34 known “innate talents”, and instead of trying to develop new ones, which physiologically won’t happen after your brain has finished “wiring” itself, we need to identify these innate talents and play to those strengths.  Then, you can take their “Strengths Finder” test that will help you identify your specific set of strengths.

All that to say I finally have a good reason to fully embrace design.  It’s something I have tended towards since I was quite little, but until now I have resisted it out of some misguided sense that I should keep “improving my weaknesses”.  Specifically, I’m into virtual world design.  The context within which players exist inside an MMORPG.  And I’m not talking about cursory ideas, I want to dig deep, considering every possible angle on how to appropriately simulate reality.