Group Size: 2-3 people
Deliverables: Working “tech demo” (shown live, but submitted as video), short presentation and a 2-4 page report
Judged on: Technical quality, originality/creativity, amount of effort, delivery of demo and presentation, clarity and completeness of report

The focus of the final project should be implementing a new feature for a game engine, using a low-level language such as C++ or Cg (for shaders). A good place to start would be with an Ogre3D project and extend that towards a more functional game engine. Some ideas include: On-line resource management (e.g. new types of resources, streaming resources), off-line resource managment (editors, tool chain), human-interface device management (e.g. supporting chords and taps for a fighting game), internationalization (being able to switch languages/cultures, support remote editing of content), incorporating a physics engine or making a simple one from scratch, rendering effects (using shading languages). These are only a few examples, feel free to suggest more and discuss with instructor.

About half-way through your group will meet the instructor for a quick status meeting. Bring questions and get feedback. (exact time to be determined)

All presentations take place Monday April 4th (14:00-16:00) in M124. Notice that we will most likely need to stay a bit longer than the regular class time. Let the instructor know if you cannot stay the whole time.

The total time you have is about 10 minutes. Aim for 4-6 minutes for slides and 4-6 minutes for demo and questions.

You should have a slide for: (1) Purpose/Motivation (what is your technology for); (2) Related/Existing Work (similar things that exist / what work did you build on); (3) Your Contribution/Exciting Technical Features/Solution.

The purpose of the slides is mainly to establish that you know why you are doing this, and that you know that others have tried before and that you have done something technologically interesting. The final report will go into more technical discussion, so you don't have to go into too much detail unless you would like to explain something in particular in some depth.

Use your time well. It is very important to plan/rehearse your demo. There is nothing worse than trying to figure out during your presentation what you would like to show us. That typically means you spend valuable time messing around with the interface and/or forget to show a couple of important things. Write down on a piece of paper a demo script and time it before you arrive, so that you know that you can get through it in the allotted time slot.

There are three things you need to hand in:

1. Your presentation slides.
2. Technical Report: A 2-4 page document describing the technology you presented in more detail. See the full section on report below.
3. Screen capture video: Use screen capture software (e.g. Fraps to capture a run through your demo. Compress that capture and either submit it into MySchool along with the reportif it is small enough or submit a link to it. You do not have to provide narration. The video and the report will tell the story together.
4. Optional: if you can produce a runnable version of your demo, I would love to get a copy. You are not required to do this, since it may be hard to make this portable. It will not factor into your grade whether you can do this or not.

This project will be graded on:

• Technical soundness (did you get the technical demo to work “as advertised”?)
• Knowledge and amount of effort (did you clearly spend time on solving the technical challenge?)
• Clarity of presentation (do you explain and pace your presentation well and technology demonstration and ?)
• Quality of report (structure, readability, technical contents)

This is a short but informative, report about the final project that should include:

1. Title / Authors
2. Screen shot (At least one at the very top of the paper - see formatting instructions below)
3. Short abstract (At least one paragraph summarizing what your project is about)
4. Motivation (What is your technology addressing? Who would want to use it? Usage scenario)
5. Related work (Examples of similar things other have done. What existing work do you build on? What other work inspired you?)
6. Approach (Explain your technical design and implementation - this is the meat of the report)
7. Results (Mention what worked and didn't work)
8. Future work (What would you do next if you had more time?)
9. References (A list of cited references in the correct format - see below, even if you only have one or two)

Think of this as a poster submission to a conference.

The paper should be written in a 9 or 10 point justified serif (Times or Times Roman) font in two columns per page, with a single line space. It should be 2-4 pages long.

Other than that, follow the guidelines for a technical paper submission to the SIGGRAPH conference as much as you can (don't worry too much about the details, just get a feeling for the overall structure and look):

• SIGGRAPH Instructions for Authors
• SIGGRAPH Submission Template (LaTeX)
• SIGGRAPH Example Paper (PDF)