Office hours: Tuesday, 4-5pm

Text: Class notes (so make sure you come to class!), will be posted on-line after each lecture.

Grader:

TBA

Work by students who have agreed to put their work on-line:

is here

Course description:

This will be an intensive course in which you will learn principles of game design by studying well designed existing games, and implementing original games.

You will be implementing lots of games this semester, so be prepared to work and to keep up with the class. Generally there will be an assignment every week. If you have a heavy course load in other classes, you might want to consider not taking this class.

Also, you are expected to do your own programming, so don't take this class if you are a weak programmer. From the beginning of the semester you will be writing Java programs as part of your work for this class.

At the start of the semester you will be working individually, but for most of the remainder of the course you will be working in teams, with each team member taking on rotating roles of game design, art direction and evaluation.

Evaluation is an essential part of game design. A game is not complete unless people other than yourself can play it successfully without you standing over their shoulder telling them what to do. Achieving this goal can be harder than you might think. For this reason, a significant portion of your work this semester will consist of learning how to properly evaluate games, and then how to iterate design based on that evaluation.

Homework due Wednesday, September 15, before class:

Remember to send me an email (my email address is on my NYU home page) with the subject line "GAMES CLASS". In your email tell me what URL you will be using as your homework page for this class. That's where you will posting your work for this semester.

Unpack the file examples1.zip to get the directory containing my little starter game/ package and the two examples -- test1.java and the version of pong.java we implemented in class.

In order to assure backward compatibility with all web browsers, be sure to compile your java files using the directives:

javac -source 1.2 -target 1.1 ...

Your assignment for next week is to implement a game, but not pong. :-) Your game should be implemented in Java, and posted to your class homework page. Feel free to use the support classes from examples1.zip, or not, if you prefer. Also, feel free to modify any of that code.

Your game needs to be finished and up on your page before the start of next week's class.

Reminder:

Next week's class (5pm, Wednesday September 22), will convene at 35 West 4th Street, in the classroom at the second floor computer lab. That's where we went at the end of this week's class.

I'd like you to make a music game. To get you started, I've put together a simple example.

Note that in the game/ directory I've added the class MidiSynth.java. I wrote this as a convenience wrapper around Java's midi package, so you wouldn't need to get bogged down in those details. Of course you are very welcome to modify that code in any way, and explore the full power (and complication) of Java's midi handling library.

The example I've put on-line is not yet a game. It's just a simulated musical instrument, in which you can rearrange the keys into any position, and then move a "mallet" around to play those keys. My simple example mainly serves to give you all the code you need to integrate midi into your game.

Your assignment is to come up with an original game that incorporates player's making music in some essential way.

It's a game (as opposed to just an activity, which is what my example is), if there is a clear goal structure. The player needs to be able to face and surmount a challenge, and received some sort of reward for having done so (even if that reward it just a simple acknowledgment).

It's ok for your game to be inspired by an existing game (such as Dance Dance Revolution), but I want you to add something distinctive and original.

When thinking of ideas, you might want to think about how you can combine the "players making music" paradigm with existing genres of game, such as construction games, matching games, maze following game, racing games, side-scrollers, simulation based games, or trivia games, to give just a few examples.

Feel free to make several different games, rather than just one, if you have time. You will learn a lot more by trying different things and comparing games against each other.

Your homework for September 29 is a much easier one than the previous two: Choose one game that you like very much and prepare to talk about it.

Your job will be to prepare a five minute presentation about this game, which you will give in class on September 29. In your presentation, identify what genre of game it is (eg: first-person shooter, simulation, matching game, sidescroller, etc), or whether it is a combination of two or more genres.

Also give an assessment of why you think this particular game is so successful, compelling and fun to play.

Finally, make one suggestion about something you could change in the game design -- whether in the reward system or the game play or anything else -- and try to analyze what impact your change would have on the game.

Here are the instructions for connecting with Jan Plass's class:

If you have not done so already, email Tsu-Ting, (tth216@nyu.edu), stating that you are in Ken Perlin's games class and that you request access to the ALEX site. Include your netID. Then:

• go to alex.nyu.edu
• log in with your NYU netID and password
• click on E19.2176.001.FA10
• use the menu on the left to access syllabi, forum, etc.

