Writing up your Project Gareth Bellaby

Style, grammar and spelling Third-person. Arrange with your supervisor for him or her to look over a draft of your project, I'll typically ask for a chapter to read. Structure dealt with below. But note the need to signpost and cross-reference. Get someone else to proof-read it. Why not swap your project with someone else and each proof-read the others' project. Use Harvard notation for references and bibliography.

A technical project Consider the technical basis of your work. Do not re-use lecture diagrams. Produce your own summary and your own diagrams.

What have you been doing? Make is completely clear as to what you doing. You are implementing a real-time, interactive program. You are implementing 3D dynamic visuals. You are implementing a time-constrained program which is required to be efficient.

Clear and explicit The write-up should be explicit as to what your software is. You also need to be explicit as to what you are bringing to the project: Architecture Renderer Real-time (the game loop) Maths: 3D maths of vectors and matrices. Affine transformation. Translation and rotation maths. Non-affine (projection matrices). Quaternions

Clear and explicit Timing. Optimisation Shaders and other advanced rendering techniques More maths, e.g. physics, collision detection, line-of-sight, targeting, particle systems. AI Instancing Messaging Each of these would probably warrant a chapter in its own right.

Software Design UML diagram: classes and attributes, connections (inheritance, use, association). Almost certainly you will have polymorphism. The UML diagram should reflect this. Make sure you show me or Laurent the diagram! Other possible design techniques you might bring in: FSM diagram (gameplay, AI) Algorithm design

Interface The 3D environment. The control system. The User Interface. Cameras and perspective. The maths of the camera positioning.

Pictorial Material The project must include screenshots in the body of the work. We expect to see diagrams, figures and pictures. We actually expect to see lots of them!

Evaluation Include an evaluation chapter. Some examples of evaluation criteria: Visual appeal Realism Aesthetic appeal Gameplay: fun, appropriate. Polish. Speed, efficiency. Architecture (e.g. Renderer could be used scenes, make this clear) Interface: ease/simplicity of use.

Testing Formally run the program on different machines. Use a testing strategy. Provide bug reports. Formal testing: average frame time preferably with different features turned on and off. Report any issues. Description of the scene elements The look. Looks pretty (or whatever effect you are after), aesthetics. Lights. Cameras, aesthetic reasons for why cameras are placed. Composition.

Originality Typically game project have a high degree of originality. It may well be the case that you working on a new technique which does not exist in any commercially released game. It is likely to be the case that your primary sources of information are NVidia whitepapers (for example). These are indicators of originality and cutting-edge techniques - so say this!

Bibliography A good project has a sizeable bibliography. Include lots of references. There are academic works which deal with graphics and AI and you must therefore cite them! For example, a discussion of the A* algorithm should include a reference to the 1968 paper by Peter Hart, Nils Nilsson and Bertram Raphael. A good sized number of references, say 20+.

Artwork and other associated material Talk about any associated files and materials. You receive no marks for the production of artwork. However, file conversation issues are certainly part of your project. Configuration files. Map files, or other data files.

Source code Source code should be placed on a pendrive (or otherwise made electronically available). The pendrive should be clearly marked and checked to ensure that it is not corrupt. Clearly indicate which material is original and which you've used from course material or from elsewhere. Include short snippets of code in the text only where relevant, e.g. optimisation or a particular implementation that you are proud of.

Structure Structure is generally the same for all projects: Abstract Introduction. Specification of the problem, overview of the project, summary of chapters. Literature Review Design. Main body of work ---- Several Chapters! Evaluation. Testing. Self-reflection Conclusion. Bibliography May be one chapter, or even part of the Conclusion

Chapter Structure Structure for each chapter mainly follows the same structure. Use case numbering. n.1 Introduction. n.2 Main body of chapter ---- Several sections! n.3 Conclusion

Example 1: Tech Demo Tech demo: graphics techniques using parallax mapping and soft shadows. Introduction. Specification of the problem, overview of the project, includes sections on running the program, interface and controls. Literature Review Design. UML, architecture. Renderer. Description of the main render. Shadowing. Parallax mapping. Diagrams of rays, etc. Includes a section on file formats (illumination of depth maps).

Example 1: Tech Demo Optimisation. Discussion of real-time, timing considerations and the optimisation process. Polish Evaluation: How good it looks. Speed/efficiency. Testing Self-Reflection Conclusion. What's new and interesting about the work.

Example 2: AI project AI project: RTS game with groups of units moving and fighting. Intro. Literature Review Design. UML of renderer/game engine. x-ref to design of AI and gameplay given elsewhere. Renderer. The rendering process. Gameplay: The levels/maps. UML diagram of game engine. FSM of the gameplay (not the AI itself). Discussion of game loop.

Example 2: AI project Game issues: Physics (of ranged combat). Collision detection. Maths. Interface issues of picking: 2D to 3D to 2D. AI: Design. UML of the AI components. FSM of the AI itself. Algorithms used. Messaging. Optimisation.

Example 2: AI project Polish Evaluation: How well does it play? How realistic the AI actions are. How sensible the AI actions are. Speed and efficiency. Testing Self-Reflection Conclusion.

Example 3: a chapter A single possible chapter in a project about implementing intelligent cameras. Chapter 2: Implementation of the camera 2.1: Introduction. Intro to the chapter. This is what I am going to talk about. 2.2: Background. Theoretical background and analysis of cameras. The behaviour of Cameras and objects. How I have done it. 2.3: Camera types. Maths. 2.4: Implementation. Classes. x-ref to Appendices. Diagrams. May be more than one section. 2.5: Conclusion. A summary of what I've talked about and why what I've done is good.