Wow! We made it to the end. This week people will wrap up projects. Instructions for final project handins and post-mortems are here.

• Tuesday, December 11 – Last Lecture! There will be a lecture. I’ll talk about some stuff like animation. Don’t forget to send your playtest feedback to the TA before class!
• Thursday, December 13 – No required class. I will go to the lecture room at class time in case someone wants to come by to talk about something (if you have questions about technical topics, the games industry, or whatever). It’s optional – feel free to use the time to work on your project, study for your other exams, or anything else.
• Friday, December 14th – Festival of Games! We’ll meet in 1358 (the lab) at 2:30 and play the final versions of the games! Show off how things turned out! Experience the cool things your classmates built! Make sure your game is handed in before the lab session starts.
• Friday, December 14th / Monday December 17th – Your final project handins are due. This includes a group post-mortem, as well as a personal reflection. We really need to get everything before noon on Monday, December 17th so we can get our grades done.

The final parts of Project 3 are due at 2:30pm on Friday, December 14th.

There are a few pieces of this (each detailed below):

1. The actual game itself, handed in and runnable in the handin directory, including instructions and a note as to whether we can keep it public. Note: the deadline for this is fairly strict (2:30pm on 12/14) since we’ll be playing the game at that time.
2. The “group post-mortem” – a document written by the group (collectively) answering the questions described below. It is mean to be written as a group activity. Note, while this is due 2:30pm on 12/14, everyone gets a no-cost extension until Monday 12/17, noon. Your group only needs to turn this in once. Please email it to both the professor and the TA.
3. Your personal project reflection. Each person should do this individually. Note, while this is due 2:30pm on 12/14, everyone gets a no-cost extension until Monday 12/17, noon.

Remember, the reflections (group and personal) are actually part of your class grade.

Project Hand-in

You need to turn in your game into your handin directory.

The index page (what one sees when they do to “YourDirectory/”) must have:

• A brief description of the game, including the title (and that it is a class project for CS679, Fall 2012).
• A list of the group members.
• A statement as to whether you are willing to leave this game on the “open” web for anyone to see (especially future classes). If you say "We do not want this game to be left on the web”, then the TA and Professor will remove it once grading is complete (we will archive it). Please do not remove it yourself.
• Either the instructions for the game, or a link to them.
• A list of any components you used (open source libraries, artistic resources that you borrowed from, …)
• A list of any requirements. For example you might say “This game was tested only tested on Chrome v. 23.”
• A link to start the game.

Make sure that everything you need to play the game (including the instructions and resources) are in the handin directory. Do not link to other directories.

Your game must run from the handin directory. If there is some technical problem with this, please try to work it out with the TA before asking for an exception to this rule.

Group Post-Mortem

As a group, we would like you to prepare a document discussing some aspects of your game. Please turn in one document for your whole group. While this is due before exams, you are allowed to turn it in late with no penalty (provided we get it before noon on noon on Monday, 12/17).

Please answer the following questions:

1. What did your group learn from the play-test?
2. How is your game different from what you showed at the play-test?
3. What libraries / art resources did you use for your game? What did you use them for? Do you recommend them? (if you tried something and didn’t use it, please mention that as well)
4. What features might we miss out on if we play the game? Since we won’t be able to play it a lot, and we might not be good at it, we might miss some things that lots of effort went into.

Per-Person Reflection

Each person should send a per-person reflection to the professor and TA. These are confidential (we will not tell your classmates what they said).

1. Evaluate the game your produced. How happy are you with it? (this is about the actual thing we would play when we go to the web page – ignore any ugliness behind the scenes). What is good/bad?
2. If you had another week, what would you do?
3. Evaluate the process by which the game was made. What went right/wrong? How did your team work together to make the game? How did you divide up the tasks/coordinate?
4. For each member of your group: give them an evaluation. What did they contribute? How good was their contribution? How well did they work with others?
5. For each member of your group (including yourself): what grade would you give for this project and why? The “why” is particularly important if you don’t give everyone the same grade.
6. It’s a cliché to ask “what did you learn from this project.” It’s also a difficult question to answer (but good self-reflection). So you can answer it if you can think of it.
   An easier question (or pair): What advice would you give to someone starting this project? or What would you do the same/differently from what you did if you had to do it again?
7. Evaluate us (the course staff) with regards to this project. What could we have done to help you have done better? What should we keep/change about this project.

