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

An Afternoon with Ben Wallace

Hello again everyone, it has been awhile since I have posted here. James wanted to start blogging again, and since he is focusing on doing a Monday post, I said I would have a post up by Wednesday for all of our non-existent readers.

Monday afternoon I had the privilege of meeting and listening to Ben Wallace, Engineering Lead for the Halo series. Ben gave a very interesting presentation on how he developed solutions to creating highly realistic lighting and material for Halo 3. Halo uses the tried and true method of bump mapping to apply textures to their models, and this gives the model much more depth without requiring more vertices. Bump mapping using take a flat texture that has different normal values (how much and in what direction the light bounces off) for different areas on the texture. When this texture is applied to a flat object, that object acquires depth.

Much of the depth on the textures in Halo 3 comes from this technique. This by itself is not a huge contribution to game engineering, however Ben’s techniques for dealing with the massive amount of calculations that need to be performed is more so. Unfortunately for all of you, I did not take any notes during this talk (I wasn’t really thinking about blogging at that time). To sum it up, many calculations need to be done in order to deal with reflections of the world on shiny objects, light reflecting around the world, High Dynamic Range lighting – which is what happens when you are standing in a shadowy area, and there is incredibly bright light coming in from an outside source – and Ben and his team created and modified ways to approximate all of this so that Halo could be played with anything resembling a decent frame rate.

All in all it was an interesting presentation, and Ben is a very nice guy. I have rediscovered why I don’t think I will ever truly be a software engineer like he is, I just don’t have the penchant for learning math and honing my skills to the degree of sharpness that is required. Some things that he did mention at the end: If you want to be a game engineer you should definitely pursue some high end calculus, vector geometry, and other middle level mathematics. Along with that, make sure you are actually working with implementing these kinds of things on your own. Nothing will convince a game company to hire you more than seeing you have the initiative to do work for your own sake.

In other news, in the next few months, James and I should be starting on a couple new XNA projects for our own enjoyment. I am sure more details will be put up here and we flesh out the ideas we have right now.

Next week – talking about Braid and probably Rock Band 2!!!

-Matt