Rock Band 2 and using Properties

Good Wednesday Everyone,

Unlike James, I did not do a good job of thinking of a topic during the last week, slightly busy and such. I did do a fair amount of Rock Band 2 playing, and I will spend a few moments summing up what the multitudes of reviews have said along with a few pet peeves. I think I will also spend a few words talking about using Properties as a method of potentially fostering easier and quicker game development.

Rock Band 2 is a fantastic expansion pack game. No really, it is more a an expansion pack with a few gameplay tweaks than it is a full sequel, however I have no problem spending 60 dollars on 80 some-odd fantastic songs along with everything else. The song list is pretty damn crazy! While there are a few songs which I am pretty “meh” about in terms of their value as a song in Rock Band (Master Exploder, Visions the sound quality isn’t that far off) in general the track list is amazing. But where I feel Rock Band 2 falls short are in the little itty-bitty details which you often notice when you play a game a lot. How come my previous scores are displayed as they are? Where are the stars I earned, or how about the percentage of the song I was able to complete? Why aren’t these options I can turn on and off? The more I am able to customize my interface, the happier I am. These are not hard things to implement. All of these fields are being stored by the game, and I should be able to tell the game which ones I want to see. Overall Rock Band 2 is very worth the money, I just wish that it was a slightly more polished presentation.

Now, on to using the paradigm of Properties to maybe help develop games quick and easier. Properties are something that I use at work. Essentially I have the ability to adjust values in my program by simply changing them in the property document, and then restarting the program rather than hard coding them in and having to constantly re-compile. What if we wrote a helper class that, at runtime, would read in a text document which had a map of values and used those when running the game? The guy is hitting too hard? Well turn down his damage and restart the game. This allows for quick and easy tweaking without having to go back to the source code. This also allows for an easy way to modify the game if someone wants to make it easier and harder.

Now the system I use at work is incredibly robust, and what I explained here is only a tiny fraction of its power. However, it was designed and written by people with much more experience than myself. I simply think that some of the ideas behind it have a lot of potential.

Anyway…until next time!
-Matt

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