This document covers the notes and discussions during the meetings of the project team.

Jan 18th 2008

Participants: Programmers team full participation

Duration: 4 hrs

- Discussion of two different game ideas:

o Alley Katz(Sameer KUMAR)

o A survival game(Gorkem PACACI)

- For both of the ideas, members are going to write one-page descriptions and post them on assembla.

- Decided to use google groups for in-group communication.

Jan 25th 2008

Participants: Programmers team full participation, and GPM students also joined.

Duration: 6 hrs

- Decided to use assembla.com’s internal messaging service for in-group communication.

- One more week will be allowed for the ideas to get mature.

- Discussing about the coding conventions.

- Discussing about the current game ideas with GPM members.

- Coding conventions will be written to assembla wiki page, and will be opened for discussion.

- Discussed the heartbeat function in the game. Kenneth and Rushi are going to have a meeing with Andy Sapeluk to get help on hardware side.

Feb 1st 2008

Participants: Programmers team full participation

Duration: 2 hrs

- Discussed to change the meeting date of the week

- One of the GPM members work on Tuesday, and the other works on Wednesday, so it’s the best choice to keep meeting on Fridays.

- Sameer has a flatmate who is an artist, he is going to ask for his help.

Feb 8th 2008

Participants: Programmers team.

Duration: 6 hrs

- Voted for the game ideas, and the Alley Katz idea has been picked.


- The writing of the Game Design Document (GDD), Technical Design Document (TDD), and the Creative Design Document (CDD aka Art Production plan/APP)

- Discussed the need for artists and sound engineers.

- The structure of the level.

- The scoring system for the game.

- The heartbeat monitor.


- The completed game should have 5 levels with five puzzles in each. Each level being a different city.

- Types of music that would suit the game. We are using techno remix songs during the riding scene.

- How the race should be started. (girl with bra)

- What sort of obstacles the racer would face. E.g. pedestrians, cars, dogs.

Feb 15th 2008

Participants: Programmers team, GPM students

Duration: 6 hrs

- Andrew attended to the meeting as the artist of the game content.


- The art style. Wind, hills etc.

- Which part of Dundee the game should be held in.

- Tone, Genre, Theme, Story of the game.

- The structure of the level.

- List of animations.

- How many characters.

- Racing blur.

Feb 29th 2008

Participants: Programmers team, GPM, Artist

Duration: 4 hrs

Decisions about the content of the game:

- Checkpoints would be used

- A heartbeat monitor to determine how fast the user’s heart is racing. This will allow the game to reward or penalise the player for getting excited or staying calm.

- Heartbeats count down until zero.

- Completing a puzzle rewards the player with more heartbeats.

- At the start of the level the player will be asked to select their route.

- Which location the puzzles are attached to will be randomised.

- No competitors will be visible on screen, although there will be a constant reminder of how well they are doing.

Mar 14th 2008

The meeting notes for this date has been lost.

Note: We gave a break to meetings after easter holiday, but we kept email discussions going.

Apr 25th 2008

Participants: Programmers team full participation

Duration: 5 hrs

- Discussed the Puzzles

- Three puzzles are going to be incorporated into the game.

o A pong implementation

o A three dimensional snake implementation

o An implementation of Picross puzzle

- Discussed the last situation about the heartbeat monitor.

- As it turns out, we won’t be able to support heartbeat system in the game. Instead, we are going to use a points system. Player is going to collect points from the puzzles, and at the end of the game. Total points are going to define the total success of the player.

May 6th 2008

Participants: Programmers full team participation

- As it turns out, we won’t be able to get any input from the art side. So procedural generation of the game contents.

A task list for the last week has been stated:

- Menu
- Add bitmap graphic for title and credits

- Game
- Generate buildings (10 blocks with textures)
- Complete the 3 puzzles
- Collect points from puzzles and show them at the end.
- Disable sounds during the puzzles.
- Re-design pedestrian waypoints
- Fix the initial state of the directional light.
- Add puzzle destination positions to the mini map.

- Bicycle
- Replace the box with bike mesh
- Limit speed of the vehicle by a constant
- Fix reverse speed constant
- Fix brake torque constant
- The vehicle sometimes keeps going while the player is playing the puzzle.

