gw official tdd

8/9/2019 GW Official TDD

http://slidepdf.com/reader/full/gw-official-tdd 1/15

0



Contents

Introduction..........................................................................................................................2Technical Overview.............................................................................................................2

Target System Requirements...........................................................................................2

Tools.................................................................................................................................3Engines & iddleware....................................................................................................3

!ile !ormats....................................................................................................................."

Technical !eatures...............................................................................................................#$ustom %ame Tye.........................................................................................................#

Rune System....................................................................................................................#

Imlementation ' ( )ase the rune class on *ic+u class............................................#

Imlementation ) ( )ase the rune class o,, $T! !lag................................................-Imlementation $ ( )ase the rune $lass on the )oming Run )all...........................-

Imlementation / ( )ase the rune class on 'ctor.......................................................-

!inal /ecision ( Imlementation '.............................................................................

'ltar System....................................................................................................................Imlementation............................................................................................................

Troll & /war, *awns.......................................................................................................Imlementation............................................................................................................

/raught o, 1i,e................................................................................................................

Imlementation '........................................................................................................Imlementation )........................................................................................................

%ods.................................................................................................................................

Imlementation ' ( $ustom *awn $lass ,or the %ods re,erred4.............................5

Imlementation ) ( Stationary O6ect as %ods ac+u4...........................................57eaons...........................................................................................................................5

6olnir8s Echo.............................................................................................................5

Tears o, !reya............................................................................................................90Tyr:s $annon..............................................................................................................90

$ustom 1evels...............................................................................................................90

;</...............................................................................................................................99Imlementation..........................................................................................................99

$ustom enu and %<I..................................................................................................99

/eveloment *lan..............................................................................................................99

ilestones......................................................................................................................99%// and T// comlete...........................................................................................99

'sset 1ist and /eveloment *lan $omlete.............................................................99

*rototye....................................................................................................................92'lha..........................................................................................................................92

)eta............................................................................................................................92

%old...........................................................................................................................92So,tware 'rchitecture........................................................................................................92

/irectory Structure........................................................................................................92

)uild *rocess.................................................................................................................93

$oding Standards...........................................................................................................93

9



2



IntroductionGreat Winter is a multiplayer, team-based game modification (mod) for Epic’s Unreal Tournament

2004. Two teams representing rival factions in Norse mythology struggle to gain control over

power-ups and destroy each other’s god. The game style of Great Winter resembles nslaught

more than any other e!isting game style pac"aged with Unreal Tournament 2004. #n Great

Winter , the team power cores are replaced by their respective gods, and the power nodes are

replaced by altars upon which team-based runes may be placed. $hen a player carries a rune to

an altar, the altar powers up in the same way as an nslaught power node% however, unli"e a

power node it grants the controlling team a special ability such as increased damage or speed.

The concept of lin"s between the nodes and cores is not relevant in Great Winter . Each team

starts the game with their own fives runes, and the levels will have a minimum of three altars.

Technical Overview

Target System Requirements

Great Winter, li"e most Unreal Tournament 2004 game mods, will be developed for &'

distributions of the game. Epic lists the following system reuirements on the retail bo!

Operating System: $indows *+ e /// 0&Processor: &entium ### 1./ 234 or 56 5thlon 1./ 234 or faster (1. 234 or

faster recommended)Memory: 1+ 7 85 minimum

(9: 7 85 recommended)Hard Disk Space: 9.9 27 free spaceCD!OM Drive +0 ;peed"ideo: < 7 $indows *+e///0&-compatible video card (:= 7

N>#6#5 2e?orce or 5T# 8adeon 3ardware T@A card recommended)Sound: $indows *+e///0&-compatible sound card (6olby 6igital

#nteractive 'ontent Encoder reuired for 6olby 6igital audio. ;ound

7laster 5udigy B; card recommended.)Direct#: 6irect0 version *./b (included) or higher Internet Connection: <<.: Cbps modem for A5N#nternet play (7roadband #nternet

connection recommended)

3



Tools

5ll members of the development staff will have access to development computer with standard

office programs such as icrosoft $ord and E!cel. #n addition, all members will have access to

the basic tools that accompany Unreal Tournament 2004.

$sers Tool $se Cost

5rt A6 ;6 $or"station and base

software

6ell 0&; 2en

laptop with icrosoft

office

D=///

5rt A6 ;6 Epic’s Unreal

Tournament //=

8etail version of the