As I said in class, I'd like you to put a brief synopsis of the results of your previous homework onto your web page. It should just be a plain text description, consisting of: (1) The game you reviewed; (2) the genre of the game; (3) a single paragraph in which you state what you particularly like about the game; (4) a brief explanation of the change you would make to improve the game.

For next week, continue to brainstorm on the shared Google Doc, putting in your ideas, as well as any images that support your ideas. I expect everyone to contribute at least one idea that they think will really help the game. Ten ideas would be good too.

In class next week everyone will get a chance to briefly talk about the best ideas they came up with, so your contributions will be acknowledged. Also, if you haven't contributed anything interesting by next week's class, it could get embarrassing for you.

I've modified the simple music game, as we discussed in class. You can download examples3.zip here.

Once you unpack this folder, you will see modified versions of game/Platform.java and a modified version of simpleMidiGame.java that uses it, just as I showed in class. In particular, I've added the reflection code to examine object fields and then write them to a log file.

You won't be able to run this on the web, because of security issues. However you can run it locally using appletviewer, which will allow you write log data to a local file.

Your job for next week is to adapt this to your mini-game. You can use one you already wrote for this class, or you can try to write a new mini-game.

You don't need to use my way of tracking data, if you think you can implement something better.

You don't need to analyze the data by next week, just get to the point where you have successfully written log data for a game session. Post the data that your game has generated to your class page.

This week you are focusing on working with the teams from Jan Plass's class, and you will be presenting your prototypes from those joint projects.

At 5pm on Wed Oct 27 you should go directly to the classroom of Professor Plass at 35 W 4th St, 2nd floor, because we will all be meeting this week together with the other class.

There are two things you should be working on right now:

(1) Continue to develop your prototype from the math game in the joint project with Jan Plass's class, incorporating any feedback that you got from last week's presentation.

(2) Develop the I Scream Zombies game. Now that you've started to learn how to create math games, we're going to build on those skills by starting to build this into a game that teaches math concepts, with multiple challenges held together by a common narrative (eg: the narrative of maintaining an ice cream truck in a town threatened by zombies).

Now that the narrative themes have developed sufficiently (we will decided definitely on the exact theme toward the start of this coming Wednesday's class, based on the state of the shared Zombies game play doc), I'd like you to start building actual prototypes for game play. Feel free to create little prototypes of game play on your own. Anything you have by Wednesday you will be able to show in this coming Wednesday's class, which will be largely devoted to fleshing out the structure for this game that will allow for multiple game challenges to be incorporated into a single unifying narrative game world.

Going forward, the game is going to be developed on a basis of "survival of the fittest": The most compelling game play prototypes will most likely be the ones that make it into the final larger game.

Since we will be able to incorporate multiple challenges into this game, more than one game mechanic can be incorporated, as long as you stay on theme. You can, if you like, reused code from the individual projects you have already built for this semester.

You don't need polish at this stage -- just the game equivalent of a rough sketch. The important thing is to show what the player does, and how the game responds.

Think in terms of score-related transations that test math skills -- such as player operations that require a demonstrable math skill to influence the amount of ice cream or the number of zombies (eg: by influencing customers' zombie-virus health level).

Eventually we will be incorporating tracking objects into the game, so that we can do post-analysis of game play to gather player statistics. You might start thinking about that in a general way that as you design your game-play prototypes. In this coming Wednesday's class we will start to define just what those in-game data tracking objects will look like.

We decided in class last week to hold off on doing a larger group game around math, because you are already doing something related to that in Jan Plass's class, and because a number of students really wanted to concentrate on implementing some of their game ideas around the theme of ice cream and zombies.

So we organized into teams of either two or three, and each team is going to build an "I Scream Zombies" prototype according to their own vision. This coming Wednesday each group will have a chance to present their prototype, and the rest of the class will give a critique.of what is presented.

The more you have a working example of game-play to present, the better. It doesn't need to be a computer program. A "paper prototype" built with card cut-outs will do just fine for this week's presentation.

Read the following and be prepared to discuss them in class on November 17:

• What do Prototypes Prototype?,

• Game Design Basics,

• Presentation Iteration,

The second document is the first chapter of Tracy Fullerton's book "Game Design Workshop". All of these materials will help you to improve and iterate your game prototype. Note that the third document contains a summary of the iteration process, from the same source.

Thanksgiving eve!

This week we will be meeting at Jan Plass's class, at 35 West 4th St., 2nd floor. This class will be devoted to the run-through of the game you are doing in your joint projects with the other class.