- Camera
- Fix initial position of the camera

- Misc
- Game design document last changes

VN:F [1.8.8_1072]
Rating: 0.0/10 (0 votes cast)
VN:F [1.8.8_1072]
Rating: 0 (from 0 votes)

Section 1 – Art Team

Team Personnel

1 Character Artist
1 Environment Artist
1 Interface / Cutscene Artist

Section 2 – Executive Summary

2.1 High Concept

Alley Katz is a mentally challenging puzzle/racing game designed to encourage people to keep fit. Players will have to think quickly under pressure and their fitness levels will be challenged during the other parts of the race.
The game is designed for the PC and Microsoft Xbox, both of which already have large consumer bases. The plethora of peripheral devices offered by these systems offer a perfect control system for the game.

2.2 Unique Features

Alley Katz benefits from being the first cycling title that encourages users to set up a bicycle in front of their computer screen. This is left up to the user, a simple method is to raise the rear of the bike making it easy to pedal indoors. A heart monitor is connected to the user, and depending on the game situation, the player must either reduce or increase his heartbeat.
Currently, there are no titles in this niche and the game will likely receive additional attention because of this.

2.3 Visual Style

As Alley Katz is based on real world locations, the visual style should be as realistic as the engine allows.

2.4 Project Scope

As the prototype is based in Dundee, the area shown in figure 1 is the basis of our scene.



From this, the number of distinct locations is listed below:

  • University of Abertay
  • Tay Bridge
  • Castle Street Tourist Office
  • The Phoenix Pub
  • Newsagents
  • Agacan Restaurant
  • Contemporary Arts Cinema Complex

2.5 Target Audience

The target audience for this game is extremely broad and it will appeal to casual players and computer game enthusiasts alike. It will appeal to the millions across the globe who take part in similar races. Everyone has owned a bike at some stage in their life, and our user-generated life-sized bicycle interface will no doubt seem instantly familiar.
People wishing to get fit may also be tempted by this product. The heart monitor rewards the player for increasing their heartbeats, providing a score-based exercise ‘hook’ and making for a fulfilling workout.

2.6 Delivery Platforms

The delivery platform of choice will be any PC with a minimum of 512MB RAM and a 1GHz processor.

Section 3 – Budgets

As Alley Katz is designed to be distributed on a single DVD disk, the 4.3 GB allowed should provide enough space.
In terms of minimum specifications, we can expect most users to have a PC with 512MB RAM and a 1GHz processor. Performance benchmarks should be carried out on machines of this specification during each phase, ensuring that the final polygon count is appropriate.
A number of resolution tests will be performed, and the game should be playable in both windowed and full screen mode. Our extensive studies have shown that the most common windowed resolution for PC games is 800×600 pixels, and especially thorough testing at this resolution will go some way towards ensuring the unhindered execution of the finished product for the greatest number of consumers.

Section 4 – Production Plan

4.1 Animation

The primary animation sequences will involve the character controlled by the player. Background and cutscene animations will also be considered, but are of a lower priority for our prototype.

4.2 Integration into the Game

The majority of the graphics used by Alley Katz will be created in a modelling and animation package. 3D Studio Max 9 and the open-source Blender are currently under consideration. We may have to rely on third-party plugins to export to a model format supported by the game engine that we choose. A small selection of items such as menu buttons may be created as bitmaps and later imported into the game.

Section 5 – Art Bible

5.1 Overview

The art within Alley Katz is designed with our target audience in mind. The final art style should be appealing to this target audience, but at the same time appropriate to the performance requirements of the game. After some deliberation, we decided to go with a realistic look with stylised elements.

5.1.1 Reference Material

We take visual inspiration from the Grand Theft Auto games and Crash Bandicoot (reflecting our realistic but somewhat stylised look), and from the fair city of Dundee.

5.2 Characters

The full game will include a character representing each of the programmers involved in this project.
For the prototype, we require one male and one female character.

5.2.1 Male Character -