game

D=/

5rt A6 ;6 Unreal Ed Aevel Editor, &ac"age

Editor

#ncluded with game

5rt A6 ;6 7ug4illa ;erver-based bug

trac"ing

?ree

5rt A6 ;6 ;ource ;afe ;ource 'ontrol D:/ 5rt A6 5utodes"’s <6; a!

'haracter meshes

and animation and

static meshes

D<9//

5rt 5ctor 0 E!porter E!port to Unreal

formats

?ree

5rt A6s 5dobe’s &hotoshop

';

Te!tures and other 6

art

D:9/

5rt $acom #ntuos< Tablet

(: ! +)

#nput device for

drawing

D<</

;6 Unreal 6evelopment

Environment <./

;cript editing ?ree

Engines & Middleware

;ince Great Winter is a mod for an e!isting game, the actual game engine source code will not be

needed nor will a third-party middleware solution be needed. The code will be written using the

Unreal Script language and compiled with the tools that accompany the retail version of the

game.

File Formats

The following table lists the file formats used in the development of Great Winter

"



5nimation .ps" <ds s"eletal animation.psa <ds mesh animation

5udio .ua! Unreal audioaps .ut Unreal mapusic .ogg gg >orbis compressed

audio

;tatic eshes .us! Unreal static mesh.<ds <ds mesh

;cripts .uc Unreal ;cript class;ystem .u Unreal class pac"age

.int Unreal pac"age resource and

locali4ation.ucl Unreal pac"age interface.ini Unreal configuration file.bat ;ystem batch file

Te!tures .ut! Unreal te!ture pac"age.tga Targa te!ture.bmp 7itmap te!ture

#



Technical %eatures

Note: reading the Game Design Document before reading this document is essential.

Custom Game Type

The first thing needed is the new game type. ;ince the game wor"s almost li"e Unreal ’s

nslaught game e!cept the Nodes don’t lin" together, and the cores are replaced by gods. The

most logical implementation is to base our new game code off nslaught game class.

5dditionally, there are also the rune system, which need to be implemented and integrate into the

rest of the nslaught game code.

Rune System

The rune system is essentially a different "ind of pic"up. The rune system may be implemented

by basing off one of the following Unreal ’s systems &ic"up, 'T? ?lag, 7ombing 8un 7all, or

straight from 5ctor.

Implementation & ' (ase the rune class on Pickup classThe main benefit of modifying Unreal ’s pic"up into our rune is the presence of Unreal ’s inventory

system. $hen a pawn pic"s up an item, the item can either be placed in the pawn’s #nventory or

destroyed. This is very close to desired behavior, e!cept that the runes are never destroyed, but

set to different states. The runes can be held, at base, dropped or placed on an altar, and only

one rune can be pic"ed up at any time. 'onsidering the abilities of Unreal script, creating and

setting the states of the runes should not be difficult at all.

5nother mechanism needed for the runes to be implemented is the runes’ effects on the team

when a rune is placed on the 5ltar (discussed later). The effects include more speed, more

damage, more armor, regeneration and god’s shield. This mechanism is something that needs to

be implemented from scratch.

Benefit: &ic"ing up and dropping pic"ups is already available. runes are logically pic"ups.

-



%inal Decision ' Implementation &

?irst of all, it seemed to be most logical to base our rune class on Unreal ’s &ic"up class.

5dditionally, the wor" load involved in the implementing the rune’s states is less than that reuired

to modify a 'T? flag or a 7ombing 8un ball. Unreal ’s pic"up class also gives us a lot of fle!ibility

where we need it, while 5ctor gives us too much fle!ibility, which could result in additional code.

Resources: -< programmers, 1/ different rune models, rune base.

Altar System

The altar system is already very similar to Unreal ’s nslaught node system. 7asing the altar on

nslaught’s node class is the most logical and most li"ely the easiest implementation.

Implementation

$e will try to "eep as much as possible of the original nslaught node code and try to build other

classes around it. The Node already has all of the functionality that we need, including the

relation to the Ain" 2un, which we will later modify to be one of our weapons. 5ll we need is to do

is ta"e away the lin"ing mechanism of the node, and the altar is pretty much ready.

Resources: 1 programmer, 1 altar model.

Troll & Dwarf Pawns

7esides their appearance, Trolls and 6warves are the same. oreover, they function in a very

similar manner to an unreal pawn. 3ence, we only need to implement their appearance and

