Why I Don't Play Wow Right Now

I played World of Warcraft for nigh on two years straight starting in closed beta, took a break, came back for The Burning Crusade, and then stopped again when summer of 2007 ended. Why? Because, in a manner of speaking, I had already figured out all the patterns in the game.

I should probably rephrase that, but I was trying to tie it to James’s post earlier (he is borrowing my copy of “Theory of Fun”). I have not solved every underlying pattern that WoW has to offer, but I have experienced almost all of them, and they do not change. When you have a persistent online world, and you are expecting that people are going to pay to play in this world, you need to provide them with reasons to continue playing. Now is the time that you point out “but Matt, Blizzard is making another expansion…” and I say, “Yes they are, but I would like to address a point that going into and beyond simply releasing more content.”

Creating alternate characters is the other way, besides simply growing the world, that MMO’s retain players. However, I tend to find playing alts to be tedious most of the time. This is where I tie in the whole pattern issue. I have already played through this part of the world. Many times. Nothing changed. I am doing the same quests for the same people, in order to receive that same loot. What I would like to propose is the idea of a much more dynamic quest system.

In WoW there are two factions, Horde and Alliance, with different races and different starting areas. However, once you get to around level 30 or so, as either faction you end up in the same neutral zones doing the same quests. From 30-60 I did the same quests on my Horde rogue as I did when I was 30-60 on my Alliance priest. The quest giver simply changed race and name.

Obviously generating dynamic quests on the fly is a very tricky issue, considering that the majority of all quests in all role playing games are probably hand written and planned out. As a temporary solution I would also be strongly in favor of simply creating quest trees with different branches. I would be much better to be able to follow one branch in a series of quests, and then if I come back as a different character, I could follow a separate branch for different results.

I think as MMO’s continue to evolve, we will see worlds that are increasingly more dynamic, and this requires increasingly dynamic tools to work properly. Perhaps one of the reasons that we are in what I would call a quest rut is that the NPC’s in WoW don’t “require” anything. The dwarf who sends me off to kill the yetis that took over his cave is not going to actually return to his cave. But what if he did, and the next time I ventured by he needed other materials in order to rebuild. That is the kind of dynamic quest structure that would make me want to roll another character to and continue playing…and paying.

GDC, and theories on fun.

GDC is almost upon us, and I'm getting excited, as well I should be. As a gamer and a computer scientist, I can't imagine an event that would combine more of my passions. Well, unless it was a game developer's conference with a rock climbing competition and Mystery Science Theater 3000 playing in the background the entire time. Until the day that dream is realized, I will be content with attending the GDC. Plus, it's in San Fransisco, so I get to visit somewhere new.

I am a bit nervous though, since part of the reason I am going is to try to land a job. Since I don't graduate until May, my resume is a bit sparse. I am lacking the, "Must have shipped two games on X console" each job seems to require, but everyone has to start somewhere. I will be putting the finishing touches on my resume this week, and I guess we will see what happens.