We do need to get your reflections (group and personal) by noon, Monday, December 17th, so we can do grading.

After the playtest, you must record your experiences. You should probably make notes as they do on and type them up afterwards.

Send your playtests feedback to the TA by email before class on December 11th.

For each game that you played: please include:

1. The name of the game, and the person who “observed” your playtest
2. Whether or not you were able to play the game without any “hand-holding’” (were there instructions? was the game self-explanatory (with the instructions?) or did you have to ask questions to the observer. (This should be a sentence or two about how easy it was for you to figure out what to do).
3. What do you think about the game in the current state? Is it playable? Fun? Buggy?
4. What do you think about the game in principle – over look the fact that it may not be overly polished (yet). Do you think the game would be good if the authors did some more work? Why / why not?
5. What do you think would be the most important things for the team to do to make the game better?

We’re expecting a couple of sentences / bullet items for 2-5

For each person who you observe playing your game, please include:

• The name of the person
• How successful were they at figure out what to do? How well did they do at playing it?
• How well did the game work for them? (did they uncover bugs? have performance problems?)
• How did the challenge level work for this player? Was it too easy/too hard? How could you adapt for this person.
• What did you learn from watching this person?

Try to record as much as you can – later, in your post-mortem, we’ll ask you do go through all these play tests and assemble them into a single plan of what to do. Here, its mainly to collect data for doing that bigger planning.

Send this writeup (for all of the playtests you were part of) to the TA before class on December 11th. You may put it into one email, or send a bunch of smaller emails.

We’ve gotten into the home stretch here – just 2 weeks left to wrap up projects, and any topics we’re going to talk about. There won’t be any readings or assignments, so you can stay focused on your projects.

The big thing this week is the playtest on Friday, December 7th. As we’ve mentioned in class, this will be logistically complex. Remember to send your availability between 1:30 and 4pm to Mark (the TA) so he can schedule things. More details about how the playtests will be given in class.

• Tuesday, December 4 – We’ll talk about some more graphics tricks (shadow volumes, ambient occlusion, …), and start talking about AI.
• Thursday, December 6 – We will talk about the procedure for the playtests. We’ll talk about some other technical topics (probably AI).
• Friday, December 7 – Play test. There will be a set schedule where in scheduled 15 minute blocks you’ll be either observing someone playing your game, or playing someone else’s. You will be required to write about what you see (brief comments on the other games, and what you’ve learned about your games).

I should also note, that since we don’t have assignments and readings, the only way for you to learn what we’re talking about is by having you come to class. So for this phase of class, we’ll just have to assume that if you don’t come to class, you’re not learning the material, and the converse (if you come, you’ve learned the material – which admittedly is a crude approximation).

We kept going through the notes on graphics stuff useful in games. (see 11/27)

We went through parallax mapping, relief mapping, environment mapping, and shadow mapping. (it was mapping day!)

As we get closer to the end, I thought I would give you some details as to how the class is going to wrap up (at least the project aspects).

Friday, November 30: the Tech Demo

For this milestone, you should have a playable prototype that conveys that all of the technology behind the game is going to work. It might not all be wired together. It might not be a tuned or fun (or even complete) game. But it should give a pretty compelling idea of what the player is going to see and do.

This milestone is an important checkpoint. If you aren’t (at least) this far along, you will have a tough time having a complete game for playtests (coming soon).

We want to check in with each group to make sure you are this far along. Although, to be honest, if you’re not that far along, about all we can do is say is “good luck, you have a big task ahead of you.”

For this milestone, all you need to do is have someone in your group show a brief glimpse of the game to Mark on Friday, November 30th. He’ll be in the lab during lab time. Alternatively, you can give him a demo at the end of class on the 29th (if you’re ready). Or send him a link where he can try the game online (if it’s sufficiently self-explanatory).

(Note: I will not be at lab session on 11/30. If you have questions for me, talk to me in class on Thursday, or send me email on Friday morning – I will have limited email access on Friday afternoon and over the weekend).

looking ahead:

Friday, December 7th: the Playtest

On one hand, the play test is just that. A chance for other people to play your game and give you feedback.

On the other hand, this is one of the main places that we’ll get an impression of what your game is. So you can sortof view this as the most important demo. It’s also the one time where everyone in class will play your game. You don’t want to waste their time.

During lab time, there will be a relatively tight schedule where each person is scheduled to receive (and/or give) a demo during a time slot. If all goes well, every person will play every game – with one of the games authors watching.

To make the schedule work, each group will need to have their game turned in and running from the web before the session begins.

Details on the logistics will be given prior to the event.

From this, everyone will be expected to write notes about what they learned as part of the gold master.

Friday, December 14th: Gold Master

In lab session time on Friday the 14th, we’ll have a “Festival of Games” where we can spend some time enjoying the final results. The final versions of the games are due at this time. They must be turned in before the class time.

There will also be a number of other documentation elements that are required. Each person will need to write a post-mortem/reflection, and there will be a group written handin (mainly describing what feedback was received at the playtest, and how the game was changed). More details will be provided closer to the date.

We’ve made it through Thanksgiving, and are now ready for that final push towards the final project! We’ll use class times for lectures (usually), but we’ll cut back on readings and assignments so you can stay focused on projects.

• Tuesday, November 27 – Lecture on Graphics. We’ll talk about lighting and shading and other graphics topics.
• Tuesday, November 29 – more discussion on Graphics. Topics depend on how much we get through on Tuesday.
• Friday, November 30 – project milestone (playable demo). This is the last major milestone before the play test (which is December 7th). Your group needs to show a playable prototype. Not all the elements need to be put together (you can have independent examples of the different technologies, you might not have levels or progression or …) – but there should be something that looks and feels like a game. The exact mechanism for us to check on this is TBD

Next week, we’ll have some tech topic lectures (probably animation and/or AI), but mainly it will be getting ready for the playtest.

(note: these notes were covered over 2+ days. day  1 we got through bump mapping, day 2 was all kinds of advanced mapping, leaving shadow volumes for day 3)

High Level Review: (see Lecture 7):

What are the goals of graphics for games?

1. Fast (keep up the frame rate)
2. Dynamic (respond to what’s going on)
3. High Quality – works for the game
   1. works with the style (realism, cartoon, stylized, …)
   2. avoids visual artifacts
   3. provides enough cues
4. Control / Authorability – we can get what we (or the art directory wants)
   1. without undue experimentation/work

Rendering Review

How does physics light a scene

Key concepts:

• surface interactions and micro-geometry, subserface
• local vs. non-local vs. global
• direct vs. global
• reflection vs. glossiness

Texture Mapping and Image-Based Stuff

Motivating Image-based methods

• pre-rendered
• sprites (depth ordering, alpha, …)
• shape-changing sprites
• texture maps
• billboards / skyboxes / special cases
• more general imposters
• layers

Review

• motivations
• texture coordinate generation
• filtering

Animation by fiddling with texture coordinates

Other texturing tricks

• volumetric textures
• world-space textures
• slide projector textures
  • tool for lighting and shadows (later)

Other Maps

• Surface properties
  • color
  • material properties (shinyness, glossiness)
  • local geometry (displacement map, normal/bump map, occlusion map)

Texturing Surfaces

Problem: still a flat surface

View Dependent Textures (very simple thing)

Displacement Maps (move geometry) – really messy to do

Bump Map / Normal Maps (move normals)

Parallax Mapping (constantly evolving)

• depending on view direction, look somewhere else
• walk along direction of ray (based on height)

Parrallax Occlusion Mapping (see gamedev.net)

walk along ray until you hit something

Relief Mapping (Manuel’s page) (paper)

• use image warps to pre-compute the ray casts
• where does the point go on the face of its bounding box
• extend this to shadowing

Light Maps (of various forms)

• pre-compute lighting on the surface (somehow)
• keep it around as a texture
• texture combining

Environment Maps

Basic version

• small object / big world assumption
• capture lighting box (envionment map)
  • box vs. sphere vs. cylinder
• pure specular (reflections)
• filtering issues

Environment Map Lighting?

• Hack version (old car racing games)
  • earth is brown
  • sky is blue
  • lighting colored by direction

Environment maps to capture light

• Captures all lights (direct and indirect)
  • from a distance, permanent in the scene
• Issues
  • dynamic range (direct light much brighter than non)
  • so far only for specular
• Idea 1 – sampling beyond the specular ray
  • issue – self-occlusions (ignore for now)
  • rays for glossy
  • rays for diffuse (lots)
• Idea 2 – small samples (but area)
  • equivalence of samples and blur
  • pre-filtering (to make equivalence of lots of samples)
  • problem: how to pre-filter an environment map
    • MIP-MAP per cube wall? (what about corners?)
    • Spherical Harmonics
• Why?
  • arbitrary complex lighting environments (not limited to number of lights)
  • specular reflections
  • glossiness
  • dynamic lighting? (re-render the environment map)

Shadows

Some basics

• umbra / penumbra / lit area
• hard vs. soft shadows
• self shadowing

Hacky shadows can be useful! (ball over plane example)

Reasons why shadows are useful

Casting Shadows

Hierarchy of Hacks

• Drop shadows (splotches) on floor
  • paint dark circles
  • paint light areas (spot-light)
  • how does this interact with existing colors
  • prospective hacks (for arbitrary point lights)

Shadow Maps (NOT light maps)

• draw scene from the light’s point of view
• use as colors (everything is shadowed, even things casting shadows)
• use as items (so you can tell what is/isn’t shadowed)
• use as depth
• Gotchas
  • other than spotlights (cube environment maps?)
  • depth bias
  • item buffering doesn’t really work (very small polygons, moving)
  • get first and second objects (two depths)
  • aliasing (need high resolution to get sharp edges)

Shadow Volumes

• basic idea (extrude each triangle)
• point-in-frustum checks to see if in shadow
• relatively efficient ways to use z-buffer and stencil buffers to perform checks
  • where you see the polygons, turn off lighting
  • 3 passes: draw z+dim, draw shadow volumes (stencil), draw bright (where not stenciled)
  • several ways to do mask pass
  • simple = (1) draw scene (dark) (2) draw back, things occluded get stenciled as on (since they are behind volume) (3) draw front (places where occluded is in front of voume) (4) un-shadow what’s not marked
• Gotchas
  • need to combine/simplify geometry
  • expensive to do lots of fills 3 times

Towards more global illumination

Ambient Occlusion

• soft shadows for self-shadowing
• adds darkness where you get less light
• independent of the direct lighting

Basic Ideas

Bent Normals

Implementation

• ray sampling
• multiple shadow drawing
• multiple direction rendering
• screen space methods
  • hack – estimate how much forward facing occlusion
  • naïve version does lots of texture reads
  • clever random sampling tricks to minimize reads (16?)

Why is AO so cool

• easy and cheap
  • pre-computed for objects
  • SSAO for game scenes
• gets major depth effects
  • dark in pockets
  • creases cause changes
  • low-frequency soft shadowing effects

SIGGRAPH ASIA 2009 Course Notes (complete, good intro, gets to details) http://dx.doi.org/10.1145/1665817.1722963

SIGGRAPH 2012 Course Notes (brief, teaser for the book)http://dx.doi.org/10.1145/2343483.2343500

Reading Assignment 8

Why HCI (see 2011 notes)

Usability vs. Games

Nobody learned to play the violin because it was easy (or play chess, or baseball)

How does usability matter?

Frustration vs. Challenge

Design Principles

Don Norman boils it all down to 2:

• Visability
• Conceptual Models

Is needing an instruction manual a cause or a cure?

Other key concepts:

• Affordances
• Natural Mappings
• Constraints
• Indicators of actions
• Feedback
• Hidden state (and making it visible)

Elevator button example.

Engineering Tradeoffs

What do you trade usability for?

• Efficiency
• Fun
• Aesthetics
• Cost
• Space/Size

Evaluation and Execution

Basic steps:

1. form goal
2. execute
3. evaluate

Detailed steps (from Norman)

1. Form Goal
2. Form Plan
3. Specify Action
4. Execute Action
5. Perceive what happened
6. Interpret
7. Evaluate

Important: usability issues in ALL of the above stages.

• Gulf of Execution
• Gulf of Evaluation

Notes from student example

• Me: elevator (old w/o numbers to new)
• Shree – Water tap (when things go wrong)
• Scott – Multimeter (why still need to re-plug probes?)
• Drew – Thermostat
• Zhouyuan – washing machine (coin op)
• Mik – Vacuum cleaner (feedback, affordance, constraint, …)
• Joey – PC
• generic vs. special purpose
• internal state (debuggability)
• Eric – Pandora
• Zach – Dropbox
• Sam – Chrome