animation.

Implementation

'reating a new character is very straight forward using Unreal . The most difficult part would be

custom animation since the character animation and weapon animation has to match, which may

be difficult. oreover, both Trolls and 6warves loo" very different, thus they will have different

animation sets as well.

5side from the animation, the character selection screen may need some modification as well.



Resources: programmers, < artists, character models.

Draugt of !ifeThe 6raught of Aife (6A) is essentially health pic"up that is dropped by a pawn, where the

amount of health is varied depending on the number of "ills the "iller has. The most logical

implementation would be to base the 6A from Gnreal’s 3ealth&ic"up class, or base it straight off

&ic"up li"e the 8unes.

Implementation & ' (ase o)) HealthPickup +pre)erred,

;ince Unreal’s pawn does not drop health pic"up by default, the first thing that needs to be done

is to try to spawn health pic"up whenever a pawn dies. The ne!t step would be to ma"e the

amount of health varies depending on the person who "illed the pawn.

Risk: 8is" here is uite minimal, the system seemed easy enough to implement with Gnreal

;cript. The only tric"y part is probably to get the number of "ills to determine the amount of

health.

Implementation ( ' (ase o)) Pickup +*ackup,

This implementation is a bac"up plan for if by any reason, Gnreal’s 3ealth&ic"up class does not

allow us to do what we wanted. This way we can ma"e our own pic"up that match our

specification, but will probably ta"e more time.

Resources: 1 programmer, 1 artist, 1 pic"up model.

Gods

The two gods, Ao"i and din, function the same, but there is nothing li"e them in the Unreal ’s

universe, which could ma"e the gods the most problematic part to implement. The most logical

implementation would be to base the gods’ class on Unreal ’s pawn class with custom 5# and a

custom way point. 5nother plan, which should be easier, is to ma"e the god a stationary obFect

that attac"s at random intervals, but this way we could not move the god as in original

specification.

5



Implementation & ' Custom Pawn Class )or the -ods +pre)erred,

This is the preferred way. $e need to implement the following ma"e the god bigger, add custom

5#, a custom weapon, and a custom way point. The main game class also needs to "now about

the gods because when one of the gods is destroyed, the game will end. oreover, the spawn

points of both gods need to be place-able from Unreal Editor.

5dditionally, the gods also need their own models and animations, which may be more

problematic than those for the Trolls, and 6warves because of their massive si4e.

Risks: 5lthough the gods are essentially customi4ed 7ots, they behave very differently. There are

a lot of things that can go wrong for the gods, especially with their 5#. Unreal pawns can have

very comple! 5#, most of which is not suitable for the gods. ?inally, the si4e of the gods could

introduce some problems as well.

Implementation ( ' Stationary O*.ect as -ods +*ackup,

This is an easier way to implement the gods, but the gods will not move. 5ll we need here is to

base the god class on any stationary, destructible obFect% a turret would be a logical choice.

Resources: programmers, artists, god models.

"eapons

There are three custom weapons Folnir’s Echo, a hammer which functions similar to Unreal ’s

lin" gun, Tears of ?reya, a crossbow which function similar to Unreal ’s sniper rifle, and TyrHs

'annon, a steam-thrower which functions similarly to Unreal ’s fla" cannon.

M.olnir/s 0cho

This is the most important weapon in the game because it’s the only weapon that can damage

the gods, and heal 5ltars. ?ortunately, the functionality of the Ain" 2un matches our specification

(heals nodes, and ma"e nodes charge faster). $ith all that wor"s cut out, we Fust need to change

the appearance of the lin" beam into something more li"e lightning, ideally something similar to

the lightning gun.

90



The secondary area of effect attac" is something that Unreal does not have, but that can be

easily implemented. #n Unreal , the &roFectile class has hurt radius functionality already

implemented for use with weapons li"e the roc"et launcher. $e could use the same functionality

for our area of effect attac".

Tears o) %reya

This is a sniping type weapon, which ma"e it very simple to create. There is really nothing special

about this weapon regarding implementation. 5ll we need are custom meshes for proFectiles and

the crossbow itself.

The secondary attac" is very simple as well% the only maFor different is the e!plosive proFectile,

which is really simple to implement.

The tric"y part is how the weapon gets its ammo% the ammo can only be collected at a special

charging station. ?ortunately, the charging station can Fust be an ammo pic"up and does not

disappear.

Tyr1s Cannon

This is an e!tremely close range weapon. #t is very much li"e a flame thrower, but produces

steam instead. 'reating the visual for the steam could be tric"y, but hopefully, not very difficult.

Unreal ’s fla" cannon fires a number of proFectiles at once. $e can probably use the same attac"

and change the mesh into smo"e particles. The only concern is that each steam particles has to

get larger as it travels further then slowly disappear.

Resources: programmers, 1 artist, < gun meshes and proFectiles

Custom !e#els

The levels need to be customi4ed to suite the new gameplay. ?ortunately, with Unreal Editor, it isvery simple to enable the level designers to place the runes, altars and gods in levels.

Resources: = level designers, < custom levels

99



$%D

Great Winter has its own uniue 3G6 with a mini map similar to the one in nslaught. The only

concern here is modifying the nslaught map to meet our reuirements.

Implementation

The 3G6 is nothing special, since the hardest part, the mini-map, is already done for us by the

nslaught 3G6. The only things left for us to implement are custom graphics and the states of

each rune. The player needs to "now what state each rune is in% whether it is held, dropped, on

altar, or at a base.

Resources: 1 programmer, 1 artist.

Custom Menu and G%

There are a lot of 2G# elements in Unreal Tournament //=, replacing them all would ta"e too

much time. Thus, only the main menu and loading screen will be customi4ed. #f time allows, more

2G# elements may be customi4ed.

Resources: 1 programmer, 1 artist

Development Plan

Milestones

-DD and TDD complete

7oth documents are complete. The T66 contains coding practices and at least a general outline

of how to implement the gameplay elements described in the 266 in addition to coding practices,

tools, and ris" analysis. ;ource control and bug trac"ing methods (>isual ;ource;afe and7ug4illa) have been proposed.

&sset 2ist and Development Plan Complete

5n asset list with all assets and completion dates has been created. ;ource control and bug

trac"ing solutions have been implemented.

92



Prototype

The code for FolnirHs Echo is complete and the weapon’s static mesh and animation have been

added. The rune system and god bots have been implemented, but may have place-holder art or

animation (most li"ely from UT2004). 5ll runes (five) are implemented. The gods spawn correctly

and "illing the opposing team’s god results in a victory. The gods use their area of effect attac"

on the opposing team. 5 preliminary 3G6 has been implemented which also may contain place-

holder art. 5n installer un-installer has been created.

&lpha

FolnirHs Echo is bug free. The behavior of TyrHs 'annon and Tears of ?reya has been coded and

their static meshes and animations have been implemented and added to the game. The steam

charger has been implemented and its static mesh has been added to the game. The final 2G#

and 3G6 have been implemented, including all art assets. The gods behave correctly under all

circumstances. The mod is installable un-installable on all test platforms.

(eta

The mod wor"s correctly at internet speeds. 5ny bugs since alpha are suashed.

-old

?inal gameplay balancing has ta"en place. The game is totally compliant with the T66 and 266.

The T66 and 266 have been updated if necessary. 5ll bugs have been fi!ed. ?ive '6’s with

the final game have been burned.

So)tware &rchitecture

Dire'tory Stru'ture

5ll art, level, and code assets will be placed under one subdirectory called I2$od’ that lies

under the IGT//=’ base directory. 5ssets will not be located across the default directories. This

method "eeps data organi4ed and simplifies installation and un-installation. The list below shows

the directory structure

• GT//=

o 2$od

93



5nimations J mesh and s"eletal animations

'lasses J Unreal Script code

3elp J custom splash logo

aps J level files

;tatic eshes J e!ported mesh pac"ages

;ystem J 2ame pac"age files, custom initiali4ation files and batch build

e!ecutable

Te!tures J custom te!ture pac"ages

IGTC=od.ini’ J custom mod initiali4ation file

(uild Pro'ess

The mod will built using the 2$'ompile.bat script in the system directory. This script willautomate the process of compiling the mod and generating the .int and .ucl files.

Coding Standards

1. 5ll of the Unreal Script classes developed by the software team will start with I2$’. ?or

e!ample, 2$rune.uc will be used.

. &roper indentation will be used for braces. 7eginning and ending braces will be placed

on their own lines. #ndents will be standard tab si4e within the editor, G6E.

<. >ariable names will have their first word letters capitali4ed li"e Irune&ic"up’.

=. 5 general effort will be made to "eep the code as readable as possible using helpful

comments.

9"

gw official tdd

Documents