The male character is an incredibly athletic 25 year old full time courier. Standing roughly 6ft
tall, with unkempt black hair, crystal blue eyes and full, handsome features. Dressing in casual sportswear, t-shirt and army shorts, he has a variety of piercings and tattoos.

Regular Animation:

Walk Animation (4 directions, idle)
Bicycle Animation (4 directions, idle)
Situation Specific Animations:
Entering Shops
Performing Puzzles

5.2.2 Female Character –

Standing roughly 5ft 6 Siobhan could very well be the poster child for healthy living. Years of physical activity through sport have left her with a lean and toned body. Sporting blond shoulder length hair hitched in a pony tail, and eyes of the purest jade, Siobhan is indeed a pretty young lady. Dressing athletically, Siobhan wears a vest top and hoodie, with hot pants and trainers.
Regular Animation:
Walk Animation (4 directions, idle)
Bicycle Animation (4 directions, idle)
Situation Specific Animations:
Entering Shops
Performing Puzzles

5.3 Environments

5.3.1 University of Abertay

The game begins outside the University of Abertay. A scene shows five riders as they are handed envelopes and we switch to a view of the race countdown. A girl acts as the grand marshal and throws a bra into the air. Once it hits the ground the race begins.

5.3.2 Castle Street Tourist Office – Puzzle 1

The player has to collect a leaflet, “Welcome to Dundee”.

5.3.3 The Phoenix Pub – Puzzle 2

The player has to down a shot of whiskey and collect a stamp from the bar staff.

5.3.4 Newsagents – Puzzle 3

The player has to purchase a Bournville chocolate bar. We expect this shrewd product placement to yield millions in advertising revenue.

5.3.5 Agacan Restaurant – Puzzle 4

The player has to collect a menu from the “Agacan” Restaurant at the Nethergate.

5.3.6 Dundee Contemporary Arts Centre – Puzzle 5

The player has to cycle to the Dundee Contemporary Arts cinema complex and collect 3 used ticket stubs that can be found scattered around the premises, indoors and out.

5.4 Player Bicycles

The user has choice of 7 bicycles; mountain, racer, chopper, uni-cycle, penny farthing, tandem and recumbent. The following figures illustrate them.



Penny Farthing






Tandem Bicycle


Recumbent Bicycle


Mountain Bicycle


Section 6 – Asset List

6.1 Characters

6.1.1 Male Character (Animations)

  • Walk Animation (4 directions, idle, jump)
  • Bicycle Animation (4 directions, idle, jump)
  • Crash Animation

6.1.2 Female Character (Animations)

  • Walk Animation (4 directions, idle, jump)
  • Bicycle Animation (4 directions, idle, jump)
  • Crash Animation

6.2 Backgrounds

  • Buildings
  • Night time Sky
  • Day time Sky

6.3 Environmental Objects

  • Cars
  • Buses
  • Street Lights
  • Bus Stops
  • Trees
  • Street Signs
  • Trucks
  • Pedestrian crossings

6.4 User Interface

  • Title Screen x3
  • Menu item hover effect
  • Dundee map
  • Puzzle Completed Meter
  • Health Meter
  • Menu System
  • Mouse pointer graphic

6.5 Sound

6.5.1 Ambient

  • Rain
  • Wind
  • Sea

6.5.2 Music

  • Intro Scene
  • Puzzle Completed
  • Ending Scene

6.5.3 Sound Effects

  • Walking on grass
  • Walking on sand
  • Walking on the street
  • Car Engines
  • Truck Engines
  • Bus Engines
  • Opening Door of Puzzle 1
  • Opening Door of Puzzle 2
  • Opening Door of Puzzle 3
  • Opening Door of Puzzle 4
  • Opening Door of Puzzle 5
  • Map Rustle
  • Sea
  • Crash
  • Drinking shot
  • Birds chirping

Section 7 – Schedule

7.1 Week 2

Basic concept art is completed for characters and locations.

7.2 Week 4

Artists should constantly check off their work, making sure deliverables are acceptable.
Final character and environments designs should be decided upon.
Construction of characters should begin.
Dummy environment creation for the programmers to work on.
Construction of full environments begins.
Interface artist begins work on GUI concept art.

