One of the most frustrating problems that I’ve faced this new year at the University of Michigan has been a new class centered around game development. I joined this class hoping to be able to flex my muscles a bit with my previous experience in taking a video
game idea from start to finish, and I didn’t feel guilty about taking a class I should already have a knack for, as this particular game-development section is part of a course that is required for graduation–A win-win, as the class should hopefully be pretty simple to complete, while at the same time I’ll get a few new ideas about game design under my belt in an academic (rather than article-based) setting.
However, the class so far has been a near-disaster. After switching late into the class (I didn’t know it existed until the term had started), I wasn’t allowed to make up any work, and the lectures so far as I’ve seen are centered around very poor ideas on game design and development. My opinions are certainly skewed due to the fact that I’m independent and plan to stay that way, but many of the ideas they’ve brought up are certainly applicable to the industry at large and, I believe, definitely worth avoiding in nearly all cases.
One development “tip” that was given to us was that we should always try to start making a game by writing the user documentation. As it was told to us in lecture, this is a critical part of game development, and the user documentation is a valued resource to players. This is certainly universally considered an out-of-touch point–as a gamer and developer, I’ve never written nor read user documentation (such as a game manual) without it being a frustrating and annoying experience. Sometimes this is necessary for a game, and I’m sure players have opened up the game manual that comes with most physical discs at some point; however, the only reason that the player had to open up that manual is because the game’s design failed them. Games are an interactive experience; teaching the player how to interact is a critical part of that, and as games are a form of entertainment, that teaching must also be presented in an entertaining way. User documentation is not entertaining. This is.
Another development “tip” given to us was on what our main menus should contain. The lecturer quickly came up with a set of nine items that are necessary for most games, including the title, start, help, customizations, quit, instructions, highscores, etc. He recommended five buttons for the main menu itself, along with submenus as necessary to cover all of these aspects. This idea is almost offensive to me, as I can’t say I’m completely alone when I say that I hate menus. They clutter the screen, they are often hard to navigate, and they pull the player out of the experience. They’re a necessary piece of management in a lot of games, and they have their place, but I feel that it is very important that menu usage is minimized as much as it possibly can. To say that your main menu needs five buttons to be adequate is not just absurd: it’s also lazy. Making your main screen clear and easy to use is something that isn’t easy to do and will require effort, but it’s important. My latest release, Quietus II, has a very simple main screen; your only choice is to press <enter> to continue. Controls are briefly listed on the next page after the intro (not my proudest setup for displaying controls, but at least it’s readily available and easy to see), and you can play. The player can literally press <enter> three times in a row to continue the next level from their last save, and my main menu only has one button. Praepoch is similar–the player presses any button at the main screen, and the game starts. It’s not confusing, and controls are taught in-game. I think that this is design that should be perpetuated. Few people are going to tell you your menu is awesome but, like a field-goal kicker, your only job is to not disappoint.
The last game design opinion dished out in lecture was the first one I heard, and it was the most aggravating. The lecturer (this time different from the above two) told us about how the designer’s portrayal of a game’s storyline is pivotal. The designer must outline how the player plays the game in a puppeteer-like fashion. The designer knows best how to unveil the storyline in a game and provide the best experience for all players. The lecturer went on to say that he’s heard of players who play games like World of Warcraft and Diablo III talking about how they crafted their own experience via PvP and exploration, but that he thinks that that approach in design is invalid, and the storylined approach is the superior method for taking a player through a game. This comment left me aghast, as it really seemed as if he was looking at games like they are books–books are restricted to linear storylines and carefully-crafted plots, which are awesome and can also make for good games, but they don’t utilize games’ most important ally: it’s interactivity. Linear storylines crafted by designers don’t let you interact with the storyline. Some games branch out a bit by letting players move through dialogue with options, but this is just a non-linear adaptation, making it an even more custom experience. Custom experiences are the future of games, in my opinion, and the movement of the industry seems to very strongly reflect that. From indie games like Minecraft, where a newly introduced player faces little to no direction but builds their own interesting story full of zombies, caves, and mining, to triple-A titles like Skyrim, where some of the most fun you’ll have is in procedural, unscripted events throughout the game. A game’s storyline should give it a bar-minimum for complexity and entertainment, but a truly good game should allow for far more than that in how players build their own experience. I almost didn’t even finish the main quest-line in Skyrim, because I was so busy taking out bandits and killing procedurally-generated dragons to care. To think that those experiences are worthless is a major misunderstanding.
These points really irked me, and hearing these out of the mouths of more than one professor really made me question what they can do for me in terms of game development. Not to mention being told that “I’m not the audience for this class,” when the vast majority of students in the game development-focused class are going into other majors, while I’m going into game development.
Note: just want to make it clear that the class is not a game design class; it’s an introductory game development course. However, it was the statements given on game design in the class that frustrate me, and I still think that they are ill-informed and badly supported ideas even if the class is based around development rather than design.