MTWThF, 4:30-5:20, MGH 271
We will meet each day during the first week. After that, with few exceptions, we will not meet. (Any exceptions will be announced a week or so in advance.)
| Instructor | John Zahorjan, Sieg 411, zahorjan@cs | |
| TA | Rabi Lahiri, beni@cs |
The colloquium presentation of your games will be Wednesday, June 4, 3:30-4:20.
In addition, this quarter we have the following requirements:
To accommodate this additional requirements, the teams this year are a bit larger than usual.
Working in teams is hard. If you're very lucky, someone on your team will be a gifted facilitator - someone who spends time (and is good at) making sure everyone is getting along and making progress, and that the team as a whole is communicating. A facilitator is an extremely valuable team role; you're sure to have plenty of people who can code, but it's not certain who, if anyone, will be able to assume any kind of leadership position.
It's common for people to become frustrated with each other. The first four times you think to yourself "Harry is lame" the problem most likely lies with you, not Harry. Whatever you're contributing is going to be most valuable if it's surrounded by things other people have contributed, and so it's to your benefit to make sure Harry is contributing. As a team, you should find something for each person to do that (a) they want to do, and (b) they can do. Everyone has skills the others don't.
Make your best attempt to help Harry contribute. When you've done that four times and you're still thinking he's lame, there's a real problem. It may be that some other person on your team needs to handle it, or it may be that the course staff have to handle it. Coming to the staff is not turning someone in, it's just letting us know that there's some kind of problem. We promise to use our own highly fallible judgement coming to any conclusion about what the problem might be.
It is critical that you are sensitive to the role of ownership in team work. There is an ownership hierarchy. The entire class is one large team with joint, but loose, ownership of everything. There is no such thing as cheating in this class - help each other out. An individual team (dev plus associated art team members) owns the final product. It is crucial that everyone be allowed to contribute to what that product becomes. No one is going to work hard on anything that they have no influence on (and you can't afford as a team to have anyone not working). Finally, each person on the team needs to have some identifiable role that they own, and that is their responsibility. When you're done, everyone should have had some role they're proud of.
How to best organize varies from team to team, depending on the personalities and skills. At teams of this size, it is impractical to try to do everything as a group of equals. Different people should soon have different responsibilities. Your group may decide that someone will act as the big cheese - when disagreements arise, that person will make a final decision. That's okay, it isn't a violation of any ethic. At the same time, the big cheese has to be careful not to take themselves too seriously.
To try to improve things, this year the course staff is taking an overall ownership role. It is our goal to end up with three demonstrably stunningly great games. This means we are very motivated to make sure that when the course ends, and you all go on to great things, that we're left with three games that, for instance, can be downloaded from the web by the general public and then actually launched and played.
To help meet our objectives (and also to provide regular feedback to you as the course goes on), we plan on the following:
You'll get feedback as a team on the build and game hopefully by the weekend. The checkouts will start on April 9.
You will receive probably brief, individual mail with our impressions, as well as a grade (that summarizes those impressions). It is your job to make sure our impressions are accurate.
Additionally, pre-integration you don't have a game. Post-integration, you do, even if all it is is boxes moving around in a simple world. Once you've achieved integration, development becomes a lot easier. You'll basically be improving a game, piece by piece. It's much simpler to work independently, and so to get a lot more done by having everyone working at full capacity.
1) The need for a possitive feedback loop. It is very easy to point out what's wrong in a game that sometimes people forget to compliment their peers about their hard work. We all need some lovin' and giving each other compliments once in a while helps reduce the stress and in a possitive way, motivate and inspire one another. Don't limit this just to your teams. In the end, you are all working together and solving the same problems. Share and help everyone succeed -- that's the very reason why we have Siggraph and the Game Developers Conference. 2) Intuitive Game Controls + Code + Art + Audio + Level Design + Game Design + Communication = Great Game All the above components help create a great game. This is a lesson usually learned too late by game teams and they fail. Show your latest code to one of the art guys and inspire them. Show your awesome concept art/model to a programmer and inspire them to integrate it! You guys are not getting paid doing this and motivation is something very hard to maintain, especially in a big team. * Note that audio is as important as graphics. Think of audio as free polygons and animation. If you're behind a door and you hear a beast growling outside, the renderer is only rendering the door while the player is busy getting scared. 3) More on Communication If you have doubts in what you are doing, e-mail someone. Before you go to the lab, figure out what you should be doing before getting there. That's why schedules are very important -- even if they are wrong! Here's the truth, schedules are always wrong. The purpose of the schedule is to provide an artificial way to motivate the project. If you guys are self-motivated and keep track of your progress, your schedule will end up being very adaptive to your progress and keeps log of who's resposible for what and the dependecies. One simple feature or piece of art could stop the production of a game for three days -- that's a big chunk of your schedule already. 4) Spatial and Temporal Locality is very important There's a reason why companies spend a lot of money on having an office space. Yeah, e-mail is cool. My cell phone rocks but there's no replacement of having everyone in the same lab making decisions in 15 minutes instead of two days! * instant messaging is kinda ok...
There should be layers of goals based on time and space. For example: every 20 seconds, need to dodge enemy fire and traps, every 1 minute, need to collect a gold coin every 10 minutes, need to collect a special key every 30 minutes, need to gain enough points to win the game Things that need to happen every 20 seconds needs to be spaced out so that the player can interact with it. Or one can speed up the objects (speed of the enemy, enemy projectile) *** This is what I call the heartbeat of the game. You know when you are in the zone when you can't think of anything else but beating the level! Create places in your level where you can force conflict (interaction between players) which technically can be accomplished by making narrow tunnels, or if the location that everybody needs to be at is specifically made small. Don't try to make things realistic... real life is boring that's why you play games! Although rock-climbing is not necessarily boring :-) Multiple win conditions are cool... let the player decide how he/she should play! > win by collecting gold coins > win by killing the most mosquitos > etc... Duh! Play some good video games and steal ideas from them!
Make it easy to tweak your game (Make it Data-Driven) Being able to change any piece of content or game attribute without the need of a re-compile is the key in making a game fun! Store attributes as text files. Have naming conventions for your content. Let everyone try out an idea and make it easy for everyone to do just that. Making a good game is easy. Making a great game is harder. Making a game that you can make money out of is the hardest. That's it for now, I'll talk more about software design later on to give you guys some hints on how to set up your game data-structures so that they can scale well as well as some internal information on what the WebDriver is doing in the backend so that you guys can organize your data to maximize the processing pipelines. If you have some time, you can read this paper that I wrote a couple of years ago about game engine design. The part about Hierarchical Programming might be an interesting read. http://www.bytewave.net/future/design/hedge/hedge.htm Remember, we're not trying to cure cancer here... we're just making games, so please keep your drama and stress in perspective :-)