7.3 Week 6

All interface art required complete by the end of Week 6.
Art team should work closely with programmers to produce required graphics.

7.4 Week 8

Character art should be nearing a completed stage, artists will continue towards this goal.
Environment Artist should ready Environment art for collision programming.

7.5 Week 10

Character art should be near completion, the artist should work towards this end.
Likewise, environment art should be all but complete; artist should have t ready by the end of Week 10.

7.6 Week 13

All art should be completed by the end of Week 13, and much should be implemented.
Art team should work with programmers, correcting any problems/ oversights in Pre-production.

The .pdf version of this report can be found here.

VN:F [1.8.8_1072]
Rating: 0.0/10 (0 votes cast)
VN:F [1.8.8_1072]
Rating: 0 (from 0 votes)

Technical Team

Technical team consists of 5 programmers, students of MSc Computer Games Technology programme at University of Abertay:

  • Gordon INGRAM (MSc CGT)
  • Gorkem PACACI (MSc CGT)
  • Kenneth ROSS (MSc CGT)
  • Rushikesh TAMBE (MSc CGT)
  • Sameer KUMAR (MSc CGT)

Support team consists of 2 manager candidates, students of BSc Games Production Management programme at University of Abertay; and a MSc Computer Arts student:

  • Euan MCLAREN (BSc GPM)
  • Alasdair CREWS (BSc GPM)
  • Andrew ROBINSON (MSc CA)

Executive Summary

Project overview

High concept

Alley Katz is a puzzle racing game designed to encourage people to keep fit while playing computer games and be mentally challenging. Players will utilise their quick thinking ability whilst under pressure and their fitness levels will be challenged during the other parts of the race.
The game is designed for the PC and all home console systems, which already has a large consumer base. The peripheral devices offered by these systems offer a perfect control system for the game.

Unique features

Alley Katz benefits from being the first cycling title that encourages users to set up a bicycle in front of their computer screen. This is left up to the user, a simple method is to raise the rear of the bike making it easy to pedal indoors. A heart monitor is connected to the user, and depending on the game situation, the player must either reduce or increase his heartbeat.
Currently, there are no titles in this niche and the game will likely receive additional attention because of this.

Genre and scope

Alley Katz is an interactive racing game which includes puzzle elements. The title is fun based and is developed with the intention of selling to individuals online. An international distributor is required to cover all shops sales.
The game will consist of 30 levels encompassing several different types of gameplay such as stunt cycling, time trials, and numerous puzzles. The game prototype will be delivered covering a single level.


A prototype of the game will be developed using the Ogre3D Engine. Ageia PhysX will be integrated offering all the physics required for such a title. The prototype will include a single level of the game – the Alley Katz race.

Delivery Platform

Delivery platform the released game is PC/DVD due to necessary space to deploy art content of the game.

Minimum System Requirements

The game will carry the following system requirements:

  • Operating systems: Windows Server 2003, XP, Vista, MacOS X
  • Main memory: 256MB RAM
  • Graphics memory: 64MB

Recommended System Requirements

As with any software, Alley Katz will benefit from any sort of processor or RAM boost above the minimum. Ideally a user will have at least 512MB RAM. Under Windows a 1GHz or faster processor will be beneficial and Macintosh users will see best performance when using a PowerPC G5 or Intel Core Duo or Core 2 Duo based machine.

Disk Budget

It is intended that Alley Katz will ship on DVD allowing a size of 4.7 GB.
If the software is to be digitally distributed, users may download episodic content or the entire version could be downloaded in a few hours with today’s broadband speeds.

Engine Evaluations

Instinct Studio (Rejected)


Instinct Studio is a cross platform game development solution featuring high-performance graphics coupled with powerful game creation tools, allowing a wide variety of game genres to be developed. These tools support WYSIWYG editing within a single unified working environment, maximizing productivity by reducing iteration times. The software has been designed as a true middleware API utilizing a set of extensible frameworks.


  • Since the Instinct studio is a complete product for game development, it has supporting tools for each aspect of game development.
  • It has integrated physics engine support, audio integration support, and extensions for scriptable game content.