On a slightly unrelated tangent, I have been reading "A Theory of Fun for Game Design" by Raph Koster, and despite how irritating I find the title (for it's casual use of the word "theory," which is a topic that has no relevance to this blog), I am benefiting greatly from reading it. First and foremost, it has got me thinking about things that I had never even thought to think of before. That was an odd sentence, so let me give you an example: I had never thought about what it is that makes games fun.

As I wrote that, I realized just how ridiculous that sounds from someone who is trying to get into Game Design. After all, shouldn't that be all that I am thinking about? It wasn't that I didn't think the topic wasn't important, I just assumed that I already knew. I've played enough games to know what I find fun, but I had not considered why it's fun, or even exactly what it is beyond "winning" and "crushing all those that stand before me."

Koster's book presents the idea that underneath their pretty exteriors, games are all really about patterns, and our brains love patterns. We delight in finding them, and in a game this is what we are doing when we start to win. We have started to recognize the underlying patterns in the game and have learned how to exploit them. I won't go into all the reasons Koster provides because he does a much better job presenting his point of view than I do, but I have to admit, it's got me thinking. I'm not sure how much I agree with him, but the important thing is that I'm now thinking about something that I had taken for granted. And thinking is good.

I hope to follow up on this post with a bit more of my impressions of Koster's book, but that may have to wait until after GDC, when I have a chance to reread it. And speaking of books worthy of a reread, "The Pragmatic Programmer" by Hunt and Thomas is also on that list.

TorqueX and Artists.

With the start of the new semester, Matt and I have been discussing possibly working on another game. Now that we have some experience with XNA and have a pretty good idea of what not to do (See the postmortems), we might just be ready. Not to mention GarageGames is holding a competition for indie developers which ends in February.

One of the other groups in our game design class decided to use GarageGames' TorqueX engine, and they had by far the most polished looking game. Given our short time line for this project (a little more than 3 weeks after the semester begins) an engine is definitely looking like the way to go. The hope is that instead of spending most of that time programming the game we will be able to test the game mechanics early on. If we can avoid spending time writing code that someone else is providing for free, why not take advantage of it?

I can foresee two possible problems with this. First, any new technology takes time to adopt. We may understand XNA, but we are going to have to learn how to use TorqueX. To help mitigate this we are going to look into bringing one of the students who used TorqueX for their game into our team.

The second possible problem is the engine itself may limit what we do. For example, have you ever seen a web site made using Frontpage? Chances are, it looks very similar to 99% of web pages made with Frontpage. We need to be wary that our game does not become a generic TorqueX game.

Matt and I both touched on the topic of using "programmer art." Wolfgang has shown us that if we are going to be creating our own art assets, it will be both time consuming and of lower quality. Our strengths are in designing and coding the game, so that is what we should be doing. This time around we are going to try to recruit some outside help. Surely we can find some art majors that would be willing to donate their time and expertise for a nice resume piece.

Bringing in more people means that Matt and I are going to have to have a pretty good idea as to what exactly we are doing. As Matt mentioned, we suffered without a solid design document last semester, and that was with three like minded people. Before we start bringing people into this, we are going to have to have a plan and direction. If everyone has a clear idea as to what they are doing, we shouldn't waste as much time butting heads and stepping on toes.

And version control. This time we HAVE to use version control.

Wolfgang Postmortem - Matt Style

James touched on many important points during his review of the last semester of programming, and I would like to bring up a few ideas that were important from my point of view.

One of the largest struggles that you have trying to create games with a three man team (none of whom are true specialists in any of the crucial parts of game design: art, AI, sound) is trying to figure out who is going to do what. Even though I am the one studying art, none of my studies involve doing 2-D artwork, and thus James decided to step up and take care of that section. John really wanted to work with sound, and that left me doing a large chunk of programming. As one of our visiting lectures said “you never want to use designer artwork” and I would argue you never want to use designer anything…however when you are stuck being the designers, and everything else, you work with what you got.

I feel that one of our biggest downfalls was not having a fleshed out design document from the beginning. We ended up having to figure out a lot of the gameplay while we were trying to program the game. We had some of the basic ideas of what we wanted to accomplish in the beginning, but up until the very end we were still debating about how the game should end, what abilities the player had, how the wolves would work, etc. So for next time, have a working, fleshed out design document ahead of time, so you know exactly what you need to be tackling.

As James mentioned, the wolf A.I. is very lacking. Wolves attack you as you run forward, and once they are left behind, they are redrawn in front. This method was adopted mainly because I was having issues with game performance when managing the creation and disposal of wolf objects in the game. For some reason, we were unable to figure out why the memory was not being appropriately allocated back to the system (or conversely, where I was getting into exponentially nested loops) and so our attempts at having more dynamic wolf behavior was rather stifled.

One of the most important lessons from computer science that was enforced in making this game was using multiple inheritance (multiple inheritance in C#) in order to deal with drawing objects in our 3-D world. Since draw order is especially important when you are drawing 3-D objects, having a way to sort those objects help. Since I was able to have the trees, wolves, and cabin inherit from the ForestItem class, I was then able to just use ForestItems in the Comparor class.

Best Wishes,
Matt

Wolfgang: Postmortem

Wolfgang is done! Or rather, we have turned it in. It is still not finished by a long shot, and we plan on making some improvements after winter break. But anyway, without further ado: Wolfgang

Before continuing on to the postmortem, I should explain what our goal was with Wolfgang. Our assignment was to create a unique game as our semester project. With a focus on creativity, our group (Matt, myself, and John Lloyd (another St. Mary's student)), decided to try something a little bit different.

We decided to concentrate on immersion instead of gameplay. These two things are by no means mutually exclusive, and more often than not go hand in hand, but due to our time restrictions we decided to focus on immersion. For our artwork we went with a surreal nightmare look because we knew that if we attempted a realistic look the results would be laugh. We slimmed down the controls to a bare minimum, so that they would not distract non-gamers. We also decided to have no HUD. The only thing on your screen is your player and the environment.

To achieve this, and still be able to lead the player to the cabin in the middle of the woods, we used audio cues to guide them. If you needed to go left, there is a voice that tells you just that. This feature was both criticized and praised. Praised as a unique and interesting way to incorporate sound, but criticized for limiting the accessibility of the game. Fortunately we can resolve the accessibility issue by adding visual cues, but then we run into the issue of how to do that without sacrificing our original goal of increasing player immersion. I am curious to see what we come up with for our next release.

Now on to what we did wrong. First of all, I am embarrassed to say this, but we did not use any sort of version control. We knew that this was a bad idea when we started, and now we know from experience why. I doubt that I need to expand further on our difficulties and I can offer no legitimate excuse, so I will move on.

In my mind, another glaring flaw is the third person viewpoint. A first person view would have been much more immersing, but here we decided on the third person view so that you could easily see the wolves chasing you. In the current build though, wolves don't chase you, they just come straight at you. While there was no way to anticipate having to cut the chasing wolves, I am now wondering if they would even work well with a third person view. I would like to experiment with a first person camera for the next release. It should not be difficult to do, since the game is now in 3D.

Which brings me to our next mistake: trying to write a 3D engine. Originally we had decided on making the game in a puesdo 3D, much like Wolfenstien 3D. Everything would actually be in 2D, but we would scale and translate our objects to make them appear to be in three dimensions. After spending far to much time on it, we realized that we were basically creating our own 3D engine. I found myself going to my Vector Calculus Professor far to much, and we were being bogged down re-inventing the wheel. Finally we switched to 3D, and within a day we had the game looking better than it did after a month's worth of work. Trying 2D turned into even more of a time sink than the artwork.

Wolfgang: I am not an art major.

On the Wolfgang project (link to final build to be posted soon) I have been doing quite a bit of the artwork, and it has been quite the learning experience.

Programming wise this project is more difficult than past assignments, but still manageable. With exception of our attempts at rewriting the 3d engine, which will undoubtedly be discussed in our postmortem, the only real difficulty we faced was the scale of the program was larger than anything we have worked on before.

The artwork, however, has been a huge time sink. It takes hours to create one animation, which chances are won't even look as intended. It is disheartening to spend six hours on a running animation which looks more like a seizure than a sprint.

On the bright side, my once non-existent artistic ability seems to have almost reached a mediocre level. The same can be said for my photoshop skills. I have also gained a healthy respect for those who have spent the time to develop their artistic abilities.

And why did I choose to do the artwork for the game without so much as a high school art class? Well, at least it was a learning experience.

Welcome

Wombat Storm Entertainment is a pet project by two full time students, Matt and James. It was started with the intention of supplementing their resumes with examples of their writing and interest in the field of Game Design. Matt and James also expect that the blog will give them an outlet to work on their writing skills, especially in the third person.

-James