Saturday, November 13, 2010

Unite 2010 round-up

I've been in Montreal all week for Unite 2010 and I figured I post up my thought on the conference now that things are winding down as we wait for our flight back to the states. In short summary - the conference was awesome, for something that is substantially cheaper than the spring's GDC festivities, the quality of sessions was superb.

Some highlights of the week were:
  • Tools: Lots of talk about developers simplifying their workflow and empowering their artists/designers by writing custom tools with Unity's great flexibility. Adam Mechtley = genius editor tools, best hope his recorded talks get posted.
  • New breadth of platforms: Unity Technologies is trying to become all encompassing, now spreading to support for Windows, Mac, Web Player, iPhone, Android, 360, PS3, and Wii. The demo of the PS3 version looked like it was very easy to use.
  • Unity Asset Store means that Unity Tech now also includes people that make middleware for middleware in their target consumer base.
  • Great Conference party hosted by Unity Tech on Thursday. Open bar = win.
  • David Helgason's collar was, as usual, popped straighter than god.

Wednesday, November 10, 2010

What makes games look good?

After several rounds of seeing games in my game development portfolio class, I;ve begun to ask myself why do so many of the games struggle to achieve an acceptable level if visual quality. As a graphics programmer this is something that concerns me greatly because often times our purpose is to facillitate the best looking game possible. So why then do many student projects fail to achieve a professional level quality in their aesthetic?

It would be simple enough to argue that academic programs with a smaller pool of artists will be the driving factor behind poor game aesthetics. I think the issue goes a lot deeper than this for a couple of reasons, but having a stronger artist community will indirectly be associated with better looking games. The reason I think this is that it takes a large slice of the team to make a visually pleasing game. Programmers need to have good animation controllers and neccessary shaders, artists need quality textures and animation, and designers need to create levels that allow players to take in the aesthetics of the game properly.

So in the end, I almost feel like the greatest obstacle to good looking student games is a general lack of caring, which almost seems a little harsh. However, I think students too readily cave to only just scraping by with their games for class. This is why a strong artist community will have a strong impact, because not only will artists have better resourcces and expectations for their artwork, but they will also know when their programmers and designers are screwing them over.

All in all, I hope to see more good looking student games in the future.

Thursday, November 4, 2010

New Project: Motion Blur + Depth of Field

Before the end of the semester, I have to complete a final project for my Advanced Graphics class, and I picked the topic earlier this week. I'm going to be focusing on doing implementations of Motion Blur and Depth of Field. The plan is to do at least two different implementations of Motion Blur, one focused on the version in GPU Gems 3 and the other implementing the accumulation buffer method, where previous frames are averaged together.

I haven't entirely decided how I'm going to implement Depth of Field. There's one good article also residing in my ever mentioned GPU Gems 3, but I haven't looked at too many other methods yet. More on that later :)

Tuesday, November 2, 2010

Half-baked State Machines: Living with Regret

So I feel like programmers sometimes look at system that needs to be stratified into a state machine, and they ask themselves a very dangerous question "Do I really need to make this all that robust?" The answer should usually be STFU and write a decent state machine. I've had to deal with a state machine built on a switch statement that has now grown to over 2500 lines, which is the players character controller, and I want to smack the code's original author for giving me such a bee's nest to inherit.

Even with this most unfortunate experience under my belt, I still looked at a simple AI that I needed to write for my latest project, and thought "I bet I could get away with just a switch statement." In the end this is by and large a failure on my part, because even though the state machine get's the job done, I'm going to have to rewrite it if we decide to expand the scope of the game beyond the 4 weeks its currently set at.

Things that are important for any state machine:
1) Calling the active states update function each frame (or however frequent the state machine is supposed to act)
2) Letting the active state know when it is being exited
3) Informing the new active state that has just been entered

Anything that does not incorporate all 3 of these in a smooth and coherent manner can rapidly become a headache. This should be commons sense, but I've caught myself and another programmer falling into the same trap with this... So I figured it might be worth ranting about.