Since the purpose of the Instinct studio is being a complete solution for game development, it misses some points in detail. At some points, you need to do heavy work, for example when you want to control the rendering process in detail.
In such a case, you have to write a plugin, an extension to Instinct studio to perform necessary tasks. So the implementation and maintenance costs of such extension projects are discussable to be worth.



OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D engine written in C++ and designed to make it easier and more intuitive for developers to produce applications utilising hardware-accelerated 3D graphics. The class library abstracts all the details of using the underlying system libraries like Direct3D and OpenGL and provides an interface based on world objects and other intuitive classes.


  • Full and equal support for both OpenGL and Direct3D
  • Full support for Windows, Linux, and Mac OS X platforms
  • Simple and extensible object framework, easily integrated into an existing application
  • Powerful and sophisticated material management and scripting system, allowing maintenance of materials and fallback techniques
  • Support for a wide variety of image and texture formats including PNG, TGA, DDS, TIF, GIF, JPG.
  • Full support for render-to-texture techniques and projective texturing (decals)
  • Official and community support and development of exporters from all major commercial and open source 3D modeling packages to the Ogre mesh and animation format
  • Plug in–based hierarchical scene structure interface, allowing you to use the scene graph that best suits your application (basic octree scene manager included as an example plug-in)
  • Full support for easy-to-use skyboxes, skyplanes, and skydomes
  • Unique queue-based rendering management allowing full control over the order of the rendering process
  • Sophisticated and extensible resource management and loading system with included support for file system, ZIP, and PK3 archive types

This list only touches on the capabilities incorporated into this rendering engine, but it should serve to demonstrate the breadth and depth of the power of the Ogre 3D engine.

Usability, learning curve and support

Ogre has been designed to be developer friendly, with ease-of-use, flexibility/customisation and rapid development being at the forefront of its design. Ogre has been designed primarily with hobbyist and amateur developers in mind, and therefore has a relatively straightforward user-interface; with more advanced customisation features available for more experienced developers. However, the interface still requires some training, with initial familiarisation taking roughly 3-4 hours (in the form of tutorials), and advanced features longer (through documentation).
Additionally, the engine is currently well supported, due to a very large, self-sustaining development community producing a wide range of tutorials, assets, interface templates, how-to guides, games, design challenges/contests and more.
One particular strength, is the large scale availability of source code which covers some of the more popular features.


The game engine has been in continuous development for some six years, and therefore is already very robust and feature rich.
The main strengths, as previously discussed, are drawn from the simplicity and flexibility of the SDK. But Because of the abstraction over DirectX and OpenGL features, in some cases it becomes harder to achieve a deeper contact with the graphics card, and the low-level rendering pipeline.
Another disadvantage of using Ogre3D may be that you need to use accompanying technologies to get the best rapid development efficiency out of Ogre3D. For example, OgreAL and NxOgre are Ogre-style wrappers for sound library OpenAL and physics library Aegia PhysX, respectively. If you go out of the trend and use exceptional libraries for these purposes, you have to implement the integration to Ogre yourself, which is not a rapid development model anymore.
While it has its limitations, Ogre is a robust and well supported game engine, supporting many of the features desired for Alley Katz. In particular, its flexibility and integrated development environment make it stand out as an ideal engine for developing a prototype puzzle racing game.

Development plan

Artistic content


Alley Katz’s music will be sourced from outside the Geekers development studio and will likely come from a stock music provider. The game will also include a selection of ambient sounds that are recorded by the team’s Audio Technician.
Sound effects will also be recorded in-house by the audio engineer.


Cutscenes will be produced in-house and will be rendered in game. The prototype will not contain such scenes.

Development environment

As a programming language, C++ will be used because it gives the best integration performance with the Ogre3D engine.
Compiler is the MSVC 7.1, provided with Microsoft Visual Studio 2005 / Service Pack 1.

Object oriented design


Ogre3D framework, has a design trend which forms the complete library very strictly. This causes the developers and architects working on Ogre framework to have a narrow design domain.
In the design of the AlleyKatz, there are classes which follows Ogre’s design approach.

Scenes and Lifecycles

