Computer Game Development at Michigan Week 1: Introduction

Published on: January 8, 2014

Today marks the first lecture for EECS 494 Winter 2014 - Computer Game Design and Development. Today also marks the first of a series of posts detailing my trials and tribulations in the class. The main reason I’m doing this is that at Michigan, Computer Game Design and Development is considered a major design experience, also known by the acronym MDE. In the computer science engineering program guide, this is what it says about MDEs:

The MDE is a capstone design project taken during one of your final two terms. It is comprised of three courses, which should be taken concurrently.

The problem is that I’m not taking them concurrently. The other two courses are on professionalism and technical communications, and these consist of writings and presentations on your MDE. Since it will be eight months until I take these classes, I will most likely forget details, and so I have decided to write everything down so that I have content to refer back to when I am taking the other classes. I somewhat voluntarily chose this schedule. It wasn’t my first or second choice as I became waitlisted on those, and instead of risking it and ending up with a terrible schedule, I decided to it was worth breaking up the MDE. My schedule of twelve credits will allow me to work full days on Tuesdays and Thursdays while allowing enough time between classes to fulfill another workday.

For reference, I’m walking into this class with absolutely the bare minimum of what one would call video game development experience. I read a book called “Game Programming For Teens” when I was twelve. Not to mention my complete lack of knowledge when it comes to video games. Five or so years ago, I would have called myself a pretty well versed gamer. I played console games, read gaming magazines, and could talk games with the best of them. Nowadays, I very rarely play video games, if at all. So while I just sit with a blank face when the Professor makes a reference to a game I have never heard of, everyone else has heard of it and nods along. This feeling of dread is exasperated when the professor repeatedly says the class is not going to be easy. Always the optimist, I don’t think this will be a problem. If it does become a problem, I could always tune into twitch.tv and watch professionals play. Not likely, but at least I have a backup if needed.

As far as actual development is concerned, we will be using the Unity game engine, which I have only heard about. I actually have no idea how to get started; I can only assume it is some sort of specific framework language. However, my biggest concern with the engine was whether I could use it on the CAEN computers here at school because it does look like it is a rather heavy install, and it is my pet peeve to install programs on my computer. Thankfully, the school computers have the software, but it is 0.3 versions behind the current stable release, so I am a tad worried that there will be compatibility issues.

The professor is Jeremy Gibson, probably one of the youngest professors that I have had the pleasure of being taught by. Some of his credentials are that he is a brand new author, IndieCade chair, GDC speaker, and has been a professional programmer and a university professor for a combined 17 years. On the first day of class, I can already tell that he will be one of the most enthusiastic professors I will have. You can tell that he knows how to communicate as well because he made a two-hour class seem short by keeping us engaged the entire time.

Throughout the semester, we are required to edit a class wiki that is dedicated to analyzing games. Here is what is required in the analysis (I ripped off the definitions from the class slides, which were in turn based off “Elemental Tetrad” from Jesse Schell):

• Mechanics: The rules for interaction between the player and the game. How does the game work? What are the different modes?
• Aesthetics: How the game looks, feels, sounds, smells, tastes?
• Narrative: The narrative of your game. Is there a story line?
• Technology: The underlying technology that enables your game.

We have to create pages on five games or add our viewpoints on ten. This may be a problem for me because my video vocabulary isn’t as big as it used to be. I may sneak by if I create pages on universal games such as Pong or Tetris.

I found it quite interesting that towards the end of the lecture we were told to split into groups and play a card game similar to UNO. After a few games, the professor asked for opinions. The overwhelming majority griped about the seemingly deterministic nature of the game (I’d wager Skip-Bo is more deterministic). There was no skill involved and no incentive to pay attention to other players when it was their turn. Then each group was assigned an additional rule in the game and once again, we convened for analysis. Some of the additional rules were showing your final card face-up, announcing “UNO” when the player only had one card left, or being able to play out of order if another player can follow rank. Each of these rules had a different effect on the game with some of them forcing players to focus more on the game in order to win.

I believe it to be a good start. Now I have to find games to analyze.