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.

Engine

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)

Description

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.

Pros

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

Cons

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.

Ogre3D

Description

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.

Pros

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

Cons

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

Audio

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

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

Overview

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.

Use

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)

Related posts:

  1. Alley Katz – Game Design Document
  2. Alley Katz Overview
  3. Alley Katz – Meeting Minutes
  4. Alley Katz – Art Production Plan

Leave a Reply

(required)

(required)