Design Document

DADIU
1
M AY PRO DUCTI O N 2010
TE A M 5
table of Contents
concept document
1
Design Treatment
2
Game Mechanics
Level Design
Interface
2
4
5
art document
6
Look and Feel
Style
Machine Design
Character Design
Enemy Boss
Environment Art
Interface Design
6
11
12
14
16
17
20
Sound Design
20
Music
20
Technical Design Document
23
Internal Standards
Game implementation analysis
23
24
Production document
26
Project Management with Scrum
Production Plan and Time Estimations
Milestones and Deadlines Risk and Consequence Analysis
Test Plan
Asset Pipeline Analysis
26
26
29
31
33
34
concept document
Our game concept deals with children’s obsession with construction vehicles and the idea that when you
go down through Earth you will eventually reach China.
You control the builder Wang Bob in his home-built vehicle of destruction as he explores a hole in a sand
box.
The hole turns out to be an entry to the core of the Earth, and Wang must battle against exciting and
funny monsters in order to make his way to the other side.
You build your own unique vehicle by assembling different parts. The parts are a mix of constructionvehicle parts and weapons such as shovel, crane, laser gun, chain saw etc.
Destroy the crazy bosses and their castles or have a laugh as your homemade vehicle totally fails to do so.
Target: 6-7 years of age
The main audience is young kids who love construction vehicles (and parents who also find them interesting). But the game also has a playful side to it and some gamers would undoubtedly find it amusing to
build crazy and stupid vehicles just to see them in action, so the game also has an appeal to everyone who
likes to build things and play with it.
Similar games/inspiration:
• Nørd spillet on dr.dk
• Robot Wars (a series on Discovery channel)
• Banjo Kazooie nuts and bolts
1
Design Treatment
Game Mechanics
Imachination has two layers: a Workshop layer where the player constructs their own exaggerated construction vehicle, and a World layer where the vehicle is put to the test against destructive minions and
menacing bosses.
Workshop Layer
The Workshop layer shows a base unit for a construction vehicle on a dais against a 2D background
depicting a workshop. The base unit will be a torso with 9 sockets for tool and weapon attachments (2
sockets on each side and the front, 1 on the back, and 2 on the top). At the top is a list of components for
the player to drag and drop onto the sockets on the base unit. When the player is ready to play, a ”Ready!”
/ ”Parat!” button will move the Machine into the World layer (see below).
Controls
The workshop layer is entirely drag and drop based. You click and hold with the left mouse button (LMB)
on a component from the list, drag it over a socket, and then release to attach it to the base unit. The list
only has one instance of each component, but components are never depleted.
Dragging a component off the Machine destroys it, freeing up the socket. Dragging a component onto
a socket that already has another attachment mounted will destroy the old attachment, replacing it with
the new component.
The player can rotate the base unit by clicking the dais and holding down LMB while moving the
mouse left or right, exposing new sockets.
Components
The initial aim is to implement five different components, and then we’ll see if we have time to add more.
The player starts with 3 available components, and the last two are dropped by certain bosses.
•
•
•
•
•
Shovel – melee, 60 damage every 3 seconds
Bucket-wheel excavator (dropped by boss) – melee, 5 damage every 0.5 seconds
Flamethrower – melee, 5 damage every 0.5 seconds + 2 DOT every 0.5 seconds
Laser – long-range, 60 damage every 3 seconds
TNT launcher (dropped by boss) – long-range, splash, 100 damage every 5 seconds
The splash range of the TNT impacts will be determined after playtesting.
World Layer
The World layer shows the Machine in the current level, in a pseudo-isometric slanted top-down perspective. The camera starts zoomed out, such that the player can see the entire level and an outline of the lower
one, and then it zooms in closer to the Machine for the beginning of the level.
2
Camera and controls
The camera is positioned in a corner above the level,
looking down at a slightly slanted angle. Use 45 degree
angles for testing purposes. The camera is centered on
the player’s vehicle and does not show the entire level
during play. An exact zoom level will be determined during testing.
The player controls the Machine by clicking and
holding LMB. The Machine will then accelerate towards
the cursor. If the player moves the cursor while holding down LMB, the Machine will rotate to keep facing
the cursor. When the player releases LMB, the Machine
stops moving.
All weapons and tools that the player has mounted on the Machine fire continuously. To destroy hives,
the player simply moves the Machine within range of one or more of the Machine’s weapons or tools. The
same is done to defeat enemies.
Enemies
Enemies will spawn out of destroyable buildings (henceforth ”hives”) and attempt to destroy the Machine. An enemy spawns every 3 seconds (tentative, to be determined during playtesting). Enemies have
20 hitpoints each. Boss vehicles have 500 hitpoints. When an enemy is defeated, it should disappear in a
cloud of smoke. Bosses eject from their vehicles the same way as the player.
Melee enemies simply move towards the player and start damaging the Machine when they’re within
attack range. If our schedule allows it, they should attempt to position themselves on a side of the Machine where the player hasn’t mounted any weapons.
Ranged enemies move up to their max attack range (to be determined), and then attempt to maintain
that distance to the player. Ranged enemies should always move slightly slower than the player.
Win condition
A building (”the castle”) sits at the top of the ramp down to the next level, blocking the player’s progress.
To complete the level, the player must destroy all the hives (each hive has 200 hitpoints), which will
prompt a boss enemy to appear out of the castle and attempt to destroy the Machine. The boss drives a
vehicle constructed from similar components as the player, but using one extra component that the player
doesn’t have access to.
When the player successfully destroys the boss, the extra component will be added to the player’s component list in the workshop layer. The player can then drive into the castle, which will open the workshop
layer and save a checkpoint. When the player leaves the workshop again, the Machine is seen driving
down the ramp from the previous level to the next level.
Damage and hitpoints
The only dynamic resource in Imachination is the structural integrity of the Machine (“hitpoints”).
Every melee attack or ranged attack that hits the Machine will reduce the Machine’s hitpoints by a small
amount. The Machine has 1000 hitpoints when each level begins.
The Machine has 4 health states: Pristine (91-100%), Dinged (51-90%), Damaged 11-50%), and
Critical 1-10%). When the Machine enters the Dinged state, its move sound becomes slightly strained
and it starts to emit light smoke. When it enters the Damaged state, its move sound starts to clank and
grate audibly and the smoke becomes black. The Critical state adds visible fires and billowing black smoke
3
to the Machine, and it sounds like it’s falling apart and about to explode (which it is).
Enemies attack for 5 points of damage once per second. When the Machine reaches 0 hitpoints, it
explodes spectacularly, and the player character is seen flying away from the explosion thanks to the cockpit’s ejection seat. The player is then returned to the checkpoint in the last workshop.
Repair power-ups
When you destroy a hive, it drops a repair power-up that you can drive into to repair your Machine by
20% of its max hitpoints. Particle effects should be used to make sure the player doesn’t miss a powerup.
Level Design
Each level will be a square platform suspended vertically over the other levels. As you move to the edge
of the level, you can see the hazy outlines of the next level below. Levels have the following elements:
hives, which spawn enemies and are destroyable; dirt mounds, which simply block the player but can be
destroyed; walls, which block the player and cannot be destroyed; the castle, where the enemy boss lives.
The castle is always placed at the top of the ramp down to the next level, such that it blocks the player’s
progress until the boss is summoned and defeated.
Menu: Sandbox
The Game Menu scene is set in a child’s sandbox, brightly lit by a warm summer sun. There is no gameplay here, and unlike the actual levels, you can’t see lower the levels. The scene depicts the player character
playing with toy trucks next to a hole he’s dug in the sand.
Caves
The first real level is an underground cave beneath the sandbox. Stalacmites and a few walls break up the layout of the
level, and enemies emerge slowly from three hives in different
corners of the sandbox. The boss drives a fairly vulnerable,
slow machine. The boss drops the bucket-wheel excavator
when defeated.
Earth Core
The third level takes place in the core of the earth, bathed
in the red light of flowing lava streams. Lava and walls
direct the player’s movement through the level, and enemies spawn at a steady pace out of four hives. Ranged
enemies are introduced here. The boss machine is slow,
but considerably more durable than the first. The boss
drops the TNT launcher when defeated.
4
Mines
The final level takes place in a network of Chinese mines.
Walls and tunnels limit the player’s movement significantly
and enemies spawn at a barely manageable pace from five
hives. The boss machine is fast and durable.
Cinematic: China
Not so much a level as the setting of a small ending cutscene.
The player is seen exiting a mine entrance on Chinese soil –
upside down! – getting out of the Machine, and jumping up
and down (or perhaps rather, down and up) in a celebratory
fashion.
Interface
There will be no HUD in Imachination. The only explicit interface elements in the game are an unobtrusive Game Menu button in the top left corner of the screen (the Game Menu can also be opened by
pressing Escape), and the equally unobtrusive Sound button in the top right corner which toggles the
audio on and off. Opening the Game Menu pauses the game.
The workshop layer also has a button labelled ”Ready!” / ”Parat!” which starts the next level.
Game Menu
See “Level Design“ above for details on the Game Menu scene. The Game Menu should consist of the
following buttons, implemented seamlessly into the scene:
•
•
•
•
•
Language / Sprog (Dansk/English) – indicated by flag icons
Return to workshop / Tilbage til værkstedet – greyed out if not in the world layer
Start game / Start spillet – greyed out if a game is already going
Credits / Rulletekster
Quit / Afslut
5
art document
Look and feel
Machines:
First and foremost the game is about the WOOW! Effect huge costruction machines has on children.
Fascinating construction machines are large, complex powerful and gritty. Hazard lines, dirty metal
and especially yellow frequent the look of the machines. Pistons, tank threads, grills are dsitrubuted on
the machine while its functional bit, be it a shovel, grinder, whatever useually is the eyecatcher in their
design.
6
Travelling trough earth:
Some of the coolest machinery there is is used in mining and digging. Digging is also one of the key
fascinaton elements tied to machines. Thus digging your way trough the earth using your huge machine
supports both elements of real machinery and the childs imagination.
Light supporting a feeling of a fantastic huge cavern. Earthly desaturated colours and flourescense.
7
Levels closer to the core of the earth will feature a more reddish and saturated light setting.
8
Workshop
Assembling a construction vehicle is gonna take a workshop of some sort, also something kids enjoy,
tools!
Important objects in the world are gonna be more saturated and the terrain less saturated to make the
important parts stand out.
9
View mode
The game has two main subdivisions: The vehicle construction part and the part where you drive around,
dig and smash things. To get a good feel of scale in the vehicles, being zoomed in close to vehicle, looking
up at it is desirable in the construction part, but when playing in the world, having an overview of what
is going on is essential. To give this oveview but still render the feeling of mass in the vehicle the driving
bit is pseudoisometric, meaning isometric camera mode but rendered with perspective
10
Style
To make it so the models will render well from a distance and not get muddied up, thus killing the intention of havng active objects marked by saturation, some stylisation of models is necessary.
For the models to render well they will be relatively simple with homogenous colour pallettes. However
they should retain some of the ”badass” that is synonumous with construction machines. We strive to
make to stylize to enhance and simplyfly details while keeping it looking cool.
To avoid having a childish look due to simple textures, the textures will have a hand painte feel to them
and lasty subtle texture added, which will show well in close ups and disappear far away.
11
Machine Design
Shape
The design is aiming for striking a balace between realism and cartoony.
Shape design guide with a demonstration vehicle and borders to prevent attachment clipping.
The machinery models will be relatively simple; built upon real machine parts but stylized to a) exagerate
the awesome pieces and b) make the machine feel really big. Exageration of awesome parts means that
the key functional parts of the machine are scaled up and skewed to support the feeling of powerful machinery. For example the arm leading to bucket wheel excavator (leftmost part on the illustration above)
expands leading out to an oversized wheel with big teeth.
As the main character is chinese, small China inspired details will be scattered around the model, also
to serve as scale indicators.
12
Early machine concept sketch, showing the huge scale of things.
Making the the machine feel big is done by adding details the children can relate to as having a certain
size, like the size of a child, the dimensions o a door, the width and spacing of bars on a ladder etc. These
details will be small relative to the rest of the machine, making it feel big.
Texture
Textures will have to be simple, yet contain the details needed to make the machine feel recognisable and
give it the flare of complex machinery.
13
Texture will be made by adding solid colour to components, then paint
black lines where details are desired. Then stylized occlusion shadows
are painted around corners and crevices, finally the texture had texture
added in photoshop.
Texture style, with black lies, solid colours and texture noise.
Shovel Arm:
Character design
The main character
As the quest is governed by curiousity and the childs tale about how you can dig your way trough the
earth to China, the main character is a child. A chinese boy digging his way home to China.
As with the rest of the game content, he will be stylized by having his important features exagerated.
In this case his head and his helmet.
14
Final main character Concept
Enemy minion design
Enemy minions will have to work on screen while being farely small, so their geometry and texture is
fairly simple. As the setting is deep below ground level, the minions are inspired by deep sea fish.
15
Final Enemy concept:
Enemy Boss
Bosses are going to have their own crazy machines, built from scavenged construction parts left in the
tunnels. This means machine assets will be recyclable. Showing the boss itself is a cockpit with a huge
version of the enemy sitting in it.
16
Environment Art
All the levels are underground, both due to story of the game and so that assets can be recycled. Non
essential level geometry such as the ground and inactive probs are going to be kept fairly desaturated in
general. Important world objects will have more colour to make them stick out as interactable.
Level Shape
The levels will be underground, representing a
progression trough the earth. To give the appearance of going down the levels will look like they
are connected with this layout.
As any significant slopes will detract from playability as a pseudo isometric layout and steep hills
will conflict. The added coding complications of
having an uneven playing surface has been deemed
not worth it, as the surface would have to be close
to flat anyway.
Thus the levels are flat. In function.
17
Like with the rest the textures are going to be hand painted, incorporating black lines and painted ambient occlusion and material texture.
Enemy Hives
The most important part of the levels are going to be the enemy boss spawn point and the enemy minion
hives. To give a sence of scale the hives will feature small windows and to be in tune with the underground
feel, they will include mushrooms and give of a flourescent light. Enemy symbols will be painted on to
indicate that a hive is a spawning point.
18
Differentiating levels
Starting out under the assumption that there will only be time to do props for one level, level differentiation will be done via lighting and tinting aswell as audio. The first level takes place just under ground and
will have a neutral blueish light setting, suggesting that some light from above is still reflected trough the
hole to the surface. The 2nd level will be in the core of the earth, light will be tinted red or orange and the
level will be overall darker. 3rd level takes place in chinese mines, the light will be tinted green and sound
will indicate the mining activity.
19
Interface design
Menus
The start menu and splash will feature a sandbox with the main character looking down into a hole. The
audio will be strictly children’s voices and the kind of noise you would hear in a playground. The character will occassionally blink and/or tip his head to the side.
The buttons containing options such as start play, tutorial, audio on off etc will be featured on the side
of the actual sandbox.
The look of the box/menu will reflect the look of the levels, a plane viewed from a corner.
Bearing in mind that the main character is imagining all that is going on, every time the player pauses the
game he will be taken back to the sandbox start up screen. This emphasizes the idea that once the player
stops playing the character similarly stops imagining and is back in the real world.
Vehicle Constructor
The construction of vehicles is going to take place in an abandoned workshop kind of place.
The attachments will be displayed at the top and the vehicle at the bottom.
On the side there will be a rotator button which will make it possible for the player to see where to
place the chosen attachment on to which part of the vehicle.
The attachments, e.g. the dynamite catapult, bucket excavator, are accessed and clicked on to vehicle
sockets by means of a drag and drop system.
The interface will only feature at the start of the game when you start constructing your machine and
when you complete a level. With each level the bonus components will be found at the top part of the
screen and the player can scroll the rope to the left in order to see what weapons are available.
In terms of style it will follow a more simplified version of the art style established for the game. In other
words it will be 2d rather than 3d - with the exception of the actual vehicle and the attachments once
they have been
dragged from the rope.
Sound Design
The overall dogma for the sound design production is that we want as many of the sounds as possible to
be produced by children from the target age group. There should also be some children singing in the
game music. This serves both as a means of giving the game a certain lo-fi sound style, and also to underline the child’s play theme of the game.
The sound assets are divided in to three layers: Music, Soundscape and Sounds.
Music
Every scene in the game has a different musical soundtrack in a style that reflects the mood of the particular game space. A soundtrack is divided into different parts, which are in turn triggered by events in the
game. For instance when you play a level, a new musical part could start every time a hive, castle or boss
20
is destroyed, thus helping to give a sense of progression through the level and heightening the suspense.
Technically this adaptive changing of musical parts could be facilitated in a way where all the parts start
playing in a loop when the scene starts but are muted until they have to play. In this way the tempo of the
music can be maintained even though the parts have to change on times that are musically arbitrary.
There will be certain musical themes that are shared between the soundtracks of the different scenes so
the music has a sense of consistency throughout the game. In the following are the different soundtracks
that will be produced. These pieces of music must eventually be chopped up into different parts and assigned to events in the game engine as described above. Thus these musical parts will be the actual musical
game assets.
•
•
•
•
•
•
•
•
•
•
•
•
Start Screen Music?
Game Menu Music
Workshop Music
Level Music
Sandbox Music
Cave Music
Earth Core Music
Chinese Mines Music
Level Complete Music
End Scene Music
Outro Music
Credits Music?
Soundscape
The soundscape is the environmental background sounds of a particular scene in the game. Technically
it will be produced in a generative manner handled by the game engine. The soundscape is generated
using small mono sound files which are played back randomly from different directions and with different volumes, to create the effect of an ever changing sound environment. The sounds in the soundscape
mostly represent the things in the environment which are not seen by the player. In the following list are
the different soundscapes that will be produced.
•
•
•
•
•
•
•
•
•
•
•
•
•
Workshop Soundscape
Radio
Sandbox Soundscape
Children’s voices
Birds singing
Trees whistling
Dogs barking
Open Air Reverb
Cave Soundscape
Dripping
Slow running water
Cave Ambience
Cave Reverb
•
•
•
•
•
•
•
•
•
•
•
•
Earth Core Soundscape
Lava flowing
Heat waves
Eruptions
Lava Bubbles
Dry Reverb
Chinese Mines Soundscape
Hatchets
Shuffling
Mine Reverb
Chariot on rails
Explosions
21
Sounds
The sounds of the game are single sound assets that are triggered by different events in the game. These
sounds inform the player of the crucial things happening during the game. Here are the game’s sound
assets:
•
•
•
•
•
•
•
•
•
•
•
•
Interface sounds
“Ready!” / “Parat!” Button
Rotate dais
Component menu
Game menu
Choose Language
Return to workshop
Components
Pick
Attach
Destroy
Weapon sounds
It hasn’t been decided yet whether we want the weapons to produce sounds when firing. Because of the
continuous nature of the firing, a rhythmical pattern would come out of this implementation, which
would then become a part of the game music. However this rhythm might be very annoying because of
its static and repetitive character.
•
•
•
•
•
•
•
•
•
•
•
•
Explosion/Damage sounds
Hives
Enemies
Vehicles
Enemy/Boss Sounds
Spawn
Attack
“Die”
Collision Sounds
Vehicle sounds
Start
Accelerate
•
•
•
•
•
•
•
•
•
•
•
•
•
Pristine
Dinged
Damaged
Critical
Drive
Rotate
Beep beep beep…
Stop
Engine slows down
Breaks
Explode
Power-ups
Repair
22
Technical Design Document
Internal standards
Coding conventions
All code will follow the coding standards already in use within the Unity Engine. All functions and classes
will be named in camel case, with an uppercase first letter. Variables follow the same convention with the
exception that they will be named with a lowercase first letter. Following this standard will expose public
variables in a friendly manner to the Unity Editor, i.e. enableWeapon will become Enable Weapon.
Scripts with common behavior should, to the extent it makes sense, inherit from abstract base classes
for a higher degree of control and reuse. An example of this could be the scripts controlling the weapons
attached to the vehicle base, as they all share the common behavior that they need to be enabled or disabled depending on the current level as well as a fixed firing rate when they are active.
File management
All assets for the project will be managed using the provided Unity Asset Server. There will be two distinct
projects on this server, the actual project and a test project. Most of the work will be done in the actual
project, but when analyzing and testing a new feature it can be suitable to start work in the test project as
no restrictions will be put on the standards here.
Whenever committing changes to the actual project it must be ensured that these do not contain any
errors and warnings.
All folders and files in the project will follow the same scheme as classes, i.e. camel case with a uppercase
first letter. For the moment it seems to be reasonable choice to group assets based on their type, meaning
that all scripts will reside within a subfolder in the Scripts folder based on the function they perform.
However this could change once we begin seeing the number of assets actually required for each object in
the game, at which point it might make more sense to have them grouped by objects rather the type.
Bug tracking
When all major features for the project for the project have been implemented, we will start using a bug
tracking system, either Redmine or Trac, which everyone in the team can submit to. The reason for first
implementing this at a later point is that we will be working with Scrum tasks up until this point, but they
would not be suitable for solving hundreds of bugs of varying size.
Performance
As the final product needs to run in the Unity Webplayer, on a wide variety of machines, performance is
indeed a concern. This applies both to the complexity of models, use of effects and the structure of the
code. The current strategy is to get the features of the game working before optimizing, as it is necessary
to identify bottlenecks for optimization to have any effect. However some general coding principles still
applies in the development phase.
Where ever possible avoid using nested loops in within Update calls. This includes building lists of
GameObject or Component, as this can become a performance issue. It is often possible to do this in
initialization code and store lists for later use.
23
Game implementation analysis
As all programmers on the team are more or less new to the Unity Engine a lot of the initial work has
been analyzing possible solutions for the programming tasks unique to this project. The following will
highlight the major required features.
Vehicle construction and workshop
As described under game design a key feature of the game is the ability to build custom vehicles. Our
analysis work has shown that this works fairly well with the Unity Engines object model. The design we
have chosen is based around sockets and attachable objects. When a new object is attached to a socket it
is placed in the hierarchy below the socket thereby inheriting all transforms associated with the objects
above it. This is one of the more complex features needed for the game, but so far the results have been
very good. This is partly due to the fact that we very early on decided to keep the system fairly simple.
The scripts governing the attachment feature must be robust and also handle detachment. A socket
script is used for all attachment points, but the actual instantiation and moving of new attachables will be
handled by the workshop gui scripts. By having a base script for all attachables we can ensure a uniform
treatment of these once they are created.
The current system, with small modifications, does allow for multiple levels of attachable components.
Such as attaching components with additional sockets in them, but as we are working to keep the system
as easy to use as possible this could be left as a possible extension in the future.
Persistence
Once a vehicle has been setup it should be moved to the next level. Unity does provide some utility
functions for letting objects survive between scenes, but they are messy at best if some framework is not
provided to control which objects survive and which does not. It was surprising that Unity did not have
a have a system in place for this already, but we discovered this at an early point in time.
The solution we are working with involves are singleton game script that persist throughout all scenes
of the game. Every scene will have a level script that inherits from an abstract level script that handles
retrieving the player’s vehicle from the game script and moving it into the scene. The individual level
scripts will have to setup the vehicle the way appropriate for the scene, e.g. workshop scripts needs to disable weapons and physics etc.
Movement and weapons
Different vehicle movement schemes have been tested, and at the moment the most suitable seems to
be using a striped down version of the physics engine. As the vehicle will only be moving in a 2d plane
restrictions to the physics needs to be restricted to provide a robust control scheme. This is partly done
by avoiding simple box, or compound colliders, instead of mesh colliders for vehicle environment collisions.
The vehicle will turn in increments towards wherever in the level the mouse cursor is currently placed.
The position is obtained by casting ray towards a plane placed in the height of the level. Whenever the
mouse button is pressed we apply a force in the forward direction of the vehicle. Some tweaking has been
applied to avoid situations where the vehicle would be skating along the old movement direction while
turning.
Weapons will be firing at all times. This is controlled in the base weapon scripts, while specific weapon
behavior is handled in scripts inheriting from the base script. A weapon that spawns projectiles, such as
the dynamite launcher, the behavior is additionally controlled by scripts attached to the projectile.
24
AI
A robust foundation for AI must be thought into the development. This requires a combination of two
things. A grid structure that can be used to identify positions of objects in the level and on top of this
a system for querying on the current state of the game. This should be paired with ability to control AI
units in an easy manner, this means path finding and predictions about the effects of using a weapon.
With these two elements in place developing AI scripts that can perform informed choices about the
game world should become fairly straight forward. However a substantial amount of research is required
to figure out how this can be done in a good way in Unity, as no one on the team has any experience with
this. This puts this high in priority, as we need to be able to make proper adjustments to the overall code
from an early point.
A major consideration is that we will be reusing the attachable components available for the player to
create the bosses for each level. This means that the weapons should be both fun for the player, but predictable enough for the AI to use. This basically means that weapons scripts needs to supply information
about what effect firing a weapon right now would have on the game world.
25
Production document
Project Management with Scrum
In this project, we aimed to use scrum methodology but a simplified way. This means that, we are not
going to divide the project into sprints. Usually scrum projects divided into sprints and each sprint takes
approximately 3-4 weeks. If we take the project time into the consideration, obviously it is hard to divide four-week-long project into sprints. On the other hand, we are going to use other benefits of scrum
such as daily scrum meetings. Daily scrum meetings usually take 15-20 minutes and all team members
expected to attend these meetings. Every team member has to answer three questions in very short time
(2-3 minutes):
1- What did you do yesterday?
2- What will you do today?
3- What obstacles are in your way or slowing you down?
Answering these questions helps other team member to clearly understand two main ideas:
1- Who is working on which task?
2- What is the overall status of the project?
After the scrum meetings, we made a quick design meeting (if needed) and try to discuss the concept and
game mechanics with whole team members.
After agreeing with concept and the game idea, we created a product backlog. We tried to write all main
priority tasks in to-do-list and low priority tasks in nice-to-have list. After the creation of product backlog,
lead management made time estimations about each task which were in product backlog.
Production Plan and Time Estimations
Gantt Chart View :
26
27
In the Gantt Chart we can easily see all the details of every tasks such as Start-Final dates etc. Also assigning resources (team members) to these tasks, helps me to observe and track the project easily.
Critical Paths for Artwork:
• Design of the garage (workshop)
• Vehicle body/base model and textures
Critical Paths for Programming:
• AI movements (pathfinding and attacking)
28
• Weapon collisions (melee and projectile)
• Attach / detach objects to the sockets
Although it is rough to make estimation at the earlier phases, the production length will be 21 working
days. We decided to work on special holidays (e.g. St.Bededag, Pinsedag etc.). Additionally, we reached
an agreement for working on weekends if necessary.
Milestones and deadlines
26.04.2010 – Pre-Production starts
1st Milestone: Playable prototype 03.05.2010
Art:
•
•
•
•
Basic vehicle model
Basic buildings
At least 1 melee and 1 ranged weapon
Basic workshop garage
Programming:
•
•
•
•
Character movement with cursor
Basic collisions with melee and ranged weapons
Building destruction
Attach objects to sockets
Sounds:
•
•
•
Basic weapon firing sounds
Background sound for one level
Basic vehicle movement sounds
03.05.2010 – Delivering documents and playable prototype
03.05.2010 – Production starts
04.05.2010 – Early prototype testing
2nd Milestone: Playable game with limited content 14.05.2010
Art:
•
•
•
•
•
•
Vehicle model and weapon models
Most of the textures
Enemy minion models and spawning hives
Boss vehicle
In-game animations (vehicle movement, weapon etc.)
Garage and at least 1 level with all elements
29
Programming:
•
•
•
•
•
AI movements and attacking
Damage and hits
Collisions with all weapon types
Level streaming between garage and level one
Attach/detach and preview objects
Sounds:
•
•
•
•
Enemy/boss sounds
Explosion/damage sounds
Vehicle movement sounds (rotate and stop)
Different background sounds for every level
14.05.2010 – Alpha test
17.05.2010 – Post-Production starts
18.05.2010 – Alpha test
20.05.2010 – Beta test
21.05.2010 – Beta test
3rd Milestone : Final game 25.05.2010
Art:
•
•
•
•
•
All vehicle models with textures
All weapon models with textures
Enemy minions and buildings with textures
Game menu and in-game interface
Menu and end scene animations
Programming:
•
•
•
•
•
Performance optimizations
Game balancing (AI movements, attacking range and damage)
Implementing all elements in the levels
GUI
Website
Sounds:
•
•
•
Game menu music
End scene music
Workshop music
25.05.2010 – Releasing final game and delivering final documents
30
Risk and Consequence Analysis
Risk
31
32
Test Plan
It is hard to find testers especially from our target group. Firstly, we try to find some children from team
members’ families. For example, their brothers, sisters or nephews can be ideal candidates for testing our
game. Otherwise we try to contact with some kindergartens or primary schools. Probably, it is not possible to bring the testers to our office. So we will try to go their schools to test our game and ask them
some questions about game feel and mechanics. During this short test sessions, we are going to record
their reactions.
33
Asset Pipeline Analysis
34