Scenes and Lifecycles

Class GeekersFrameListener

Ogre requires a subclass of Ogre::FrameListener to occupy a step in the rendering lifecycle.
GeekersFrameListener is a subclass of Ogre::FrameListener, and implements necessary functionality to perform necessary operations for rendering of a single frame.

Class GeekersGameScene

GeekersGameScene is a base class for every class which represents a game scene, or a puzzle scene in the game. It defines abstract methods, and makes use of template method design pattern to allow flexible functionality in the subclasses.
SetupScene and DestroyScene methods are called by the GeekersApplication class. When a puzzle is disclosed, Freeze method of the GameScene is called, which causes it to temprorarily pause it’s all rendering functions. The rendering gets back alive only when the Recover method is called.

Class GeekersRidingScene

Class GeekersRidingScene is a subclass of GeekersGameScene. It manages the main bike-riding scene, creation of the environment, destination points, the pedestrians walking around.
An algorithm to generate random-height buildings is implemented within the scope of RidingScene. Algorithm consists of _createCityBlock(…), _createBuilding(…), and _createCity(…) methods. These methods are all private, and they’re called by SetupScene() method.
GeekersRidingScene also contains implementation of the mini-map, on the HUD(Heads-up display). The circular birds-eye view of the game environment is updated for each frame. Positions of the objects in the environment, and the blips of destination points are continuously synchronized with the game model.

Class GeekersVehicleDestination

The purpose of GeekersVehicleDestination class is, hiding the functionality of a trigger inside a specific class. Which can be checked to fail or succeed by CheckRange() method. In each frame, GeekersRidingScene checks states of each vehicle destination, and takes action accordingly, like disclosing a puzzle.
GeekersRidingScene also considers the necessary order of visiting of the vehicle destinations. For example, if the vehicle goes to the final destination before player solves two existing puzzles, nothing happens. The player also has to visit snake puzzle first, and then the picross puzzle.

Class GeekersSnakeScene

GeekersSnakeScene is a subclass of GeekersPuzzleScene, and implements necessary functionality to create, render the snake puzzle. It is created by GeekersSceneFactory, and called for operation by one of the GeekersVehicleDestination objects in the GeekersRidingScene. The total points of the user for the snake puzzle, are collected by the GeekersApplication through the GetPoints() method of SnakeScene.

Class GeekersPicrossPuzzleScene

PicrossPuzzleScene is a subclass of GeekersPuzzleScene, and implements functionality for rendering and gameplay of the Picross puzzle. The picross puzzle templates are loaded from txt files, stored in the picross folder in within the game’s root folder. The class itself calls LoadPuzzleFromFile(…) method during the Setup process, to load the appropriate file.
PicrossGrid represents the grid, and implements game logic behind the picross puzzle. PicrossPuzzleScene calls appropriate methods of the PicrossGrid to manage gameplay.

Entities and Interaction

Entities and Interaction

Class EntityBase

EntityBase is a base class for all the entities that exists in the physics environment, and gets rendered onto the screen. It encapsulates a nxogre body object as private, and GetBody() public method can return a pointer to that object, in case.
SetupOnScene metod is a stub for subclasses to implement the initialization steps for the entity. It may consist of loading of resources, initializing variables, etc.

Class GeekersVehicle

GeekersVehicle is a subclass of EntityBase, and it represents the bike in the GeekersRidingScene. It encapsulates Aegia PhysX objects wheel, wheelset, motor and engine. It provides access to bike functionality through methods TurnLeft(), TurnRight(), StraightAhead(). Class GeekersRidingScene calls methods of this class to integrate it into the gameplay.

Class Pedestrian

Pedestrian is a subclass of EntityBase, and provides functionality for animated people wandering within the game environments.

Class GeekersPlayer

Class GeekersPlayer is not a subclass of EntityBase like Vehicle or Pedestrian, because it’s not rendered onto the screen. It is the modeling of player’s state during the game. It provides methods like IncreaseEnergy() or DecreaseEnergy(), to be called by the RidingScene when appropriate. For example, IncreaseEnergy() method is called on each frame, with a units parameter. But the DecreaseEnergy() method is called only while the ‘accelerate’ button is pressed.

