1

Writing up your ProjectWriting up your Project

Gareth BellabyGareth Bellaby

2

Style, grammar and spellingStyle, grammar and spelling

● Take note of the feedback from the literature review.

● 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 projectA 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?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 explicitClear 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 explicitClear 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 DesignSoftware 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

InterfaceInterface

●The 3D environment.

●The control system.

●The User Interface.

●Cameras and perspective.

●The maths of the camera positioning.

9

Pictorial MaterialPictorial 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

EvaluationEvaluation

● 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

TestingTesting

● 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

OriginalityOriginality

●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

BibliographyBibliography

●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 Artwork and other associated materialmaterial

●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

PolishPolish

●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 codeSource 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 softwareThe 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 DemoExample 1: Tech Demo

● Tech demo: graphics techniques using parallax mapping and soft shadows.

1. Introduction. Specification of the problem, overview of the project, includes sections on running the program, interface and controls.

2. Design. UML, architecture.

3. Renderer. Description of the main render.

4. Shadowing.

5. Parallax mapping. Diagrams of rays, etc. Includes a section on file formats (illumination of depth maps).

6. Optimisation. Discussion of real-time, timing considerations and the optimisation process.

19

Example 1: Tech DemoExample 1: Tech Demo

7. Polish

8. Evaluation:

● How good it looks.

● Speed/efficiency.

9. Conclusion. What's new and interesting about the work.

20

Example 2: AI projectExample 2: AI project

● AI project: RTS game with groups of units moving and fighting.

1. Intro.

2. Design. UML of renderer/game engine. x-ref to design of AI and gameplay given elsewhere.

3. Renderer. The rendering process.

4. 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 projectExample 2: AI project

5. Game issues:

● Physics (of ranged combat).

● Collision detection.

● Maths. Interface issues of picking: 2D to 3D to 2D.

6. AI:

● Design. UML of the AI components.

● FSM of the AI itself.

● Algorithms used.

7. Messaging.

8. Optimisation.

22

Example 2: AI projectExample 2: AI project

9. Polish

10. Evaluation:

● How well does it play?

● How realistic the AI actions are.

● How sensible the AI actions are.

● Speed and efficiency.

11. Conclusion.

23

Example 3: a chapterExample 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.