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