Application Scope ClassApplication Scope

GeekersApplication class is the class which puts all the functionality together, and it also is the first to appear in the lifecycle.
At any time, a gamescene or a trigger in the game scope can call SetGameScene(…) method, or DisclosePuzzle(…) method of the application. When SetGameState() is called, the current game scene gets destroyed by DestroyScene() method, and the new scene’s SetupScene() method
When the DisclosePuzzle(puzzletype) method is called, application calls Freeze() method on the current game scene and calls Setup() method of the puzzle.
When the player is done with the puzzle, the interaction system calls RecoverFromPuzzle() method of the application, which causes the Puzzle to be destroyed, and the actual game scene to be recovered to its normal state.


WinMain function in the Win32 application, calls GeekersApplication’s Instance method, which is a static method that returns a pointer to the only existing instance of the GeekersApplication class.
The Singleton design pattern is used at this point, because during the application’s lifetime, there’s no point to create another GeekersApplication instance. And the dependent objects like scene managers, can reach this only instance through the static method Instance(). This is a good way of accessing single-instance objects, because you don’t have to keep references to the application class in each asset in the game.

The Initialize Method

This method is called before the Go() method, to perform the necessary initialization steps for Ogre3D, Aegia PhysX, NxOgre and OgreAL. Calls private methods _initRenderWindow(), _initInputSystem() and _addResourceLocations(). It also throws appropriate exceptions of type GeekersException with messages of the exceptions happened.

The Go Method

The go method requires Initialize() method to be called before it. It simply checks if the initialization stage has passed, and triggers rendering loop of the ogre system.

Puzzle Activation Sequences

Activation of a puzzle

In the figure below, you can see how the disclosure of the puzzles are handled by the game model. GameScene calls DisclosePuzzle of the Application when it’s triggered. And Application calls SetupPuzzle method of the puzzle object, and Freeze() method of the GameScene. From this moment on, OgreRoot just recognizes the puzzle as a FrameListener.

Activation of Puzzle Overview

Deactivation of a Puzzle

In the figure below, you can see the process of deactivation of a puzzle. Since the Ogre is calling FrameStarted method of the puzzle, it can decide when to end its existance. When it calls RecoverFromPuzzle() method of the application, application first collects points from the existing puzzle. After it ensures it’s done with the puzzle, it calls Destroy method of the puzzle. Then it calls Recover() method of the GameScene, which will set it into Ogre rendering loop again, with appropriate framelisteners.

Recover From Puzzle Function

Quality Assurance

Version Control

Subversion (SVN) version control system is used for version control. The features of subversion are:

  • Keeps a history of each document (source code or content)
  • Lets the members of the team work on the same source files at the same moment, merging their work together.
  • Prevents data loss by managing conflicts.
  • Reachable over internet.

The Subversion service will be sued from assembla.com, a collective web project host for software projects.

Coding Conventions

For clarity, the following standards will apply:

  • All variables must be clearly labelled with descriptive names.
  • Private data members have an underscore ( _ ) at the beginning of their names.
  • Pointers have a “p” char at the beginning of their names
  • Public methods of the classes starts with a capital letter, continues with lover case, and gets a capital letter at the beginning of each separate word. Acronyms have all their letters capitalized. Example: SetupScene SetupOnScene DisplayHUD
  • Namespaces are named like public methods of classes. They begin with a capital letter, and have a capital letter at the beginning of each separate word.
  • A general understanding of the benefits of whitespace and indentation will be expected of all programmers.

Test Methodology

Feature Tests

Feature tests will be performed on the game, by guest players. They’ll be provided with the initial game design requirements and they’ll be expected to write down which features are fulfilled.

Unit Tests

Unit tests will be written for extended classes in the framework. Tests will be run by the Team System version of Microsoft Visual Studio.
Unit tests provide a stable flow of code integration, and regression tests are automatically performed by this method.

The complete report can be found here.

VN:F [1.8.8_1072]
Rating: 0.0/10 (0 votes cast)
VN:F [1.8.8_1072]
Rating: 0 (from 0 votes)