Project rapport
Team Flying Frogs
Version 1.0
Table of Contents
1
Introduction (group) ............................................................................................................................. 3
2
Reading instructions (group)................................................................................................................. 3
3
Organization structure (Tim)................................................................................................................. 3
3.1
Rolls ............................................................................................................................................. 3
3.2
Information handling ................................................................................................................... 4
3.3
Pipeline ........................................................................................................................................ 4
4
Choice of method (Tim) ........................................................................................................................ 5
5
Phase 1: pre-production ....................................................................................................................... 7
5.1
Developing the game idea (Lau) .................................................................................................. 7
5.2
Creating a design document (Lau) ............................................................................................... 8
5.3
Use cases/game mechanics (Lau/Tim) ........................................................................................ 8
5.4
Risk assessment (Tim/Per)........................................................................................................... 9
5.5
Making a plan (Tim) ................................................................................................................... 10
6
Phase 2: prototyping and testing of concept ...................................................................................... 10
6.1
making a visual theme (Julie) .................................................................................................... 10
6.2
Making sound (Mads) ................................................................................................................ 10
6.3
Main technical challenge (Per/Christian) .................................................................................. 10
6.4
Critical stage analysis (Hvem vil?).............................................................................................. 10
7
Phase 3: production/construction ...................................................................................................... 10
7.1
Plan A or plan B? (Lau)............................................................................................................... 10
7.2
Testing (Lau/Mads) .................................................................................................................... 11
8
Future perspective (to be discussed) .................................................................................................. 11
9
Evaluation (group)............................................................................................................................... 11
10
Appendix ........................................................................................................................................ 12
10.1
Use cases ................................................................................................................................... 12
10.1.1
Use cases developed in pre-production ........................................................................... 12
10.1.2
Use cases developed and changed in prototyping ........................................................... 12
1 Introduction (group)
2 Reading instructions (group)
3 Organization structure (Tim)
3.1 Rolls
To mimic real life situation as much as possible we have chosen to give each group member rolls. The
team consists of six members and therefore some members must take on more than one roll.
Tim Nielsen: Project manager, half programmer and content pipeline manager
As project manager it is Tim responiblity to have the overall view of the project and making schedules.
Furthermore Tim has participated in programming when he had the time. Tim has been the main
resource in trying to figure out the content pipeline of Source.
Per Lohmann: Lead programmer
Per has function as lead programmer and as such had the responsibility for estimating time spent on
each programming assignment. Furthermore Per did the technical risk assement of the use cases1.
Christian Wolfgang: Programmer, CVS manager and wki manager
The job of Christian has been to support our Lead programmer and do a lot of programming. It has also
been Christian’s assignment to manage our CVS and help the other team members use CVS. Christian
has also been the manager of our wiki.
Julie Houlberg: Lead visual designer and game designer
I conjunction with the other team members Julie main responsibility has been to take everyone ideas
and combine them into stunning visuals and maintain the overall visual representation of the game.
Julie has also taken a part in the design of the gameplay.
Mads Lyngvig: Lead Animator, sound artist and game designer
1
See BLA
A major part of Mads’ work has been to bring life into the models of the game by animation.
Furthermore Mads has worked with implementing sound into the game. Mads has also helped in
designing the game.
Lau Korsgaard: Lead game designer, level designer and playtest manager
Lau had the noble job of being Lead game design and therefore had the overall responsibility of our
gameplay. In conjuction with his job as Lead game designer Lau has also being doing most of the job
sitting up our level. Lau has also being managing our playtest throughout the project.
3.2 Information handling
In large groups information is crucial. In an effort to communicate efficient between members we have
used several different methods.
3.2.1 CVS
In sharing and version of code, text files, graphic, animation and sounds we have used CVS. CVS has
several features helping controlling files, like merging files, version control, fallback features. This has
helped us greatly in not override important files and always ensures that everyone had the latest version
of our files.
3.2.2 Wiki
The Wiki has been used to shared information regarding source, both technical and non-technical stuff.
We have also got several tutorials covering different subjects like creating mods in steam, using CVS. The
Wiki has helped us share information in a simple and clearly manner.
3.2.3 Governator
For the more important files like design document, process document and plans we have used
Governator. Governator is a multipurpose webpage which can handle document version, simple Gantt
charts and message boards. But Governator has mostly been used to easily access important documents
from everywhere.
3.3 Pipeline
Pipeline is used as a technical term and represents the work needed to be done to get a model into
source. In general a model has been constructed in max, animated in max, then coveret into .SMD files.
This then is “complied” into several files understood by Hammer and Source. When the files are
“compiled” it is a simple task using the files.
The tricky part of the pipeline is to learn the way it works and then ensure that no part of the pipeline is
ever waiting for work or is idle. Basically if member A has the job of “compiling” files, the .SMD files
must be ready or member A will be idle and waste valuable time.
To avoid the case above we fairly early in the process tried to identify any problems the pipeline could
contain by making a simple model and import it into Source. This is not a easy process if you haven’t
work with Source before and it took us a couple of days to get working. From there it was simple
planning, the visual artist made the models, the animatator animated and converted and “compiled”.
From there the programmers of the level designer took the files, depending on who needed it.
In a effort to minimize idle time for pipeline members, each member had other responsibilities and
could always work on other assignments. But we also tried to keep the number of people involved in the
pipeline to a minimum for easier coordination. Therefore at any given time only 2 members where
working with the pipeline.
Sound on the other hand is an entirely different story. Only one member work with sound in the entire
project. As a result no coordination between members were needed.
4 Choice of method (Tim)
Developing games can be a changeling job at best. Therefore the choice of development method must
reflex this. In our chase we have choosen to look at sereval different methods in a effort to find the most
suiddet method:
4.1 Unified Process
Unified process (UP) offers a large number of tool for developing software in general, but one of the
most important parts of UP is that it is iterative development2. Iterations in UP can be considered as
mini-projects ranging from a couple of weeks to a maxium of 8 weeks.
Another important concept of UP is that it is risk-driven, meaning UP uses Use-cases and rank these in
an effort to minimizes risks for the entire project3.
UP is divided into four phases4:
4.1.1 Phase 1: Inception
This can be considered as the phase where the initially analyse of the project happens. Work done is
this phase is approximate vision, business case, scope, vague estimates.
4.1.2 Phase 2: Elaboration
Identify and resolution of high risk, refined vision, implementation of core architecture, more realistic
estimates
4.1.3 Phase 3: Construction
Iterative implementation of the remaining lower risk. Prepare for deployment
2
[Larman ??] page 14
3
[Larman ??] page 17
4
[Larman ??] page 19
4.1.4 Phase 4: transition
Beta tests and deployment
4.2 Pre-production/production/post-production
We have chosen to name this method after its three phases. Pre-production/pro-duction/postproduction (PPP) is the first method mention her that focus on game development.
4.2.1 Phase 1: Pre-production
In the first phase of PPP it the concept of the game is difined, the time it take to produce the game,
manpower and a budget5. In the end of the pre-production a roadmap for the rest of the project should
have been developed.
4.2.2 Phase 2: Production
In this phase the production of game assets and code starts. At the end of the phase the game should be
finish, approved by QA and ready for release6.
4.2.3 Phase 3: Post-production
This phase is about closing up the project, learning from the experience of the project. Look at the pros
and cons of the project7.
4.3 Choice
Each method has its strengthens and weakness, and as result we try to take the best of each method
and combine them into a useful method for this project.
PPP should be a obvious choice as it focus on game development, but the fact that most details of the
game and development process need to be disied8 at the end of pre-production make it look a lot like
the water-fall model9. From our point of view the PPP is not espially open experimentation or
prototyping, and that is considered that games often requires the last in technology and the
development team often have low or no knowledge of the technology used.
This is exactly the case with this production, none of the team has worked before and therefore we have
to see at the possibility that we don’t know what we are doing. Therefore is it important that we choose
a method which allows us to prototype and even focus at the risk that we are facing. As a result we have
chosen to take advantage of some of the tools provided by UP. This includes the opportunity to
5
[????] page 5
6
[????]
7
[????]
8
[????] page 10
9
Not discut here
prototype and the risk-driven. In an effort to have some similarity to PPP we have chosen to use some of
the phases provided by PPP.
4.3.1 Game-prototype method
We have chosen to split our development process into three phases:
4.3.1.1 Phase 1: Pre-production
In this phase we will developed the initially idea of the game, write up a draft of the game design
document. Developed Use-cases and rank those regarding risks. Furthermore we will developed a plan
for the rest of the project.
4.3.1.2 Phase 2: Prototyping
New technologies introduce new uncerteties and in this phase we try to establish an understanding of
the source engine while trying to develop the most risky parts of our game. Further development of the
game concept will occur.
4.3.1.3 Production
When we have establish a knowledge and know-how of Source as well as developed the most risky parts
of our game we will enter the 3 phase – production. In this phase there shouldn’t be any surprises. This
phase is about wrapping up the game and documents and get ready for release.
5 Phase 1: pre-production
5.1 Developing the game idea (Lau)
We used the first two sessions together to come up with a game concept. To agree on one single idea in
a group of six creative people with only the technical limitations of source as constraint is a very
challenging task.
Our process stated as a normal brainstorming session. The group members came up with ideas in a lot
of different directions. After a few ours of constantly bringing up new game ideas the group felt a desire
of closing, not opening up, more possibilities. A quick analysis of the ideas so far showed that a good
deal of the concepts regarded the universe; snow fighting, frogs and fairytales, …, ect., fewer ideas
described game mechanics; turning and twisting camera, not killing but stunning people, ect. but almost
no ideas concerned the end goal of the game. Without a goal, mechanics and world couldn’t be rooted
in anything which gave us a hard time selecting the right ideas. Further energy was put into that area
and a goal came up, everybody agreed on were unique and challenging. The idea was that every player
was a part of both a normal team and a secret team. The player has the opportunity to either win with
her normal team or backstab the team and score a point with the secret team. This goal made it possibly
to be a lot more focused in the development of game mechanics. Our initial idea, after settling for the
goal, was a capture the flag game were the conflict were over possession of an item, this idea got
further iterated due to the wish of making a more experimental gameplay. In stead of moving a flag
between different goals the idea developed into moving the entire playing field towards different goals.
This idea evolved into a concept about moving a ball indirect by moving the entire playing field by
gravity, still containing the original goal of players playing on two different teams.
To the brainstorming sessions, each team member had brought a toy to help generate ideas and to
visualize concepts. The idea was to let toys help us think outside conventional genres and foster more
creative solutions. Instead of people saying “I want to make a squat based FPS like Counterstrike but
with the communication rose from Battlefield 2” the toys should help us propose concepts like “Players
should build castles with modular components like LEGO bricks but with the tactile feeling if Slime”.
Some of the toys also helped the group test concepts and reach a common understanding quickly. A big
pile of different coloured dices were used test the dualteam system, each player were assigned both a
number and a colour and after a few minutes the overall concept of the teams could be playtested and
understood.
5.2
Creating a design document (Lau)
What kind of template an how were it used
-also the technical
5.3 Use cases/game mechanics (Lau/Tim)
In trying to understand the requirements of our game we chose to divide the game mechanics into use
cases10. Use cases are functional way of describing player behavior avablie for the player.
This chapter contains the use case which is part of our game. Through out the development other use
cases have been discussing, but didn’t become part of this game. These use case can be found in our
appendix11
User case diagram
The use case dia
Use-case 1: Move sphere
Use-case 2: Through object
Use-case 3: movement
10
USE CASE MY ASS
11
Yeerhaaaaa
Use-case 4: Shoot enemy
Use-case 5: pick up object
Use-case 6: Score point
Use-case 7: roll ball
Use-case 8: spawn powerups
How did we use them
5.4 Risk assessment (Tim/Per)
One of the fundamental issues in development in general is to know what to develop next.
In determing which order the use case has to be developed in, we made use of a method known as risk
assessment12
More bullshit about what risk assessment is
Risk assessment
12
See Larman LGJSDLF
Use-case
TD
GR
Total
1
5
5
25
7
4
5
23
3
1
5
17
2
3
3
15
8
3
3
15
4
2
3
13
6
2
3
13
5
1
3
11
TD = Techical difficulties * 2
GR = Game relevans * 3
5.5
Making a plan (Tim)
Show how to incorporate the risk assessment in the plan
6 Phase 2: prototyping and testing of concept
6.1 making a visual theme (Julie)
How was the concept development of the visual theme?
6.2 Making sound (Mads)
How and why did we make the sound as it came out?
6.3 Main technical challenge (Per/Christian)
A description of how we planned to make the sphere roll and what kind of problems it gave.
6.4 Critical stage analysis (Hvem vil?)
The discussions and results of the critical stage analysis
7 Phase 3: production/construction
7.1 Plan A or plan B? (Lau)
From the beginning of the project the entire team had high ambitions. We wanted to challenge the
possibilities in the source engine and the hammer tools in design, arts and programming. To succeed in
this project the group found it necessary to use a tight risk assessment and start with the most unknown
variables. If some of the highest risk areas got delayed, we still had a change to adjust design and
planning according to the unforeseen events.
The project got delayed. After moth of developing a satisfying solutions to the main technical troubles
weren’t yet found. Programming worked really hard but problems with tilt of camera, bounding boxes,
figuring out the coordinate system of source and many other kept popping up. The team didn’t doubted
that the primary usecases could be done, but how many days or weeks it would take and how many
other features we would have time to do were still unknown.
A crisis meeting were held to discuss the future of the project. The possibilities seemed to be either
giving up the idea of making the players roll the entire playing field and develop a plan B instead or the
team could continue working towards the original idea but cutting of almost every other than the basic
rolling of environment. The outcome of the meeting was a compromise: Programming was given a week
more to show results, meanwhile design started to develop a plan B if it should be necessary.
Luckily a week was enough for programming to make some results. Plan B got cancelled and the team
kept working on the original concept.
-we picked plan a, but moved to other use cases than the most critical ones, why?
7.2 Testing (Lau/Mads)
A plan for testing from the beginning
Physical prototype with dices (to understand the concept)
2d digital prototype (to explore flaws in the design)
Internal gameplay prototype (to test balance and flow)
External prototype (do they get it? Theme, gameplay, interface)
8 Future perspective (to be discussed)
To do list
Considerations of sales and so on
9 Evaluation (group)
We need some kind of evaluation or conclusion
10 Appendix
10.1 Use cases
This section contains the use cases original indented for our game:
10.1.1 Use cases developed in pre-production
This section shows the initially use cases developed in the pre-production
Use-case 1: Move sphere
Use-case 2: Through object
Use-case 3: movement
Use-case 4: Shoot enemy
Use-case 5: pick up object
Use-case 6: Score point
Use-case 7: roll ball
Use-case 8: spawn powerups
10.1.2 Use cases developed and changed in prototyping