Writing up your Project

1
Writing up your Project

• Gareth Bellaby

2
Style, grammar and spelling

• Take note of the feedback from the mini-paper.
• 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.

3
A technical project

• Consider the technical basis of your work.
• The project should include a general overview of
  3D implementation.
• The maths of converting from model space to world
  space.
• The maths of projecting the scene onto the
  screen.
• The view frustum.
• Vertex shaders.
• Pixel shaders.
• Do not re-use lecture diagrams.
• Produce your own summary and your own diagrams.

4
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.

5
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

6
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.

7
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

8
Interface

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

9
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!

10
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.

11
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.

12
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!

13
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.

14
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.

15
Polish

• The work should be polished.
• Some of the write-up about polish turns up in
  design.
• Some turns up at the end, possibly in a chapter
  on its own.
• Could be combined with the evaluation section.

16
Source code

• Source code should be placed on a CD.
• The CD 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.

17
The software

• Full specification as to how to run the software.
• Controls within the software
• Starting the software
• Full specification of the environment, dlls etc.
  Preferable to have a standalone build.
• Checklist- write down the SDK version and/or any
  other environmental libraries.

18
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.
• 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).
• Optimisation. Discussion of real-time, timing
  considerations and the optimisation process.

19
Example 1 Tech Demo

• Polish
• Evaluation
• How good it looks.
• Speed/efficiency.
• Conclusion. What's new and interesting about the
  work.

20
Example 2 AI project

• AI project RTS game with groups of units moving
  and fighting.
• Intro.
• 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.

21
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.

22
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.
• Conclusion.

23
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.