Effective Management Networks in

the Game Development Industry

Zachary Finley

A submission presented in partial fulfilment of the requirements of

the University of South Wales/ Prifysgol De Cymru for the degree of
Masters by Research

November 20, 2016

 Table of Contents
Effective Management Networks in the Game Development Industry .................. i

Table of Contents................................................................................................... i

Table of Illustration ............................................................................................. iii

Abstract................................................................................................................ iv

Introduction .......................................................................................................... 1

Why Management Networks are needed ................................................................... 1

Game Development Company Types .......................................................................... 9

What is a Hobbyist? .................................................................................................. 11

What is Indie? ........................................................................................................... 13

What is AAA? ............................................................................................................ 15

Chapter 1: Networks........................................................................................... 18

Hierarchies of Communication Hierarchies of Communication ................................ 18

Network Structures ................................................................................................... 21

Chapter 2: Iterative Design ................................................................................ 42

What is Iterative Design? ......................................................................................... 42

Chapter 3: Project Management Methodologies ............................................... 49

i
 What are Management Methodologies Relating to Game Development? ............... 49

Agile ......................................................................................................................... 50

Four Values of Agile .................................................................................................. 52

Twelve Principles of Agile ......................................................................................... 60

DSDM ....................................................................................................................... 89

Scrum........................................................................................................................ 94

Cabal ........................................................................................................................ 98

Chapter 4: Discussion ...................................................................................... 101

Chapter 5: Conclusion ..................................................................................... 106

Future Work ........................................................................................................... 111

Bibliography ..................................................................................................... 115

ii
 Table of Illustration
Figure 1, Heirarchies of Communication, (Pettinger, 2001) ............................ 19

Figure 2, AAA Company Hierarchy, (Ian Thomas, 2017) ................................. 28

Figure 3, Flat Organizational Structure, (Learnmanagement2.com, no date) . 36

Figure 4, Waterfall Method, (Manning, no date) .............................................. 45

Figure 5, Iterative Design Method, (Manning, no date) .................................... 45

Figure 6, Tribes, Squads, Chapters & Guilds, Kniberg and Ivarsson, (2012) .. 84

Figure 7, Evolution of DSDM, (Dynamic Systems Development Method

(DSDM), 2011) ................................................................................................. 92

Figure 8, Team Leadership, NYLT Syllabus, (2016) ....................................... 112

Figure 9, Stages of Development, NYLT Syllabus, (2016) .............................. 113

Figure 10, Team Development, NYLT Syllabus, (2016) .................................. 113

iii
 Abstract
This paper outlines and discusses the various networks and design processes

used by management in differing company types within game development. The

three company types studied are Hobbyists, Indie, and AAA each defined by the

number of their employees. The positives and negatives for each network are

analysed to determine which, if any, company type they best fit. The iterative

design process is held to be the keystone of game development as it allows for

greater quality of products to be created. At the same time, the iterative design

process allows developers to utilize their creative knowledge to make successful

games. This process is used in tandem with production methods such as Agile,

Scrum, and DSDM to provide means of stable and fluid communication between

development teams, a constant and efficient flow of information, and to provide

a positive environment for employees. This paper concludes with a few

examples of networks or mixture of networks that are ideal for each company

type.

iv
 1

Introduction

Why Management Networks are needed

When discussing the term management many different and varying definitions

come to mind. In this case, management will be defined as an ideology that

helps encourage and promote productivity and creativity in the game design

industry, not producers controlling the employees. This encompasses the power

structures, channels of communication, information networks, and

methodologies used in the game development industry. What will not be

included are the management methods and ideologies that focus with public

relations.

Many of the possible downsides in management that will be looked at

come from The Tyranny of Structurelessness, (Freeman, 1970). These

downsides will be applied to the gaming industry and how companies can

mitigate known issues. Another issue all companies have to face is to consider

their product from the eyes of their audience and their shareholders or investors

and which one to satisfy or both if possible. Methods will also be looked at to

develop a formal structure of management that promote productivity and

creativity.
 2

Structure is needed when a group of people form together with a similar

goal or ideal and is used to organise the team so they can effectively

communicate and complete needed tasks to achieve the end goal, (Freeman,

1970). In some regard, every group of humans form a structure in which to work

and communicate within social and production constructs, as is explored in Jo

Freemans 1970 publication. This pamphlet discusses the AWA, Anarchist

Workers Association, and the British Womens Liberal Movement; specifically,

how they wanted to avoid using conventional hierarchies of structures prevalent

in the world around them and remain groups with no structure. These groups

wanted to be set up this way because they wanted to go against the current over

structured nature of the society they lived in. However, without knowingly

implementing a system of communication and operation, a structure was formed

in which workloads were distributed either fairly or un-fairly, lines of

communications established and a power structure developed. This is known as

an informal organization, which allows observant members who are aware of the

rules of the group to have the power to make the decisions and make changes for

the group as a whole, (Diefenbach and Sillince, 2011). Keeping a group

structureless does not prevent the formation of a hierarchy of power but,

rather, only prevents a formal structure from taking shape, (Freeman, 1970).

A major downside of a structureless organization is the lack of chosen

spokespersons for that organisation. This lack of a spokesperson prevents the

group from deciding issues that will be asked about by the media and the public.
 3

Freeman does not specifically define what a spokesperson is or their role but

does imply that a spokesperson is someone directly responsible for talking with

the media in order to spread the ideas and goals of their organization; public

relations, (CIPR, 2016). The purpose of a movement such as the AWA and the

British Womens Liberal Movement is to spread their thoughts and views about

the over structuralized nature of the times as well as the unfair working

conditions women were expected to endure. The British Womens Liberal

Movement held a conference to discuss a rally they were going to hold in

London on March 6, 1971 on International Women's Day. They had several

demands to make so that working conditions were equal to that of mens.

However, many new women joined after the conference but were not informed

about the rally or the demands that were going to be made. These new members,

when asked, could not tell what the organizational slogan was or what their

goals were. In November 1972, they held their last national conference, which

was well organized, but nothing was achieved and groups remained divided in

their understanding of goals and the organization as a whole remained

ineffective. The reason for this ineffectiveness was a lack of structure as stated

in Freemans paper, (1970).

This is much like game companies, they wish to develop games and

release them to a wide customer base. Without a chosen spokesperson, a

member of media or public could approach any person from the group and

whatever they say can be construed as the official standing of the group on the
 4

subject asked about, (Freeman, 1970). This phenomenon is called the Star

System because it can make any member of the organization a star in the eye of

the media and the organization regardless of their position and experience. This

perception of responsibility from the media and public will unintentionally cause

internal issues between the new star and all of the other members of the

structureless organization. Goals of the company become confused and

mistaken. This individual also becomes an outcast in the organization because of

the new responsibility they have, which is directly contrary to their standards

and expectations of all members and ideals of the structureless organization. The

Star System also gives the individual a new form of power in the organization

given to them by the media. This causes friction in the organization by the

individual agreeing to a non-individualistic responsibility that has now been

thrust upon one of their members.

This type of Stardom can be particularly bad in a creative industry such

as game design because every creative designer in a company will have their

own unique opinion and views on their product. A level designer will describe

the game in a completely different way than a 3D modeler. On the other hand, a

selected representative can gather an overview of the product as a whole and

give a well-rounded description of the product. This selected speaker will then

be able to address the media, the public and other internal stakeholders and

employees about topics. The spokesperson can also give consistent reports on

the features, progress, and general updates that will be approved and accepted by
 5

the company as a whole. This reliable and steady information will give the

media and public a positive attitude about the company and the product they are

working on instead of a confusing and untrustworthy view based on the reports

of many individuals of the company.

Freeman also discusses how an organization that has no structure can be

taken over by a group(s) of elitists. She defines elitist as nothing more than a

group of friends in an organization that all agree upon similar goals and

aspirations even if outside of an organization, (Freeman, 1970). This group of

friends in a structureless organization will have the power of numbers which

allows them to alter the direction of decisions and goals. Elitists are effective at

altering a collective group because they communicate efficiently inside and

outside of that organization. These established lines of communication have,

most likely, been organized and maintained for a longer time than they have

been at the current organization. This allows the groups of elitists a subtle way

of communicating with each other during meetings, influencing outcomes of

decisions.

Freeman (1970) outlines two potential downsides from an organization

controlled by these groups. The first is based around how decisions are made for

the entire group. The groups will become more like a fraternity which people

only listen and agree on topics because they like the person speaking and pay

little attention to the actual topic of substance of what they are speaking. The
 6

second is the lack of responsibility the elitist groups will have or be held to.

Since they are members of a structureless organization with no leader voted or

hired in, they were never officially given the power to act or decide of matters of

business. If no one gave them the power then no one can take it away from

them. However, if a group wants to retain their influence over the larger

organization they typically do remain responsible in their actions. This does not

keep them from making selfish and harmful choices for the organization

however. This is of course all dependant on what the goals of the elitists are for

the organization.

A formal structure would be laid out in a manner so that every member is

aware of the rules of the group and all have the power and knowledge to make

changes, adjustments, and decisions in the group. This is a structure in which

everyone knows their roles and everyone elses roles in the group and

communication flows freely and openly. There are no Stars and there are no

groups of Elitists.

These examples can apply to any group of people working together

toward a similar ideal or goal. If a small hobbyist group or indie company of

game designers wants to remain free from the political entanglement of

management, the groups will inevitably form some structure for communication

and decision-making; this will be a formal structure as they are not trying to

protest management as the AWA and British Womens Liberal Movement

 7

were trying to do. Some small-to-medium-sized companies, such as Supercell or

Valve, have managed to obtain an arrangement in which the company as a

whole is structured into small groups of people without a designated leader of

the individual groups or of the company as a whole, (Krogh. Geilinger, 2015).

This, however, is done through very careful planning and a formal network of

communication, with the understanding that is still a structure of management.

Larger game companies or groups of people will find that trying to form

a relatively informal management structure is difficult, if not impossible, based

on the number of people involved, (Wiley, 2016). The more people working on

a game or product, the more teams the group will have, which in turn means the

more managers or project overseers. With more managers come more lines of

communication between people and groups of people, which, based on how well

it is set up, can keep workflow moving smoothly or cause issues and

complications. The idea of structurelessness is to avoid having managers or

leaders in a group while at the same time having that group of people working

towards a similar goal, (Freeman, 1970). When a large group of people do not

have a dedicated leader, they will need to have very good communication and

personal understanding of the project to make the product feasible in the first

place. The other issue with no formal group leader, is who makes the final call

on an issue when there are several possible solutions available. The only way to

get close to achieving structurelessness in a very large team is to have

producers and leaders occupying solely an internal employee disagreement

 8

settlement role, allowing the designers, group or individual to use their creativity

to build or create the product the way they think will be best.

Game companies may mitigate issues with the Star System effect

because big or small they will ideally, have a representative to discuss their

products in an agreeable manner with other employees and promote accurately

to the public. Small hobbyist groups, which only involve a few people, will have

less issue with Star System effect occurring. A smaller Indie game company is

very similar to hobbyists in this regard as well, they do not have a massive

amount of employees and everyone knows what the game is about; however the

larger Indie companies will have at least one or two selected representatives or

public relations (PR) officers to release information about their games to the

public. Larger AAA (triple A) companies with hundreds of employees will have

a team of PR representatives to advertise their games, build up hype, and

intrigue among the press and public, (Hierarchical Organisation,

http://www.learnmanagement2.com/hierarchical%20structure.htm, no date).
 9

Game Development Company Types

In the case of this study there are only three types of companies; small, medium

and large. Each of these will be regarded in the course of this paper as each has a

unique method of management that will be most effective. There are two

different management methods that are not only based on the number of

employees but also the product being created. For example, a steel mill will

have a very different management method than a law firm, as they each offer

different products or services, as well as differing numbers of employees.

While game development companies all offer the same type of product,

games; different methods can be utilised based on number of developers and

length of the development cycle. This paper will discuss three types of game

development groups: hobbyist (bedroom coders), Indie, and AAA (Triple A).

These three range from having one designer to as many as several hundred game

developers, coders, level designers, play testers, artists, animators, audio

developers. As a company hires more developers to work for them they will

have more people to manage, more design ideas to take into consideration, more

features being developed, and potentially more issues to deal with, (Meinhard,

no date).

These three company types are all very unique and different; there is no

one right way to manage creative designers and their projects. For the most part

as game production progresses, the management being used will need to be fluid
 10

and flexible to allow for the unknown. The game may take an unexpected turn

for the worse, which could be a major feature suddenly not working. This game

breaking bug would require more time or more resources will be needed in order

to finish the game or fix it. Another possibility would be adding a new game

feature either by intention or through an unforeseen combination of game

mechanics.

While developing an infinite runner game, Onions (2017) discussed that

towards the end of development directors wanted the addition of werewolves

into the game. This impromptu request delayed the deadline, tripled the size of

the game, and doubled the time to complete. The reason for the increase of size

and time is due to the developers needing to incorporate the werewolf feature in

a way that fit coherently with the rest of the game.

 11

What is a Hobbyist?

A hobbyist is a person or a small group of people, two to five, that design games

over a very long period of time with no publisher or funding from outside

sources, (Diefenbach, and Sillince, 2011). Lacking a publisher and outside

funds, the workload and work schedule can be very unpredictable. Additionally,

the members of a hobbyist team may all have day jobs to provide for their living

expenses and the expenses of their games, which is the reason the games take a

lot longer to complete. The upside to being a hobbyist is that, with no publisher

and no rigid period, these developers can take as much time as they need to

finish the game. This can ensure the game is ready when the developers believe

that the game is polished to its fullest degree.

One possible inadequacy that stems from hobbyist teams is the lack of

detailed documentation about the game at all stages. Hobbyist developers

without funding do not have very much time to work on the game from day to

day so they focus more on production of the game rather than documentation.

These teams or individuals can get away with this practice if there are very few

people involved and communication is very effective. Without detailed

documentation, solutions to various problems can be lost as more work is done.

This can cause the team to become less effective if the problem occurs again and

they no longer remember the solution they used beforehand. With a lack of
 12

documentation the developers cannot simple go back through documentation

and look up the method previously used.

The structure side of a hobbyist team is very different to either an indie

or an AAA setup. Since this team is composed of one to five people, each of

these individuals will need to have a wide range of abilities in order to fill every

area required of game design: art, coding, playtesting, audio design, etc. This

small team should not waste time with a designated project manager, apart from

the person who generated the main game idea, but should instead loosely

communicate with everyone else in the team about things that need to be done.

This can be done easily in a small team because everyone will be in the loop and

information will reach everyone in a short time. This structure of

communication is more commonly referred to as a simple decentralized

network, (Pettinger, 2001, Figure 3.1), in which all information flows freely to

everyone involved. This network results in good performance among teams

because no one person becomes over-burdened with too much information,

(Pettinger, 2001).
 13

What is Indie?

An indie company consists of a team or a group of teams numbering from eight

to thirty people. An indie company is very rarely larger than this. For the

purpose of this paper, Indie game developers will be referred to as SMEs, or

Small and Medium Enterprises, which is defined by the European Commission

as: An SME is a company that has less than fifty employees for a small

company and less than 250 for a medium, (What Is An SME? - European

Commission, 2016).

Indie companies will be more specifically referred to as the Small side of

SME, as they generally involve fewer than fifty employees. SME game

companies usually do not have a publisher that they work for, but they do have

some kind of outside funding, be it obtained from crowd funding, loans,

Kickstarter or government grants, (DellaFave, 2014). With revenue available for

Indie companies, a period for completion is required for each game. With a time

frame there will need to be some sort of management in each team that can set

milestones, deadlines, write the necessary documentation, and schedule play

testing sessions. Indie companies will use a formal system of hierarchy, in which

everyone is aware of everyones responsibilities and all members of the team are

able to make suggestions or make decisions relevant to their field of work.

 14

Having this number of people working on a game allows for

specialization among the members. This means that two or three people can

work exclusively on the code of the game while another two or three can work

on the art, etc. Ian Thomas, (2017) who has worked in several Indie companies

said they do have employees who work in several areas such artists who work

on assets and audio or coders that playtest. A few of these members may even be

in management positions to push all of these things along as well as keep the

game on schedule, within the allotted capital available, and to make sure

communication between the members is smooth and efficient.

The networks that would normally be used by SME companies in the

game industry is a mix between briefing and simple centralized systems. A brief

network is a structure in which one person in the form of a presentation delivers

information to a group of people, who then take this information away; this will

be discussed in the next chapter. The company as a whole when being assigned

a new game to design would use a brief network. This network allows for a lead

designer, who would be the briefer, to give each group, art, code, play testing, an

overall goal to work towards. The performance of a briefing network is

determined by the quality and detail of the brief given. The groups then take the

brief presented and create the product requested using a simple centralized

structure. A simple centralized network involves all information in a group

flowing to one person, group lead, who could then hand out new tasks and

evaluate all the products designed by the group. This group lead would then
 15

communicate with other group leads in order to determine what needs to be

finished next and the position of the game as a whole. This type of network

results in a good performance from the teams and the groups.

What is AAA?

An AAA company is the equivalent to a Hollywood movie company. It has high

production value, has a team ranging from fifty people to upwards of four

hundred people. AAA companies have the highest allotted budgets, promotions,

and ratings among professional reviewers, which brings the expectations of

being a high quality game as well as a game of the year, (Shultz, 2016). Because

a publisher is paying these companies, most will have a strict deadline as to

when the game will be released with a little leeway. This is a very formal

structure compared to the others discussed, (Meinhard, no date). There should be

a strict set of rule to follow from lines of communication, expected workloads

for each member, and legal contacts to fulfil.

Companies with this large a workforce have people that are each very

specialized, with skills ranging from, coding, art, audio, etc. They are broken

into smaller teams within the overall company. These groups are then to be led

by a manager or small group of managers that should communicate with the

other group managers and make sure all other groups know what they are

working on and what they may need other teams to work on next. Ian Thomas
 16

outlined this in an interview about a AAA company he worked for as a

developer, (2017), this will be discussed in a later chapter. These managers

should also communicate any problems that need to be solved, new features that

should be added, and distribute the workload through their respective groups.

Further, the managers of each group have either an overall manager, who acts as

the lead designer of the game or the person who final decisions about all aspects

of the game. The lead designer also communicates with the lead producers and

makes sure the time and funds are available for the teams so the work is not

hindered. This frees up a lot of time and alleviates stress so the development

team can focus entirely on the game.

An AAA company should use a very similar network system as Indie

companies but on a much larger scale. There should also be a lead director of a

game idea and they will give a brief to their lead producers in each of their

respective fields, who in turn give more detailed and focused briefs to their

group or groups. Some AAA companies have several art teams and several

coding teams, each with their own tasks and managers. Having several teams,

helps break up the workload for a very large project and can allow for a rotation

of work to keep teams from losing enthusiasm for a project. This rotation also

allows the designers to learn new skills and widen their views of their fields,

(Panagiotakopoulos A. 2009). Antonios Panagiotakopoulos discusses how new

employees are trained by pre-existing supervisors on basic operating procedures.

Once they have basic training they join the work force but will continue to
 17

receive training in their area of employment by more experienced personnel. He

describes older employees who have done the work for a long time become tired

of the monotonous processes and so the company allows them to train in a new

area and work there. This allows experienced employees to continue to learn

new skills in many different areas, which enables them to train new employees

in more positions available at the company.

Development teams would then use a simple centralized networks

system in which to communicate with their managers on their tasks, issues, and

workloads. The simple centralized structure would then work in reverse back up

the chain to the lead director when giving them updates on the project as a

whole. With a mixture of networks it results in the company being very

productive and having an evenly distribution of work between all members.

 18

Chapter 1: Networks

Hierarchies of Communication Hierarchies of Communication

Communication between members of a development team is a key aspect to a

games success, and is often the reason for failure or delays. Without an

understanding about the chain of communications that should be used in

companies, either formal or informal structures; delays, complications,

inefficiency in development and confrontation among team members will arise.

However, with a well-structured and understood hierarchy of communication,

development can progress smoothly. Figure 1, (Pettinger, 2001) shows the many

different structures of communications in companies and teams; there are more

not shown. Each structure has an upside and a downside. These positives and

negatives are simply observations of groups using these networks and can vary

for each implementation of each network. Different companies or teams will use

different network structures or combination of networks based on what is most

efficient for the companys production line, (Meinhard, no date).

 19

Figure 1, Heirarchies of Communication, (Pettinger, 2001)

Many of these networks can and do exist together and work in a

company, merging their roles to allow better management of teams and groups

of people. One example of this is Supercell. Supercell is a company that uses a

mix of a briefing network as an overarching structure for the company, while the

individual teams inside of the company use a simple centralised network. These
 20

mixed networks are known as a Matrix Structure. Devane (2012) defines a

Matrix Structure as a company that has more than one command structure that

employees use to report work.

However, Matrix Structures do have their fair share of problems. The

main issue this mixed network faces is the reporting structure that comes with it.

One group of employees will report to one set of managers while another group

reports to a different set of managers. This can cause power struggles between

managers. Clear and concise lines of communication need to be created and

maintained as well as procedures for reporting work to managers, (Devane,

2012).
 21

Network Structures

Simple Centralised Network

The first network in the table is a simple centralised network. The simple

centralised network is best used with a single person that has many outsiders

doing research, and gathering materials. The members gathering the information

then send the information to that one person in the centre who gathers, compiles

the information and then uses that to make the product. These groups of people

are defined as nodes and signified as the dots in the images. This network results

in good performance as there are no communication breakdowns between the

central node and various teams of people. This structure would not be good in

large teams or companies for extensive products as the increase of individuals

leads to an increase of information gatherers. The more information flowing in

takes away from development time, instead increasing the time necessary to

sorting the useful information from the useless. This network is ideal for

hobbyists and very small indie companies.

With game design companies, the central node would be a manager who

assesses all of the flowing information and decides on any action that will be

taken. The outside nodes are the developers or teams of developers that work on
 22

the game itself in all aspects: code, art, level design, etc. As they design features,

they send their work to the central node, who decides the best way to use it. The

lead developers will either use it as is, very unlikely, scrap the information or

prototype, or change it and make alterations, which is the most likely, (Donald,

2013). After the central node receives the work from an outside node, it can then

give the outside node a new task to work on keeping everyone involved in this

network efficiently.

Simple Decentralised Network

A simple decentralized structure lets information of a project flow between

every node in the team or group freely. This form of communication results in a

grapevine, repeating, of poor performance, which cascades throughout the

company. The general teams that would want to use this type of structure are

very small hobbyist and indie companies that do not want to assign one person

as a leader or official director. Without this director or resulting team guidance,

the lines of communication and documentations may become garbled and

misunderstood, with pieces of information missing as it is passed from node to

node, (Mookherjee, 2016). This can result in features not being finished or being

forgotten entirely, bugs not being fixed or reported, and deadlines not being
 23

achieved. This network structure would only be effective if every member of the

team knew exactly what their workload was, when it was due, and all members

were very dedicated and clear when documenting and reporting both positive

and negative results.

This network type would not work well in large development companies

as there are too many members working on one product. Without some form of

structured communication and guidance about what ideas make it into a game

and which ones do not would cause heavy workloads, frustrated members, and

repetitive tasks to complete. This structure would not be used as the main

structure of communication in very large teams; however, it can be an effective

secondary structure in smaller, more specialized groups of a large company,

especially when mixed with other networks, (Devane, 2012).

Complex Centralised Network

The third network is a complex centralised network, it has a central node that

becomes over saturated with information. The outside nodes send in too much

information for one person to review and sort through. The main difference

between simple and complex centralised networks is the amount and the quality

of information being gathered and sent to the central node. This over-saturation
 24

is a result of the amount of information flowing to the central node. The large

quantity of information results in poor performance because of the need to sort

and categorise the information. The better the quality of information, the easier

the task will be for the central node. This network is not widely used and any

form will result in inefficiencies and poor performance, (Bitcoin College, 2014).

Complex Decentralised Network

A complex decentralised network is simply a larger and more complicated

version of the simple decentralised structure. Information can freely flow among

all members of the team and no one person becomes saturated. The main

differences between a simple and complex decentralised network is that the

complex version has a dedicated director that controls overall content and

quality of work. A complex network has a greater number of members involved

in the project as well. This results in good performance and good products

because the work is distributed among every node that it needs to be. Further,

only nodes necessary to complete a task are engaged; therefore no one node

becomes overwhelmed.

Indie and AAA companies are most likely to use this system, as they

have a large numbers of people working on a game project. Managers

 25

preferring not to hinder the creativity and flow of the designers must allow and

enable designers to work the way they find best. This network allows the content

to flow between everyone that should be involved that allows for the best quality

product.

Even though companies may use this network as a main structure, other

networks may have influences over various aspects of the business, such as

documentation, meetings, communication, hierarchies, production, or

evaluation. This network is most often combined with small hierarchal networks

and briefing networks, (Devane, 2012).

Hierarchical Network

The hierarchical structure is the most commonly used network among very large

companies that split their employees into smaller specialized groups. These

smaller groups report to a lead designer. This structure of power continues all

the way up to stakeholders of whoever is supplying the funds for the game. This

network allows workloads to be split up evenly among groups as well as

allowing for easy communication between these groups. This easy

communication allows for smooth file sharing, sending files such as art assets or

prototypes to different people or teams. This communication between groups

 26

happens only through the leaders so that the information passed between

everyone is filtered to only include important and relevant information, an

example of this is shown in figure 2, (Ian Thomas, AAA Company Hierarchy

2017). Information is passed between the leads of each group up and down the

hierarchy. This filter of information allows the developers in each section to

focus on their work and spend time developing the ideas and testing them. With

this system in place, the work will be efficient and quick, permitting for a

greater amount of work to be completed to a higher quality. Large companies

prefer this network to others because of the breakdown of information and the

amount of work that can be completed. This form of communication also allows

the lead game designers to be kept in the loop with all developmental progress.

This loop lets them make changes quickly, add or take away features, and set

deadlines and goals to be reach for each team. This is a very effective structure

of communication for AAA companies and large Indie companies. However,

this network can break down with long hierarchies; the information being passed

between them can get muddled and misinterpreted. When this occurs, it is best

to add in other networks such as a complex decentralized structure to make sure

information passes freely among the members of each team, (Devane, 2012).

Ian Thomas (2017) discussed how the hierarchy of communication

functioned while he was working for a AAA company. He did not want the

name of the company included for anonymity purposes. There were about 500

developers at the company and the company worked on two to three projects at a
 27

time. He drew an outline of the hierarchy from his perspective seen below in

figure 2, (Ian Thomas, AAA Company Hierarchy 2017). The company made a

specific type of creative story telling game with destructible and constructible

environment. They have the game systems developed and have teams customize

the use of these systems for the game they are working on at the time. Each team

is specialized for a specific task relating to the production of a game. As they

develop the game, they create cut scenes for story, animations for characters,

vehicles, etc., and port the game to multiple platforms. Communication between

teams travel between the leads of teams up and down the hierarchy all the way

up to stakeholders and executives. The lead developers and managers are

separate in this image because they oversee every project not just one, but

communicate with all projects. Ian stated that in these large AAA companies the

traditional path of management is, Great designers are promoted to become bad

managers. This phenomenon is known as the Peter Principle, (Peter, Hull,

2009). Laurence Peter defines this principle as, The employee had been

promoted from a position of competence to a position of incompetence. I saw

that, sooner or later, this could happen to every employee in every hierarchy.

Peter then gives an example in which employees filling a job vacancy and how

they are given the new job position because they are competent at their current

position. However, once they rise to a position they are incompetent at they stop

being promoted and, as Peter puts it, [] has reached what I call his level of

incompetence. He will stay there until the end of his career.

 28

Figure 2, AAA Company Hierarchy, (Ian Thomas, 2017)

 29

Briefing Network

A briefing structure of communication is very common among game

development companies and used in combination with many of the other

networks listed in this section. Other networks that may be used are complex

decentralized and hierarchal networks. A brief network is a single or small

group of people; publishers, lead developers, or even stakeholders, that think of

a game idea and wish to make it a reality. They would develop the idea as far as

they can and write a design document outlining all aspects that they can think of

at the time. Once this process is done, they would gather a team of coders,

artists, designers, etc. to develop the idea. They will give each team a brief of

what their area of the game will comprise of and what their responsibilities

involve. After the groups have been briefed on the overall project goals, they are

set free to design and create what they believe to be the best possible product for

that brief. The quality of this type of communication results are efficient and

with good production but is related specifically to the quality of the brief given.

If the brief is short, non-specific or full of holes, then the developers will have

little to base their work on, resulting in teamwork that may be very disjointed.

The greater the clarity and quality of information presented to the development

teams will result in a better understanding of the desired objectives. This allows
 30

a greater understanding between each team with minimal miscommunications

and misunderstandings, (Businessballs.com, 2016). This type of network can

also work well with a chain network as multiple teams within teams can be used

to develop the product. However, every brief given should have the same quality

of detail as the original brief. If they do not then the bottom groups will not be as

clean or cohesive as the original teams given the brief. The information that

travels in this network is linear from the brief presenter, the person who presents

the brief or idea, to teams. Communication also works in the reversed,

consisting the progress of the teams to the briefer. This chain allows the lead

developers to make changes to their design document and then give regular

updates on the brief to enable the teams to make changes to their work. This is a

very repetitive process so companies using this structure should expect to give

one large overall brief at the start of development and then several smaller

update briefs throughout the project to keep the game evolving and growing.
 31

Hourglass Network

The hourglass network of communication is largely used by the internet for

filtering information from servers to the public. The structure of an hourglass

allows for all information from one side to pass to another through a small area

that restricts movement and allows all information to be checked, filtered, and

managed. This leads to all performance occurring in the neck, which slows

down production, communication, efficiency, but leads to a very high quality of

work.

With a low production speed, this network would be ideal for small Indie

teams that desire a very high quality of work without being slowed by a lot of

information passing through the neck. Large game companies would suffer

under this type of network, as they would have many teams all with a lot of

prototypes or pieces of information being created and flowing out towards the

neck. In this situation, the neck represents a severe bottleneck and slowed

production. With large teams and a large amount of work being produced, this

structure would represents missed deadlines as well as heavy workloads being

placed on the neck; the quality of work may actually be reduced, rather than

being improved. This structure is, overall, a poor choice when implementing a

communication network in a large game company. Quality is always desired

 32

when creating a product but by using a structure that does not fit the output of

production, quality suffers tremendously while at the same time adding stress

and unneeded workloads for team members.

Chains Network

A chain network is much like the game Chinese Whispers, (Advameg Inc.

2016), a verbal activity that starts with one person making up a phrase such as

The red fire truck drives very fast and passing it onto another person. The

second person will then pass the phrase along to a third and so on until the

phrase is heard and repeated by everyone playing. As the phrase is passed along

through this chain of people, individuals mishear some words and replace them

for what they think was said, resulting in a very different phrase by the end of

the game.

A game brief is given to a group of developers who then takes what they

learn and present the game idea, now with changes, iterations, and additions, to

another group of developers. The process occurs again within the second team,

and the brief continues to pass down the hierarchy with successive changes

throughout. With each presentation of the game, the idea will change and,
 33

depending on the quality of the brief, much of the core game may change from

each presentation to the next.

This type of communication is very detrimental to the initial game idea.

Game design companies will very likely avoid this type of communication

because of the many troubles it can cause in the developmental process. If a

company does use this structure, they should expect a loss of quality of the work

being produced. The work that is produced may not be coherent with each other

or the initial game idea. This can result in a loss of enthusiasm for the project,

and slow movement of information between one person to another or between

teams working on the project. Chain networks do not work well in any type of

company but if a development team does choose this as the basis of their

communication network, they should ensure that every team and every member

has a very clear idea of what the game project is and exactly what their

responsibilities are. There should also be very regular checks on the work of

every team to make sure that no one has misunderstood their developmental

responsibilities. Communication between everyone will have to be very

effective as well, keeping all stages of the game coherent and on track with each

other. Other structures of communication and work dispersal tend to be more

efficient and easier to manage.

 34

Cascade Network

The cascade structure is used with other briefing network structures such as

hierarchal and decentralized networks within each cascade level that pass

information from one group to the next. However, the difference is that in a

cascade network the information only flows down and not back up like in the

others. In the cascade structure, the information starts out at the top of a pyramid

hierarchy and a brief is given to a group below them. After the second group has

received the game idea and understand what is expected of their teams they will

then present the same game idea, possibly broken into specialized fields, to other

smaller groups that have the skills needed to make the product. These leaders

would take the information from the brief they received and break it into

specialized information that is needed for their teams to create the product. The

last smaller teams will only have information that is relevant to their fields and

would not have the outlines for the other groups, (Lencioni, 2016).

This can cause issues when trying to make each group coherent in what

they create. This passing down of information from one group to the next is

much like the chain network but the information is split up between the

specialized groups. This pass however, does still act like Chinse Whispers;

information is diluted and altered as it is moved between the groups. With this
 35

alteration of information, there will be a loss of quality. Much like the chain

network, the communication between the groups will have to be closely watched

to make sure there is coherence between all the groups work. To make this type

of structure work successfully and effectively, each brief must be checked for

understanding and have all of the information needed for the groups below. This

will become increasingly difficult the larger the company and the more briefs

that will need to be given. The more members in a company, the more

hierarchies exist for information to cascade through. This increases the risk of

losing information, misunderstandings and alterations of the original game idea.

Smaller companies with fewer members and fewer groups; meaning, they will

have less complications and less dilution of information because of the fewer

number of briefs required.

 36

Flat Network

The next structure discussed is not on Pettingers chart, (Table 1, 2001). Called

the Flat management structure, this style of management is very much like the

cascade structure but with very few levels. At the top is the director of the

company or project. Below this figure are the managers followed by all of the

other employees, (Figure 3, Learnmanagement2.com, no date). There can be as

few as two levels to this structure, as opposed to the four or five found in the

cascade network.

Figure 3, Flat Organizational Structure, (Learnmanagement2.com, no date)

The theory behind this structure is that, with limited management, the creative

employees will have the freedom to create their best work and the liberty to

communicate with anyone else in the company. In practice, this structure only

works on small-scale companies, or around twenty employees. When the

company gets too large, about 300 employees according to Ellsworth, (Sinclair,

2013), flat networks break down a great deal. In an interview with engineer Jeri

Ellsworth, a former employee of Valve, said that this structure works very well

in the small teams that produced prototypes but broke down tremendously as
 37

more individuals were introduced, (Sinclair, 2013). Another big problem

Ellsworth describes happening is Elitist groups started to form in Valve. The

lack, or in this case a structured form of less management, allows for popular

employees to have more pull in decision-making and results in a hierarchy of

power that, felt a lot like high school. says Ellsworth. She also says that this

type of management in such a large company hinders communication among

employees,

Ellsworth said that there were resources within Valve that weren't being
used, but she had no way to tap into them because there was no
management layer to coordinate things. With no management in place to
address employee complaints, she wound up trying to recruit people
from within the company.

This lack of communication is acknowledged in the Valve Handbook under their

section, What Is Valve Not Good At. Ellsworth says that she does have some

bitterness working with Valve because she could not see any way of actually

making hardware inside that company because of its current management

structure. Flat management is a good structure for smaller companies or teams

of people but for larger teams such as Valves estimated 330 employees, (Valve

Corporation, 2016), this structure breaks down in many key aspects, including

communication, power hierarchies, and allocation of resources. These important

areas can prevent projects from being completed, missed deadlines, over-budget

games, and a lack of enthusiasm in the company. Without these areas, it can also

cause friction between employees such as what was felt by Ellsworth.

 38

This network, along with the others, can be combined to improve and

change the nuances of communication between employees at different levels of

the hierarchy. For instance, the complex decentralised network, which allows all

information to flow information freely, complements the flat structure perfectly;

the formers relaxed environment works well with the latter because of the fewer

management layers. This is a complementary network because it calls for a

relaxed environment when it comes to sharing information just like the flat

structure that has very few managers and few layers of management.

Additionally, the briefing network can be combined to great effect with the flat

network and/or the complex decentralised network, as the relatively few levels

found in the flat network can deliver briefs directly to the employees developing

the product. This is similar to a chain network or the game Chinese Whispers but

with few levels for the brief to pass through before it gets to the developers the

less deformation. Developers are also able to direct their question to

management without having to work through multiple levels; again, decreasing

the risk of distortion or misinterpretation of information.

 39

Matrix Structure

A matrix structure is a combination of two or more different networks that

attempt to overcome their individual inadequacies, as stated in Encylopedia.com

(2009) a site dedicated to management terminology. This network allows

companies to employ several structures to take advantage of their benefits and

hopefully mitigate their disadvantages they have when used separately. Some of

the advantages of using a matrix system are; decentralised decision-making,

strong product/project co-ordination, improved environmental monitoring, fast

response to change, flexible use of resources, and efficient use of support

systems, (Chand, 2016). The matrix network allows groups to cross-

communicate through their managers allowing for greater communication and

co-ordination. It also allows teams to be flexible on their work and the resources

each team uses at a time. This freedom of work on what needs to be done and

use what they need to produce their current work allows developers to use their

time efficiently. The company may also employ different networks at different

stages of development. At a prototyping stage, they can use a flat management

structure for the whole company; but after they enter a development stage, they

can morph the company into a decentralised network allowing for benefits from

both structures to be used.

 40

Chand (2016) also outlines five disadvantages that can occur in a matrix

structure. They are; high administration cost, potential confusion over authority

and responsibility, high prospects of conflict, overemphasis on group decision-

making, and excessive focus on internal relations. If lines of communication are

kept effective and efficient than most of these disadvantages will not exist in the

network. Because employees are working with multiple managerial structures,

conflicts of authority may arise with regards of who to report. This can be

avoided as long as everyone knows their direct manager and only reports to

them. A typical matrix network has a function manager and project manager

each with his or her own respective jobs. The functional manager is in charge of

the supplies and resources the company needs and uses during development and

the project manager are in charge of the groups of developers that are designing

the game, (Chand, 2016). The high administration cost comes from the extra

managers in this network. The problem that occurs with high cost is when times

of financial downside come along and cutbacks need to be made. Davis and

Lawrence (1978) suggest the way to prevent this is by planning and preparing

for budget cuts and adjusting management structures or attempting to obtain

more contracts.

The structures discussed above are the main frameworks used when

setting up communication networks between teams of people. While the most

common structures have been outlined, there are still many possible

combinations; each network can change and improve the dynamics of

 41

communication. Many companies today use a matrix network in order to keep

workflow, communication, information exchange, and updates efficient and

easy which in turn increases productivity, (Sun, 2016). This ease of

communication decreases the amount of stress of everyone working on the

game, documentation, or in management position within the company.

When forming a structure of communication between people there needs

to be trial and error when testing because not everyone communicates or

receives information in the same way. If the network is flexible and robust, in

that it can support all of the information being transferred between groups, then

there will fewer issues with miscommunication, information loss, and reduced

quality. In the end, choosing and implementing the correct communication

network leas to a better overall product and a more enthusiastic team.

 42

Chapter 2: Iterative Design

What is Iterative Design?

Iterative design is a design methodology based on a cyclic process of

prototyping, testing, analyzing, and refining a work in progress. In
iterative design, interaction with the designed system is used as a form of
research for informing and evolving a project, as successive versions, or
iterations of a design are implemented.
(Zimmerman, 2003)

Iterative development is a method teams employ to create measurable progress

on a project. The method includes several steps that are repeated through the

projects life. The main steps that the teams will go through are planning,

prototyping, testing, analysing data, improving workflow, and refining the

product, (Donald, 2013). Kevin Tate refers to this method as the plan a little, do

a little, learn a little (2006) method. At the end of each cycle, various people

such as other developers, stakeholders, and game testers test the prototype.

Martian Onions (2017) stated that as a project manager he liked to sit down and

play the game being developed to understand what the game currently was and

where it was headed. He would test the maps, the mechanics, feel if the art

belonged in that area and get a feel for the environment. The data collected

allows developers to reprioritize work that needs to be done and minimize

wasted work. These short-term iterations makes changing priorities easy and

lightweight. Feedback from the testers allows developers to accurately agree

 43

what features need to be added next or what fixes need to happen. Iterative

design is a methodology that fits very well into management methodologies.

Many developers consider iterative design as the keystone for game

development, (Zimmerman, 2003). The iterative design method enables

developers to re-work previously created content, which yields a greater quality

of game. The management methodologies that will be discussed latter facilitate

the iterative method.

The methodologies that will be discussed below Agile, Scrum, DSDM,

and Cabal are all tools to foster iterative design methods. These methods were

created for software development and focus on the iterative cycle. The iterative

cycle builds upon a base functionality of a product while simultaneously

releasing updates of their base product to improve it while keeping customers

interested and using their software. This is particularly relevant in early access

products with a long life cycle where developers attempt to maintain early user

engagement through introducing new features. Iterative design is extremely

useful in game development because of its creative and test-heavy nature.

Scrum, DSDM, and Cabal rely on a team developing the initial base functions of

any software. After the initial functions are prototyped, they are then tested to

look for any bugs or faults. Once the game-breaking bugs are fixed, the

version is released and a new iterative cycle begins. After a few of these cycles

have been completed and the major functions designed, tested, and released,
 44

secondary functions that are not vital to the game are then developed and tested

following the same iterative design process.

Ian Schreiber (2009) states that, Historically, the first design

methodology was known as the waterfall method, which follows a linear

developmental cycle, much like how water in a waterfall can only go one way,

down. Schreiber discusses how, in a waterfall system, there are no opportunities

to go back and fix mistakes or add features; the waterfall methodology just did

not allow it. Waterfall follows five main stepping-stones from conception to

developing and then onto releasing the project: Start, Design, Implement, Post-

production, and End, (Figure 4, Manning, no date). This method is less effective

because it makes it extremely difficult to go back and make changes to the

software. It also does not work well with a project that evolves with time,

(ISTQB Exam Certification, 2016). Games evolve throughout their creation and

need to be tested during development and these reasons alone make waterfall a

poor choice design method. However, the iterative design process adds a step

that allows development teams to evaluate when and if they need to fix bugs,

add new features, or rethink aspects of the game, (Figure 5, Manning, no date).
 45

Figure 4, Waterfall Method, (Manning, no date)

Figure 5, Iterative Design Method, (Manning, no date)

 46

The one downside to this iterative process is that it takes time to playtest

and evaluate each iteration of digital games. However, the time-cost of coding,

testing the code, then fixing, changing and adding, is offset by the benefits of

better, more polished artefact. In this paper From Waterfall to Iterative

Development A Challenging Transition for Project Managers, (2001),

Philippe Kruchten outlines eight advantages that the iterative process brings to

game development,

Serious misunderstandings are made evident early in the lifecycle, when

it's possible to react to them.

It enables and encourages user feedback, so as to elicit the system's real

requirements.

The development team is forced to focus on those issues that are most
critical to the project, and team members are shielded from those issues
that distract them from the project's real risks.

Continuous, iterative testing enables an objective assessment of the

project's status.

Inconsistencies among requirements, designs, and implementations are

detected early.

The workload of the team, especially the testing team, is spread out more
evenly throughout the lifecycle.

This approach enables the team to leverage lessons learned, and

therefore to continuously improve the process.

Stakeholders in the project can be given concrete evidence of the

project's status throughout the lifecycle.

(Kruchten, 2001)
 47

The game company that doesnt follow an iterative process instead needs

to begin with an extensive and comprehensive design document outlining every

part of the game, including mechanics, story, art, level design, and audio. Teams

operating under a non-iterative cycle follow the design document as closely as

they can, starting at the beginning of the document and working their way to the

end, not necessarily focussing on the more important features first. It is possible

for the product to be far off from the desired item because the non-iterative cycle

does not allow room for the product to evolve naturally from the development

process. On the other hand, an iterative course allows the development team to

read the document, make a list of features and begin with the most important

ones. Time is allowed for the testing of each prototype, ensuring functionality

and a lack of game-breaking bugs. As prototypes are tested and deemed

functional, the teams will work their way down the list of features, making and

testing each prototype as needed. This continues until the list is completed or the

deadline or budget is reached.

A key part of this process is that each prototype is tested, and improved

upon so later prototypes are better than the previous version. These prototypes

are referred to as Vertical Slices, being defined as a fragment of the overall

game that can be experienced and run from start to finish by play testers,

developers, or the public, (What Games Are, no date). When each section is

completed it will be shipped, or allow the consumers access, so the teams can

move on to the next selection of features. The prototypes need to be playable

 48

so the teams do not focus their efforts on continuous patches or fixes. This

uninterrupted cycle fosters creativity as well as stability. While the initial

prototypes are not perfect, they are functional and stable enough for release.

Kruchten, (2001) gives examples of three categories relating to changes

in an iterative cycle. These changes are needed due to issues that arise in

development that can ruin the game. These categories are changes in

requirements, tactical changes, and technological changes. The first category,

changes in requirements, refers to any change during development that alters

mechanics, art, audio, story, etc. Essentially, changes in requirements includes

anything that affects the games requirements before it can be considered for

release. This is the most common area in which changes will occur. The second

category, tactical changes, refers to changes performed in order to release before

a competitor to match or release before a competitor does. Tactical changes can

also refer to an alteration in the management structures that are causing

problems with interactions or team members. The last type of change,

technological changes, denotes any change in the technology used to develop the

game. This can range from the platform the game is being release on, specs

needed to run the game, or software used in development. Changes in this

category should be avoided during construction of a game to mitigate risk, time

lost in transition, and implementing fixes from one technology to another.

 49

Chapter 3: Project Management

Methodologies

What are Management Methodologies Relating to Game Development?

Project Management, a management structure that is formed around the idea of

specifically managing a team working towards a common goal, is a formal

structure which companies use to outline how teams of people will work

together and the steps or principles that should be followed when creating a

product, (Haughey, no date). These principles comprise of simple structures,

which can be followed in order for creative teams to work freely while also

ensuring customer satisfaction, high team enthusiasm, and an efficient work

place. There are many methodologies out there, but they all follow the same

basic principles. These methods act as a constant reminder to teams of the next

step in development, be it coding, testing, reporting to managers or to the client,

or releasing an alpha build of the software. Management structures help to keep

teams working on schedule as well as in budget, while at the same time keeping

enthusiasm and work efficiency high throughout the development cycle.

 50

As the arena of game development has progressed, many different and

effective methods have been established, including Agile, DSDM, (Driving

Strategy Delivering More), Scrum, and Cabal. All of these use the same basic

principles. These principles are, they all aim towards the same goal of delivering

software, or games in this respect, on schedule, within budget, with customer

satisfaction, while keeping highly efficient and enthusiastic teams, and are

supportive of iterative design. Agile provides a comprehensive team

management structure while also working very efficiently with DSDM, Scrum,

and Cabal that provide the all-important iterative design process, which games

are developed around. These methods also have differences but will be

discussed later in this chapter.

Agile

Agile is a production framework used to oversee teams of people working in an

IT or creative field in an effective and flexible manner, (What Is Agile Software

Development? - Agile Alliance, 2016). It came about when software firms were

under a lot of pressure to deliver products on time and within budget, however,

they were consistently running over-time and way over-budget. It was formed as

a new and unique way to manage IT teams that would inspire, enthuse and

capture the creativity of the employees. Agile is merely a framework to allow

teams to effectively communicate, share work, report on progress and find

 51

creative ways to overcome challenges during development. This approach

encourages freethinking and creative solutions for problems as well as constant

iterations of work. Iteration always improves upon what is needed in a piece of

software and always allows changes to be made that are necessary that allows a

product to evolve and grow. It encourages constant criticism towards the main

features of any software and asks developers, Is this feature crucial, if not then

what is? This allows features to be prioritized based on importance, keeping the

teams on track and efficient.

The management structure associated with Agile is a non-hierarchical

one, which allows the team members to be open with one another and free-

flowing information during development cycles. This also fosters greater

teamwork and high efficiency, as there are no power struggles between

members. There are however, managers of the teams that hand out briefs and

check up on progress. They do not interfere with development, instead acting to

ensure the product is on schedule and within budget. Additionally, their role is

to provide the teams with everything they need to develop software efficiently,

(James, M. no date).
 52

Four Values of Agile

Agile is comprised of a Manifesto, (Beck et al.), created on February 11-13

2001, which lists four important values and twelve key principles of project

management. Seventeen people that represented different aspects of

management, from Extreme Programming, Scrum, DSDM, Adaptive Software

Development, Crystal, Feature-Driven Development, and Pragmatic

Programming, created the Manifesto. The primary reason they met to design this

Manifesto was to restore the word methodology in the IT and software

development community to what it once represented (Beck et al. 2001).

Denning (2010) discusses reinventing management in the modern times

and analysed the breakdown in managerial structures and what was done to

resolve the issues. He gives the example of how a military general managers

both troops and civilians. Military personal are managed with a strict line of

communication and orders, The more disciplined the army, the more successful

it was. The communications were top down, explicit, and linear. (Denning,

2010). This approach however does not work with civilians. They do not have

the training or discipline needed for such a strict management style. Instead of

making them follow exact orders he gave them rules and procedures to follow to

reach goals and allowed the workers to largely manage themselves within those

rules and procedures. The general found that productivity and safety increased in

the work place. The ability to manage oneself gave each worker personal
 53

responsibility for both success and failure. Agile follows this principle and

supplies the framework for companies to make rules and principles for

employees to follow.

The twelve principles range from client satisfaction, team enthusiasm,

efficiency, and changes in requirements for the software, (Beck et al. 2001).

They form the framework for many other methodologies such as DSDM, Scrum,

and Extreme Programming. They make it clear what developers need to focus

on and allow the teams to decide how to best achieve that. While not every team

needs to use this framework, it is advised to use a method such as this while

working in larger groups of people in order to keep everyone moving in the

same direction and on the same page as one another. The Agile method is

adapted to fit each company or group of people individually allowing teams to

create a structure, which works best for their work.

The four Agile Manifest values are:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

(Beck et al. 2001)

 54

These four values outline the twelve principles that make up the manifesto and,

as Carroll and Morris (2015) argue, are ideal for a management methodology in

the creative field. The first value outlines this fact very well: it is all about

communication within the teams and finding solutions that are outside of the

box instead of sticking to processes and tools that are available but ineffective.

This value ensures that creative teams are doing just that: being creative and

working as a team to solve the problems for which conventional methods prove

inadequate. This is particularly useful in the games industry because most game

development teams come across issues with code or game logic that dont work

the way they were intended. Creative solutions are required in order to fix a

buggy mechanic, or a work around is needed in order to make a mechanic

functional.

An example is found in Fallout 3, and Fallout New Vegas, (Whitwam,

2015). When the player needs to get into New Vegas, using the railway system

in the game it looks like the player is actually riding a train into New Vegas.

However, due to limitations of the game engine the player is actually teleported

to under the train and is now wearing the train as a hat. The player is then set on

a path to run with increased speed and the players view angle is altered in order

to look like they are sitting in the train. The trains in all of the Fallout games

that the player can ride are actually hats. On the surface they look like a train,

just setting on tracks but below there is an NPC (non-playable character). When

the player needs to ride the train the camera is switched from the player to the
 55

NPC on a course and with camera, animation can make it look like the player is

riding a train. This is an example of an AAA company using a work around

because their game engine is not set up to include working vehicles like those

that a person would find in a game such as Grand Theft Auto V, (Rockstar

Games, 2013), or Borderlands, (Gearbox Software, 2009).

Working Software over Comprehensive Documentation

The second value Carroll and Morris (2015) talk about is the balance between a

working product(s) over the documentation(s) of a piece of software. This

principle suggests that it is better to have something that works in some fashion

rather than just have a lot of papers that tell the customer or stakeholders how

the product will work. This can speak to the developmental work that is being

put forth into the software. Actual working software also tells people the

developers are working and not just making up useless paperwork that doesnt

do anything; after all, An idea that is developed and put into action is more

important than an idea that exists only as an idea. (Bono, 2016). In the Games

industry, producers, managers and customers want to see how a game is

progressing, all for different reasons.

A producer wants to make sure a game is on time and within budget but

also if they need to increase the deadline or increase the budget. This change in

budget or time can affect how well designed a game turns out to be, the more
 56

pressure on the teams then the more mistakes that can be made. The less time to

develop a game also means the amount of features included in the game need to

be cut back.

A manager needs to see results in order to manage the team and the

workload he or she hands out to the developers. They want to know if an art

team needs more time to get assets together and if level designers can be

working on something else until the assets are completed. They need to manage

all the teams and all the people within the teams. Without actual prototypes or

vertical slices, or a proof of concept, (What Games Are, no date) the managers

will not be able to effectively manage the team as a whole and allow the

developers to make progress in a productive way. Martin Onions (2017), a

developer and game tester in his early career, included checking in on

employees every day as a project manager, later in his career, to play the game

and see how it was progressing and if changes needed to be made to deadlines,

budget, or game features.

 57

Customer Collaboration over Contract Negotiation

The third value is all about involving the customers and keeping them involved

and pleased over contracts and legal issues. This is important in many aspects:

firstly, customers should always come first as they are the ones buying the

product and if they arent pleased, then the software is bad, has too many bugs,

or is difficult to understand and use. If the customer is not buying the product

and the company is not making any money than any contract the companies may

have are useless, especially if it is a contract about the income the software

makes.

In the games industry the customers are strategically involved with the

development of games when it comes to Indie game studies. Hobbyists design

games for themselves, their close friends, family. AAA companies design for a

massive market, which allow them to keep their main design of a game to

themselves for marketing purposes. Indie game studios tend to involve people in

their games from the start because it generates interest, a following, ideas,

feedback, and early income if they release the game on early access. Due to its

small nature, an indie company may not have a publishing company or a

contract to supply funds and equipment but they do have fans and gamers. Fans

can help with developmental ideas, feedback and, in the end, someone to buy the

game and pay for the development.

 58

Klei, the developers of Invi?ible Inc. and Dont Starve, have found great

success in early access. Both games were released in early access and the public

met both with great excitement. Klei kept the public up to date with all changes

being made, and kept in constant contact so there were no periods of the public

of wondering what was going on with development, (Rock Paper Shotgun,

2015). With a positive relationship between a company and the gamer,

companies generate a positive outlook and if they can deliver their games on

time and polished then they can create a positive look that will attract more

clients and may even attract the attention of a publishing firm that will help with

future games.

Responding to Change over Following a Plan

The fourth value is about the developers using their creativity to allow the

software to take them where it needs to go. This change can occur at any time

during development. It can happen by mistake when a bug appears, a new and

un-foreseen feature is created, or by design when a client wants to add, subtract,

or change a feature of element. An example discussed previously that fits this

value is about Martin Onions Director (2017) deciding a game needed to have

werewolves in it, and how the team adapted to this thematic shift. Some changes

allow the project to evolve and grow into something that works, is efficient,

keeps focus and enthusiasm in the team, and keeps the players happy, other can
 59

add complications and extend the life cycle. Even though a plan is good and

prudent to have, it needs to be flexible. If it is a rigid schedule and plan, the team

will lose focus on the product and not be as excited when developing it. The new

changes and challenges that occur during development keep the teams on their

toes in order to come up with creative ways to solve the problem. Most of the

time these problems introduce new mechanics, reveal a larger issue at hand, or

demonstrate that a feature is not needed or has a negative impact.

During game development, from the start to the day the game is released,

the game is in a constant state of flux. The original game design document will

have everything listed out that should be in the game but this document will only

be initial ideas that are believed to work. As development proceeds some ideas

will prove to not fit the design, or cause too many bugs to implement or they

may just be poor design ideas to begin with. Throughout the development cycle,

ideas are taken out, added, or changed based on many variables. Designers need

to be able to work on a mechanic one week but then the next week realise that it

doesnt really add anything to the game. The designer afterwards must be able to

remove it without feeling personally hurt or that their work is being undermined

or unappreciated. The week after that they may realise that a new and different

mechanic may add a completely new and interesting game play experience to

the game that was not conceived of before. After making these discoveries the

design document, which is the plan for the game, will be changed and updated to

remove the old mechanic and add the new mechanic. Other changes may include
 60

a new art or audio theme, or a different narrative to deliver to the player that fits

better with the game play. These changes can and should be made to all aspects

of a game.

Twelve Principles of Agile

[1] Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
[2] Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
[3] Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
[4]Business people and developers must work together daily throughout
the project.
[5] Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
[6] The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
[7] Working software is the primary measure of progress.
[8] Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
[9] Continuous attention to technical excellence and good design
enhances agility.
[10] Simplicity--the art of maximizing the amount of work not done--is
essential.
[11] The best architectures, requirements, and designs emerge from self-
organizing teams.
[12] At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

(Beck et al. 2001)

 61

The four values govern the twelve principles of Agile that can be seen

above. These principles are merely a framework that can be changed, have some

removed, or have others added based on the companys preference while

developing. However, changing and removing principles must be done with

care. Ian Thomas (2017) explained that a small Indie company he worked for, of

about thirty-five employees, cherry picked Agile principles for their structure

and faced many managerial difficulties because they did not carefully consider

each of them. AAA companies would most likely take out principle three,

deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale. They also may find number

six harder to do in having face-to-face conversation as AAA companies tend to

have quite a large workforce and sometimes face-to-face meetings would be too

complicated and end up wasting time instead of saving it, (Valve Corporation,

2012). However, Indie companies may find it more difficult to follow number

nine, as they will have fewer employees working for them. These smaller

companies may have to focus on one aspect of the game instead of all aspects as

all companies want to do. These principles are guidelines to get an organization

moving forward and allow software or games to be produced. As each company

develops and progresses, they will find their own way of doing things efficiently

while still keeping the enthusiasm of their designers.

 62

Our Highest Priority is to satisfy the Customer through Early and Continuous

Delivery of Valuable Software.

The first principle of Agile focuses on the satisfaction of the customer and the

delivery of the software. They say that this is the highest priority because

without customers there would be no software to produce, which means there

would be no business. This principle suggests that one of the main ways to keep

the customers happy is to release valuable product early and continuously

throughout development. It also shows the clients that the company is

progressing in development. It also allows the customers to view how a piece of

software evolves and grows.

In the games industry, communication to clients can be done a few

different ways. The first is to open the game to Alphas and Betas, which allows

the players to download the game and play what has been developed so far.

Alphas and Betas are positive as it acts as a form of early income, allowing

designers to see the level of interest in their game, and allows the public to give

feedback on art and audio styles, game play features, mechanics, and to report

any bugs. Opening to Alphas and Betas and receiving first hand feedback allows

the designers to use their time improving or fixing these mistakes instead of

finding them. The other common way of keeping constant communication is

keeping a regular and constant blog that updates gamers on the progress of the

game. These blogs should include updates of new features added, taken away, or
 63

changes as well as photos of the game and art assets, short clips of the audio

being designed, photos of the actual game levels, and videos showing off game

areas, game play, and core game mechanics. By keeping a blog or releasing

continuous Alpha or Beta updates, the game keeps the interest of fans. These

releases also provide the designers with feedback on which direction the game

should take, which can be used or ignored based on the designers discretion. The

feedback can also gage the publics view and feelings of the game whether

positive or negative.

Welcome Changing Requirements, even late in Development. Agile processes

harness change for the Customers Competitive Advantages.

The second principle of Agile refers to features included in the software or

product. This principle suggests that changes and alterations to the features of

any software are good, no matter when the changes come, early or late. These

changes could come straight from the customer or client or they may come

through testing and de-bugging of the product. Some features may become

irrelevant through development while other new features because major selling

points and core additions. Agile is set up in such a way that enables changes to

occur during development without major time delays or budget increases

because of its flexibility and the four values. It does this through its constant

communication between team members, producers and managers, and the

 64

clients themselves. With this communication between everyone, changes can be

made quickly and efficiently because everyone is on the same page and nothing

is happening un-unexpectedly at the last minute. This principle is essential to the

iterative design process that game developers widely use.

In game development, changes in design happen constantly, as

previously discussed, (Zimmerman, 2003). Core mechanics are replaced; art and

audio styles change, and story or mission layouts are altered. These are all

positive things as it allows the game to grow and mature into a better-designed

and thought-out game. Without changes, the game would stick to a linear

development path, which would most likely follow the original design document

without changes. Developers would be using a waterfall method instead of an

iterative design approach, (Figure 4, Manning, no date). A game using a linear

developmental process would turn out to be a poorly thought out, non-cohesive,

boring and possibly monotonous game. Agile becomes ideal for game

development because change happens so often. By using Agile as a base

methodology, game companies have a management method that takes into

account all the changes; while simultaneously still allowing a company to be

efficient and on budget. Agile accounts for an ever-changing product and is

structured in a way that keeps communication and cooperation open between all

aspects of the development team. This can clearly be seen by the core values of

Agile which keep developers communicating, tell people to expect change, and

always push the software forward instead of focusing on the paperwork.

 65

Paperwork can become a hindrance if it becomes over whelming. Interaction

with the public will drive change as feedback and play testing are recorded.

Several ideas that were not thought of before or not seen can be captured

because of outside eyes, and feedback further enhances the game as a whole.

Clients should be as much a part of development as they can; this is not the case

for many of the larger AAA studios.

Deliver Working Software Frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

The third principle of Agile elaborates on the periods of working software and

when it should be released to the public or individual clients. It suggests a

release of new or updated software from a few weeks to a few months, but

suggests that shorter is preferred. This is a principle as it speaks to the forward

moving and enthusiastic nature Agile brings to teams. If a team is motivated,

enthusiastic and creative then they will work more efficiently on software and

design it in creative ways that may work better than standard by-the-book-

methods. By delivering software or updates in a timely fashion to clients and the

public, they will know that a company is working and does care about its

product. Even if an update is small and only fixes a few of the smaller, less

important issues that currently exist, it tells the clients that work is being done
 66

and progress is being made. This is important in order to keep interest in the

product and to keep clients from moving to a different software.

For most Indie game companies, the developers will keep the public

apprised of all changes made to a game. They can do this through early access

strategies or other means. Developers will also make constant updates that fix

bugs that either were not found in play testing or that have arisen due to the last

update. If the game is in an Alpha or Beta, then the developers may create a

roadmap for the public to watch. Wube Software LTD., creators of Factorio, has

a roadmap on their page that states what features they are working on and when

they plan to have them done, (Forums.factorio.com, 2016). This is a very good

way of including the public and keeping them in the loop of development. It also

allows people to see if there is a large update coming that will take longer to

prepare than ones before. This way the public will not be surprised when a

longer amount of time passes without an update. The roadmap is also just a

guideline as new issues will inevitably arise with each update delivered and new

bugs are found. It is common that half way through a road map, the developers

push all future updates back a week or two in order to do a maintenance patch

that will clear up new issues. This is a very positive way to keep public interest.

AAA companies will do this differently as millions of people around the

world are most likely playing their games. They will usually release a game and

let people play for a couple of months, all the time gathering feedback from sites
 67

such as YouTube, forums, or other media that they can use as play testing.

Developers can then see if people come across any bugs that in-house

playtesting missed. The mass playtesting that happens around the world allows

AAA companies to make updates that can cover a wide range of problems from

graphical issues, gameplay bugs, coding problems, system compatibility

breakdowns, or broken features. AAA companies will release a few large

updates covering as many issues as they can. After these updates they will most

likely start to release extra content (DLC, or downloadable content) and add to

the games experience; but as these are released, the process of playtesting and

patching starts all over again. These large companies do not have any sort of

roadmap or interaction with the public because they make so much money and

do not need to try to keep interest in the game.

 68

Business people and developers must work together daily throughout the

project.

Agiles fourth principle is about communication and teamwork between the

developers and the managers or business people that are related to the software.

This is important because the business side of software keeps the capital coming

in as well as the products being sold. They also make sure that the developers

have all of the equipment needed in order to make the product. With the

equipment, the mangers also have to provide the software that is capable of

doing what is needed in order to market it effectively. Without this line of

constant communication then all sorts of breakdowns can come along that would

affect the development and sales of a product. The main issue is that the

business people do not know what the software can do. If they do not know that

then they cannot market it in the right way to the right people and thus cut into

the profits that could be made. The other issues involve getting the developers

the right equipment for the development. Without that then the developers will

have a more difficult time creating the software, testing or packaging it, which

wastes time and cuts into profits again.

When it comes to game developers communicating with the business

side of the games industry there are many of the same positives and negatives.

The first one being marketing, if the business people know the game, the

mechanics, art style, and story then they will be able to find the more effective
 69

target groups. They will be able to focus their sales, whether it be young, older,

mature, sports, RPG (role-playing game) groups, puzzle, or other groups. The

other positive or negative thing is the equipment or software available to the

developers. If the developers have all the software they need they can effectively

create the game and design it well. Without the proper software, they may need

to use work arounds that are buggy and glichy that cut into the game play and

pull the player out of the experience of the game. The business people can also

make suggestions based on public feedback on which way the game should go.

There are times that the public want games that focus on certain genres much

like music. One season can be space and sci-fi and another season it can be all

about the pirates. All of these positives and negatives will make it easier or more

difficult for the business people to market and sell the game effectively to a wide

range of people. The better designed a game is and the more well informed

every member of the market group is, the more sales that can potentially be

made. Communication is key between all groups of a design and business group.

The transfer of information is key when developing and selling a product.

 70

Build projects around motivated individuals. Give them the environment and

support they need, and trust them to get the job done.

The fifth principle of Agile is about making the right environment with the right

motivated people on a team with the right support in order to make a piece of

software effectively and efficiently. For a creative team to work efficiently they

need to be motivated to do-good work and this motivation can come from a

variety of different things. Carroll and Morris (2015) outline these needs and

other suggestions to keep motivation that include: team meetings, proactive

development, well planned workshops, stable team members, and others. To

take these needs a step further, first in order to work their creative magic they

need to have the freedom to be creative. Employees will need a management

structure that allows that to happen instead of hindering it and holding them

back. They then must have a project that motivates them to work and be creative

in its design and development to work around problems that pop up and arise.

To create software they also need the equipment, tools, support, and goals that

lead to a finished project, without the proper tools they cannot make anything.

The hardest thing to provide for them is the proper environment. As everyone

works in different ways, it is difficult to please everyone. Some members may

work best with noise and things going on around them while others need

complete silence in order to focus. Some work best in groups and others work

best alone. While not all needs can be met at once, office space can be set up in

an intelligent manner. There can be sections that are dedicated quiet area to
 71

concentrate and work and there can be another area for group projects and

collaboration. There should also be a loose dress code for an office. Some

people find it easier to work when they are relaxed and do not have to wear a

business suit everyday while others like the professional feel a suit can give.

These are all things that need to be tested and changed to see what works best

for the team.

In AAA game design industries there are several ways to set up an

office. One of the more common ways that is emerging now is system in which

everyones desk is on wheels and can be pushed around the office to work with

whomever they need to at that given point in development. Leo Kelion (2013), a

Technology reporter for the BBC, interviewed DJ Powers about Valve and how

they make it easy for employees to move around the office. This mobility allows

employees to work with anyone they want to on any project they want to, DJ

Powers says this about the system and ability to do this,

"We move around a lot and we don't want it to take a lot of time to do
that
"We form into teams based on need to complete a feature or complete a
game, and then we disperse into new teams.

"The ability to be able to pick up and move and be in another office in 20

minutes as opposed to a day-and-a-half is really attractive

"I've moved my desk probably 10 times in three years.

"You just wheel it out of the office and into the freight elevator and go
up to whichever floor you need."
 72

This flexibility and mobility allows the work to flow naturally and gives the

designers freedom to move around to make their current work more effective. It

also takes less time to ask a fellow designer about something if they are right

next to you than searching around looking for them. In smaller companies, this

is less of an issue as there are fewer employees, so everyone can work next to

everyone and communication is a lot tighter and cleaner. When it comes to small

hobbyists teams, they would largely work on the game in their homes where

they are comfortable and relaxed which would result in their best work. The

larger the company and game then the more difficult it is to provide everyone

with an ideal working environment.

The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation.

The sixth principle of Agile Development is about effective communication

within a development team. The best way to communicate effectively between

people is to discuss topics face-to-face, (Goman, 2016). When sending memos,

messages, or letters, issues and details can get lost in translation. The loss of

understanding comes from either the way it was written or the way it was read.

Not only can understanding be lost due to sentence structure and word choice

but a person reading a message cannot know of the tone it was said in, (Segal et

al., 2016). The tone in which something is said conveys a lot of the meaning.
 73

Rami Ismail of Vlambeer (2014) gave a presentation where he asked the

audience to give responses to words. For example He said sun, the next person

said moon, and then stars and so on. His point was that while playing this game

it is very unlikely that two people say the same words because people hear the

same word but interpret it differently. Rami Ismail then goes on to ask the

audience what they think of when he says platform. He asked who thought of

3D side scrolling platformer, top-down platformer and then goes on to say that

the word platformer means nothing by itself. While designing and developing

games communication is key which makes these key words, phrases, or

sentences have the same and correct meaning to all members of the team,

(Ismail, 2014).

In a face-to-face meeting about a piece of software a topic can be

discussed in more detail with more clarity, questions can be asked and answered

immediately, and if something is misunderstood than clarity can be given. This

face-to-face does not just extend to internal team members but also to managers.

If something needs to be done or addressed in a piece of software that

information should be presented and given back to developers in a face-to-face

meeting. This will clarify the issues to the managers as well as the designers,

where it can be found, how it can be triggered, and potential solutions. This

meeting will also allow time to be spent discussing the potential solutions.
 74

This is the same for game development; when bugs are found it is better

to talk about them face-to-face where they can be discussed and hopefully

resolved. Same with software this does not just extend to the designers. Face-to-

face meetings are also important for the managers of the game project and the

producers. If the producers are not happy with the path the game is taking, it is

best to tell the managers the course they want it to take. This will allow the

managers to contact the right designers for the changes. The same can be said in

reverse, if a designer or manager does not like a certain aspect of the game or

where the game is going. It is best to discuss these issues in person to the

producers to try to find a resolution everyone is pleased with but more

importantly improves the game as a whole.

As a project manager for a small Indie company of about seventeen

people, Martin Onions (2017), made sure that in his day-to-day undertakings, he

talked to all developers to check their progress as well as how they were doing

in the company. He was able to find out about most problems in the game from

the developers themselves and find possible fixes in the next Scrum meetings.

Communication in any project, either software or game design, is the best way

to ensure everyone understands what needs to be done. Meetings give direction

the product is heading and is best to have regular meetings face-to-face to

discuss issues, clarify misunderstandings and give direction for the developers.
 75

Working software is the primary measure of progress.

The seventh principle is straightforward: How is progress measured? Agile

suggest that it be measured by the amount of functional software that has been

made. This does not mean that the progress measured has to be a huge part of

the core software but any amount of working software is progress. Development

teams can document and write ideas down all they want but this is not physical

progress on the software and does not contribute immediately to the product. If

working software is available to managers and test teams then feedback can be

given to the developers on which direction they should take. Where only

documentation exists, the changes planned to be made to the software can only

be theoretical instead of practical and cannot be tested. As more testing is done

on any piece of software, progress can be made and positive changes made.

This is the exact same in game development. If there are mechanics to

test or assets to look at, alterations and feedback can be given to improve them.

The main point of a game is to have fun. The best way to test if a game is fun

is to playtest the game and to playtest it for fun, (Ambinder, 2009). There are

several ways in which to playtest. The two that will be looked at in this paper

are internal and external. Internal is when a company has hired people in the

specific role of game tester to test for fun, bugs, and balance. This is done in

order to keep a game undisclosed from the public but it is more difficult to test if

a game is fun, as the testers are professional game testers. The second way,
 76

external, involves companies, particularly Indie, gathering members of the

public up to play their game or section of game. This allows for a wider range of

gamers to play their product and give feedback. This is great for testing if the

game is fun.

While playtesting, several things should happen. A member from the

development team should be watching but not interfering or creating a false play

experience. Designers should keep an eye out for bugs encountered, issues with

the art or audio, and listen to what the player is saying while playing. As a

person plays a game, they say what they are thinking and this gives insight as to

their though process and how they are reacting or solving an issue. The point of

a designer watching the play tester is to take note of all the subtle things that the

tester does while playing the game, (St. John, 2013). This gives the designers

genuine responses and results but, because they are observed, there can be errors

when interpreting the data. The best way to combat this error is to have a

questionnaire that asks specific, while not leading, questions about their

experience and thoughts on the game, (St. John, 2013). These can be multiple

choice or circle as many as possible or even a rate on a scale from 1-10 which

can lead to generic answers. Alternatively, there can be sections where they can

type out their answers and give in depth feedback.

 77

Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.

The eighth principle is all about sustaining the practice of Agile in the

workplace so development never has to stop and the designers are not burnt out

or lose enthusiasm for the project. This is known as sustainable development.

Sustainable development is a mind-set (principles) and accompanying set of

principles that enable a team to achieve and maintain an optimal development

pace indefinitely, (Tate, 2006). This is easier said than done as the longer a

project goes on, the harder it will be to keep focus and enthusiasm for a project.

At the start of any project enthusiasm and focus is high as the idea is new and

fresh and everyone has creative and game changing ideas that they all want to

put into the game or software. After core mechanics, art, and a design have been

decided and is in place then a pace can be set for the team to produce the game.

However, after a while this pace can become tiresome and boring. Long work

hours can also degrade morale and enthusiasm for a project.

Agile promotes a constant flow of communication between everyone

developing and managing the project as well as the use of meetings and

collaborating projects to keep enthusiasm and focus high. With these meetings,

everything about a project can be discussed from progress issues, possible new

features, or things that need to be removed. These meetings can provide

solutions for issues that are plaguing the project. These meetings will provide
 78

designers with several ways to creatively approach an issue which will help keep

interest in keeping the work going forward.

Another thing that can help keep focus on a project is short-term goals

and deadlines. There is ultimately a long-term deadline where the software or

game will be realised. However, with short-term goals, designers will always

have something immediate to work on. Bachan Anand (2011) discusses setting

short-term goals and letting game designers get on with their work managers

also show trust that they will get the work done and do it well.

Bachan Anand, (2011) also discusses the manner in which giving

designers trust and a challenging project will encourage them to do their best

work. Along these lines, positive feedback and appreciation for their work also

helps keep focus and enthusiasm on project because everyone likes to hear that

they are doing a good job. If something is challenging but not too challenging it

can lead to them learning new skills and testing the skills that they already have.

When a new skill is learned, there is always a sense of achievement. This feeling

of accomplishment is then translated to goals being reached or challenges being

overcome.
 79

Continuous attention to technical excellence and good design enhances agility.

The ninth principle of Agile focuses on the quality of product. Since all

companies main goal is to make a profit and sell their products, (Denning,

2011) they must ensure that they are producing the best possible quality of good.

This process can also be known as achieving technical excellence. Technical

excellence is the ability to engineer products that are superior to anothers

products. Scolese (2006), Senior NASA Headquarters Manager, outlines four

guiding principles to reaching technical excellence:

Clearly Documented Policies and Procedures

Effective Training and Development

Engineering Excellence

Continuous Communications

These four principles can easily be applied to game development with some

exceptions. The first principle states that there needs to be policies and

procedures in place for employees. Policies and procedures are a set of rules and

principles that organizations use to reach long-term goals. These rules would be

published in a booklet or document that are readily available to all employees,

(Luthra, 2016).

Effective training and development can happen in two ways. It can be

either internal training or external, (Panagiotakopoulos A. 2009). Internal

training start with induction at a new company by helping new employees learn
 80

what is to be expected of them and the policies and procedures the company

uses. In-house training also occurs throughout a project. As a game develops,

employees will work with each other learning from and teaching each other

techniques and skills, (Harrison, 2002). External training happens when a

company brings in new technology or new hardware that current employees do

not know how to work, (Panagiotakopoulos A. 2009). When new hardware or

technology is brought in developers from the company will hold training

sessions to teach a number of employees about the new equipment. By training

just a few employees on new equipment, they will in turn be able to train other

employees, passing on their knowledge. By allowing employees to rotate jobs,

they are able to learn a wide variety of skill and contribute more to projects.

Engineering excellence is the ability to create a product through

mathematical or scientific means that is superior in all regards, (Gill and

Vaughan 2006). Gill and Vaughan also argue that engineering excellence is

associated with the management of human resources within an organization.

They quoted that the excellence of the workforce is critical to the safety of

NASAs missions, (NASA Directive, 2005). In game development, it is

important to both manage the quality of product being created and the

effectiveness of the employees.

Communication in a group of people with a common goal is essential.

Communication allows all information to flow pertaining to the project.

 81

Constant communication ensures that all members of a team know what to do

next. Communication also guarantees everyone knows what everyone else is

doing which can help improve efficiency.

All four of these principles play an integral part in achieving technical

excellence. They each contribute a key part to help a teamwork together

smoothly. According to Scolese (2006), two sets of roles and capabilities

accompany these four principles when trying to achieve technical excellence.

These two roles are:

(1) Personal accountability where by each individual must understand

and believe that he or she is responsible for the success of the Agencys

mission and (2) Organizational responsibility to provide the proper

training, tools, and environment.

These two roles between employees and the organization make sure that

responsibility is shared. Employees must have personal accountability for the

work that they are doing and take responsibility for their work. The company is

responsible for supplying training, supplies, and environment for the employees

to work.

By demanding this high quality right from the start of any product,

designers should get into the habit of always giving their best efforts in

producing their finest work. As developers gain more experience, this workflow

of high quality will become natural to them and allow them to produce more
 82

work at either the same quality level or higher, consistently. This allows

designers to be very agile in the way that they work and permits them to

experiment with techniques and new software or technologies without

compromising their speed or quality.

Simplicitythe art of maximizing the amount of work not doneis essential.

The tenth principle of Agile is about maximizing time allowed for development

as well as efficiently using the time a team does have. If a team knows that a

feature or a piece of code will not work or can be replaced by a better or

improved feature of piece of code, they should skip to the better version right

away. If a team can skip a step without compromising stability or quality then it

should be done but only if it can be done safely. In game design, a mechanic that

is originally thought of as a great idea but later becomes apparent is not, should

be cut from the game immediately. This cut can save testing time in the future.

Some mechanics need to be tested in order to gain an idea if it will work or not

with the rest of the game. If it does, then continue with development; if it does

not, then cut it immediately and shift the focus to something productive. Agile

calls this process of deciding what is important and what is not MoSCoW, which

stands for, Must have, Should have, Could have, and Wont have this time,

(Carroll and Morris, 2015).

 83

With learning what not to do, there is learning to do things as simply as

possible. Simple is easy and safe; there is no point in making a system overly

complicated and a mess. If it is complicated then there is a greater chance of

something going wrong and needing additional work and focus to fix and

stabilize. While designing any game it is far better to make mechanics, art, etc.,

as simply as possible to save time, space (bytes), expenses, and stress,

(Shiralige, no date). Working hard is not necessarily working smart. It is better

to have a semi-functional yet stable prototype than a buggy, complicated

finished product that is not reliable. Keep design simple.

 84

The best architectures, requirements, and designs emerge from selforganizing

teams.

The eleventh principle is focused on the team aspect of companies and states

that self-organizing teams are ideal for companies that use Agile. The strength in

a self-organizing team comes from its ability and enthusiasm to work together

and use their creativity to imagine, design, and build the best work possible.

Self-organizing teams have the option of moving people around into different

teams as they see fit. If one team has too many artists and another has too many

coders then they can move people around so each team has the best composition

for that point in development. With a wide range of various skills and

personalities, each member offers a different viewpoint and perspective on the

design that is currently being developed. With these many different perspectives,

Figure 6, Tribes, Squads, Chapters & Guilds, Kniberg and Ivarsson, (2012)
 85

others can bring many things unseen to light. These unseen things can alter any

design greatly, either adding features or avoiding potential issues that will hinder

progress.

The development team at Spotify has a very interesting and complex

way of handling their teams, but it is effective, (Kniberg and Ivarsson, 2012).

Their teams are comprised of tribes, squads, guides, and chapters each with their

own roles and responsibilities, as shown in figure 6.

A squad is a self-organizing team with all of the skills and tools to design

and develop a part of a system in the overall product. Each squad has their own

individual part to develop within a certain field like coding, art, or audio design.

They also decide on the best way to manage themselves, as well as distribute

workloads and how to communicate with each other. Squads do not have

designated leaders but they do have a product owner. The product owner

collaborates with the other owners to make sure their work is coherent and is not

overlapping with what other squads are working on, (Kniberg and Ivarsson,

2012).

A tribe is a composition of several squads all in the same field, like

coding or art, but each tribe has a different focus than the others; one tribe would

be in charge of the coding and another in charge of the art. Tribes meet regularly

to talk about progress that is and is not related to the product, to share skills, and

new learning opportunities. The problem with this autonomy is still a lack of
 86

communication between squads and tribes. This is where the chapters and guilds

come into play.

A chapter consists of every member from a specific area, coding, art, etc.

across all squads and all tribes. They have regular meetings where they discuss

their work, issues, and work arounds or fixes. This keeps all members of the

same field in communication so if squad A found one bug but the fix was

discovered by squad B then this fix can be communicated to every other squad.

This chapter system ensures communication flows freely throughout the

company, keeping every member of a field effective.

The guilds work differently. Guilds consist of a guild coordinator to plan

meet ups and keeps things in order. Guilds work more organically than the

others do as they span the company as a whole. There are no specific fields

required to show up at the meetings; anyone and everyone in the company is

welcome to the meetings. Guild meet ups may be geared towards one specific

task such as coding or art but anyone can join a guild. This allows members to

keep learning new skills and stay up to date with development in other areas of

the product.

Spotifys structure allows teams to be self-organised in a way that each

squad has the composition they need. Tribes are similar in their structure as

squads. This structure also keeps the squads and tribes in constant
 87

communication with each other through the chapters. The guilds provide

communication between squads, tribes and chapters as a whole.

At regular intervals, the team reflects on how to become more effective, then

tunes and adjusts its behaviour accordingly.

The last principle is about reflecting on how the management structure worked

during the development of the software. This principle should be examined

several times during the production and, more importantly, altered to be more

effective. This process must happen at several stages during a game or software

because as the game evolves and grows so should a team and the way they

manage themselves and the project as a whole. While being in a creative

industry, both management structure and developmental processes need to be

flexible with the team and the project. Martian Onions (2017) explained how a

small Indie company he was working for had to change from a developmental

company to a publishing company because they did not evolve their methods.

They changed because, as he stated, was less work for the employees.

The first time this reflection process should take place is when the team

is at the very start of development and is out of the idea-gathering phase. They

should analyse how the ideas were developed and created and ask if there are

better ideas still out there or if some need to be culled. Reflection should

examine if they spent their time efficiently while in this initial idea phase. The
 88

next few times should be during development as each milestone is reached, such

as when core mechanics being designed and tested, when art and audio styles are

decided, and when the story is in its initial development. The last few stages of

reflections should take place towards the end of development to analyse how the

whole process was carried out and what could be done better for the next

project. Questions that should be asked are: Was our time used effectively? Did

we create un-needed features? Were we too ambitious or not ambitious enough

in our design? Did the people in the teams work well together or was there

tension between team members? What were the reasons for this tension?

This principle is the most important one, if a team or company wishes to

continue improving its products as well as efficiency. If a design processes is not

analysed during and after development, then the teams will continue to make the

same mistakes or have the same inefficiencies instead of finding the mistakes

and slow-downs and improving them.

 89

DSDM

Dynamic Systems Development Method or DSDM is a project management

methodology that is mainly used when developing software and follows the

framework of Agile. DSDM has nine principles, primarily following those of

Agile, aiming toward team empowerment, iterative design, and frequent update

releases, testing phases occurring throughout development, and active user

participation. These principles differ from Agile in that they are more

development-focused and less team and client driven. Despite this, DSDM

continues to push the design teams for iterative and innovative software

development. Nine principles and seven steps form the core of DSDM,

(Dynamic Systems Development Method (DSDM), 2011).

 90

DSDMs nine principles:

1) Active user involvement Imperative.

2) Teams must be empowered to make decisions.

3) Focus on frequent delivery.

4) Criterion for accepted deliverable (Fitness for Business).

5) Iterative and incremental development Mandatory.

6) All changes during development must be reversible.

7) Requirements are base lined at high level.

8) Testing is integrated throughout the life cycle.

9) Collaborative and co-operative approach.

DSDMs seven steps:

1) Pre-Project

2) Feasibility Study

3) Business Study

4) Functional Model Iteration

5) Design & Build Iteration

6) Implementation

7) Post-Project
 91

Both the principles and the steps focus toward the development of software, not

the team or client base. These steps mainly outline how the production of a piece

of software should progress from pre-production to functional builds to

implementations and after release updates.

DSDM existed as a management methodology before the creation of

the Agile Manifesto, originally in order to deliver a methodology for rapid

application development (RAD). RAD was created to provide a rapid

development methodology for models developed in the 1970s and the 1980s

such as the waterfall model or the Structured Systems Analysis, (Rapid

Application Development, 2016). RAD was based on the premise of an ever-

growing knowledge basis by the developers and emphasized the growth and

evolution of a project. It is best used when developing software that focuses on

user interface development. The positives of RAD are better quality product as

well as better risk control and more projects being completed on time and within

budget. The downsides are using a new way of approach, spending limited

resources and time, there is less control over the project, poor design as it

focuses on prototypes and not the overall picture, and it has trouble handling

larger sized projects.

 92

Figure 7, Evolution of DSDM, (Dynamic Systems Development Method (DSDM), 2011)

After the Agile Manifesto was designed, DSDM changed a few of its

guiding principles of design, which can be seen in Figure 7, (Dynamic Systems

Development Method (DSDM), 2011). The image shows what a traditional

DSDM development cycle was before Agile and what it evolved to after the

manifesto. The traditional development company wanted a piece of software

that had fixed functions, interfaces, mechanics, and system but allowed for

varied amounts of time and resources for the development of the software. With

the fixed functionality of traditional DSDM, there is no room for growth or

evolution in a piece of software contrary to iterative methodologies. Traditional

DSDM also has varied time and resources, which is bad for several reasons.

With varied time, a fixed function, and the poor enthusiasm to work on the

project, projects will most likely run over time costing extra money without any

increase in product design. The varied resources can both be a positive and a

negative. The resources provided can be either too low or high. Too low means
 93

the developers will not have what they need to design the software properly.

Whereas, if they have all the resources they need they will be able to develop

any part of the system without using time to request additional resources.

However, with this increase of resources is also an increase of money, which is

some cases, can mean the product not making a profit.

The new revised DSDM use principles from Agile, such as technical

excellence, active user involvement, etc, which completely reverses the system

with the functions of a piece of software, seen in Figure 7, (Dynamic Systems

Development Method (DSDM), 2011). With functions, time, and resources

allocated like this it means that with a variable function the developers can focus

on the most important aspects of any piece of software and when those are

completed, work on other systems. This focus enables to team to work on what

they feel is most important. With the time and resources also fixed, the team

knows when they need to have a functional product and what resources are

available to make this happen. Fixed time scales encourage developers to get the

product done by the due date, which also pushes the product forward and gives

the developers a challenge when designing the systems. The resources available

should always be fixed, unless a piece of software or equipment is absolutely

needed, which keeps costs down, increases profits, and provides another way for

the designers to creatively work around issues that pop up in development.

 94

Scrum

Agile provides basic and understandable principles with which to base a

company. It also delineates which aspects of development and business should

be focused on and in what way. Scrum takes those principles and organises them

into a cohesive plan that a team or company can use to design a piece of

software. It helps set up team composition as well as lines of communication

between teams, managers, and producers. It lists out a set of steps that should be

followed. As a company uses Scrum they can alter and make changes that best

fit their team structures. Scrum is by definition, an iterative and incremental

agile software development framework for managing product development.

(Scrum (software development), 2015). This means that throughout

development many iterations or versions of the game or software should exist,

each with its own unique changes. Changes can be either positive or negative

with each of these versions leading to the final product. A flexible

developmental methodology enables self-organizing teams to work together on a

product until the final releasable version is achieved. Scrum encourages creative

problem solving at all levels of development to overcome design complications.

There are three distinct roles in a Scrum: Product Owner, Scrum Master,

and the Team, (James, M. no date). The Product Owner is the person with the

overall vision of the product. According to James (no date) Product Owners

have the power to alter that vision but they should not interfere with the creative
 95

development process of the teams. The Scrum Master is a leader whose role is to

communicate to the Product Owner about the work being done; similarly, it is

their job to remove any impediments the team may face. They are not there to

manage the members of the team, but rather to ensure they progress smoothly.

Meanwhile, the team is the core of Scrum where all of the development takes

place. Each team should be completely self-managing and self-organising in a

fashion that work is completed on time. Each team is comprised of several

individuals from different fields of expertise, ranging from programming,

designing, aesthetics, QA Testing (quality assurance), and, in some cases,

analysts. Having members from a range of fields allows each team to be self-

organising, managing, and autonomous.

The Scrum process is simple and easy to alter if a team works with a

different variation of workflow (Scrum Alliance, 2016). The process begins with

the Project Owner creating a wish list comprising of all of the features desired

in the software or game. These features would include game mechanics, play

style, art and audio themes, and win/lose conditions. The second phase includes

the team pulling a few items from the top of the list and working on them during

what is called a sprint, which is two to four weeks long and involves the team

implementing those features into the software. The major factor about this step

is the team deciding the best and most efficient way of implementing these

features. When a sprint is completed, the team then reviews the progress made.

The team then takes some more features from the top of the shopping list and
 96

starts the process again. At the end of each sprint, the prototype created by the

designers should be in a potentially shippable package that can be used by

customers.

James (no date) discusses throughout the process that the Scrum

Manager works toward removing obstacles that keep the team from being

productive as well as keeping the team members focused on the work. The team

also has a Daily Scrum, which is an everyday meeting to review the work and

progress of that day. They make changes and alterations to their workflow or

focus at this meeting and decide where the current features need to go in

development. These short cycles of development help to keep the team engaged,

focused, and enthusiastic on work due to the time constraints of each sprint as

well as the changing of features that are developed in that time, which brings

variation to the work, being produced.

Scrum is widely used for game development because it recognises and

enhances the iterative design approach. By using this design methodology, the

process of sprints allows the teams to develop a feature and at the end take

advantage of the analysis step. This analysis step allows developers to determine

if a feature needs more work or is ready to be fully implemented. Ian Thomas

(2017) said in an interview that scrum works very well with game development.

However, it starts to break down when managers select which principles to

 97

follow and not follow without fully understanding what each principle brings to

a scrum sprint.

According to the official Scrum Alliance website (Scrum Alliance,

2016), the day-to-day process in a scrum has a few steps. The first step being a

daily scrum meeting where the team synchronize activities and ask specific

questions. This meeting should only be about fifteen minutes long and in a

consistent time and place. The questions that should be asked during this

meeting are: what did I do yesterday that helped the development team progress

towards the sprint goal; what will I do today to help the development team

progress towards the sprint goal; and, do I see any obstacles preventing the

development team from meeting the sprint goal. These questions are intended to

allow the development team to analyse where they are and project what

direction the project should take.

Scrum Alliance states (2016) that after the main daily scrum is

adjourned, individual development teams often meet to discuss detailed plans

for the days development, how to adapt to situations, re-planning, and how to

continue to work together effectively as a team. The advantages of having daily

scrums are, it eliminates the need for other meetings, improves communication

between developers, identifies obstacles and ways to remove them, and

improves the knowledge of the development teams.

 98

In an interview with Trygve Bjellvaag, (2017), he discussed how his

small company of about seven people used Scrum and their day-to-day tasks

within it. He said that they started out by checking what needed to be done on

their wish list that was on Basecamp. Basecamp is an online project

management site where developers can make lists, upload data, and organize

files easily, (Basecamp, 2017). The employees would check Basecamp and see

what needed to be done in their area and would then proceed to develop it. Once

they have finished a task they would upload the task onto to Basecamp for other

employees to analyse, suggest corrections, and provide feedback. Once the

feature was finalized and approved, it would then be merged with the game.

This process then starts again for the next task.

Cabal

The Cabal system was fully realized by Valve when they were having troubles

developing Half-Life (Valve L.L.C. 1998). They needed a new system of having

meetings and deciding which features made it into the game. With only a few

months left of development and un-happy with the progress, Valve developed

the Cabal methodology, (Valve Corporation, 2012).

The methodology is straightforward and very successful at generating

new ideas, flushing out bad ideas, and keeping progress at a steady pace. The

Cabal system is a series of intense meetings between a selection of members

 99

working on a game project. Everyone in the Cabal has equal say and no idea is

thrown out right away. Rather, every suggestion is written down for further

consideration. The members of the Cabal can differ meeting to meeting, but the

leads of each specialised team will usually attend. This constant overseeing of

the proceedings ensures that the meetings will stay on track, previously

discussed topics will not be brought up continuously and game information will

be updated regularly, (Birdwell, 1999). As the game progresses through stages

of development, so too do the meetings evolve. Normally the process begins

with a very large document containing every idea, mechanic, story, art

inspiration, or theme. This document can be several hundred pages alone,

outlining every possible aspect the game could include, no matter how silly or

far left field the idea may appear, (Birdwell, 1999). This document gives the

developers an idea of the direction the game will take at the very start. After this

document is created the members of Cabal then start to remove the ideas that are

non-cohesive, not possible to create, or, ultimately, bad ideas. They will then go

through the document and pick out the strongest of the ideas, the ones that can

form the backbone of the game, and focus on enhancing those concepts.

This form of the document allows the teams to start prototyping

mechanics and game levels, as well as the story. As the prototypes are

completed and the backbone of the game takes shape they will then have another

Cabal meeting and discuss what they like and what they do not like about the

prototypes. This discussion then leads to changes in the main design of the
 100

game. This may lead to casting off ideas that were once considered vital to the

project but have now been made obsolete; or, conversely, the re-introduction of

ideas that were once thrown away. At this stage of the Cabal, the entire original

backbone of the game can be ripped apart, analysed, and re-structured based on

how well the prototypes performed, were enjoyed, or flowed as a system. In

some cases, the whole base of the game changes because the prototypes were

simply not fun or had difficult controls. The Cabal system keeps the games from

going down a path that will not lead to a successful game. Cabal will also stop

the game immediately and make it take a new shape, which is fun, functions

gracefully, and is controls smoothly, if the original game does none of those

things, (Birdwell, 1999).

The reason Cabal is successful is the intense fortification that the

iterative design process employs. Each idea, prototype, and function is tested

and analysed thoroughly and reconstructed if needed. This system allows

iterative design to become the main driving force behind developmental

progress while simultaneously weeding out poor design concepts.

 101

Chapter 4: Discussion
Managing a digital game company and the employees that work in one requires

a combination of all the subjects discussed. Communication is key between all

employees in order to allow the flow of information. This communication needs

to have formal channels that everyone understands like Ellsworth (Sinclair,

2013) describes. These lines of communication can be organized in many

different forms depending on what is needed in the company. Some of these

communication networks are; centralized, decentralized, hierarchal, and

briefing. However, even with lines of communication established and

understood there needs to be a structure within the company that outlines project

requirements. These structures such as Scrum, DSDM, and Cabal offer a

framework of production that integrates the iterative design process that is

essential for game development. The frameworks give a flexible day-to-day

schedule for each employee to follow that includes, production periods, meeting

times, and analysis periods.

The next important feature that needs to be included in game

management is the effective use of the iterative design process. The

development structure and the iterative design processes should work together in

allowing employees to develop, analyse, and improve the game as needed. The

structures discussed above and the iterative design process have much in
 102

common. The most prevalent of these is their similar project life cycle. A project

life cycle generally has four main steps: the initiation phase, the planning phase,

the execution phase, and the closing phase, (Watt, 2014). Adrienne Watt (2014)

discusses each in detail; they all follow the same principles as the iterative

design process with the review, and analysis periods taking place in the

execution phase. Scrum follows a similar cycle through development starting

with planning, prototyping, testing, finishing, and then repeating the process for

future features, (Scrum Alliance, 2016). The methodologies discussed all use a

very similar process for development so it is ideal to use them in conjunction

with each other to amplify their strengths. These strengths being project

planning, implementation, review and analysis, team communication, and time

management.

While working for a small Indie Company, Martin Onions, (2017), had

experience working for a company that had a poor file sharing system, and did

not evolve or constantly analyse their work. He explained that they used

TortoiseSVN a file and art sharing system and every time anyone wanted to

submit a piece of work they had to fill out a report that was long and tedious. He

said that these reports just piled up and created excessive paper work that no one

could sort through and took away from time that could be spent working. Martin

eventually left this company due to the, [] file sharing and report networks

were very disorganized, and he said they didnt evolve their management or

development structures while he was there. He explained because they were

 103

unwilling to evolve, they soon after his departure, changed from a development

company to a publishing firm because it was less work for the employees.

The unwillingness for a company to evolve either its management or

developmental structures can cause several issues. One such issues as Martin

Onions (2017) described is either a break down or a consistently bad reporting

and file sharing structure. If such issues are not addressed and fixed then the

system will get bogged down and employees will have difficulty finding what

they need for their work. If issues such as these are not addressed and fixed soon

then companies will continue to have the same inefficiencies. Developmental

issues are just as bad. Martin Onions (2017) also talked about how the teams in

the company were unbalanced and that sometimes artists would have to fill in

for other roles such as coding. This type of issue can be solved by better time

management for individuals within a team and how they proceed with their

work. They must decide effectively and put the tenth Agile principle into effect

which is, [] the art of maximizing the amount of work not done, (Beck et al.

2001). Artists can do this by creating models and textures that are optimized

from the start instead of having to go back and re-do work on previously

finished models; and coders can make code that is stable and efficient the first

time instead of having to go back and add in patches.

 104

Issues such as these disrupt a projects life cycle by inefficiencies in the

workflow, lines of communications, and the analysis of the product.

Communication networks and management methodologies are used to mitigate

these inefficiencies and keep the project life cycle from being disrupted. There

are several ways to help keep a projects life cycle on track. One of the best

ways is to keep communication clean and clear. While working at a small Indie

company Trygve Bjellvaag (2017) said that their communication evolved from

sending emails to each other to using skype on a daily basis, then to using

basecamp and GitHub. The evolution of communication and file sharing

networks are an example of teams analysing where their weak points are and

attempting to fix them. This enables future projects to run more smoothly.

Analysing communication networks alone is just half. The other half is evolving

methods used while developing. Ian Thomas (2017) discussed when he was with

a small Indie company that had just formed had trouble finding the method that

worked best for them. They started using bits of Scrums and bits of Agile;

cherry picking what they felt would work the best. As they progressed in their

development, they realised which bits did and did not work and realised which

principles or steps they were not including that they needed to be.

Analysis of a game product at the end of a sprint is important but it is not

the only analysis that needs to happen. Developers and managers need to also

look at their communication and developmental structures and find ways to

improve the way they work. These improvements will carry on to future
 105

developmental projects and continually improve the efficiency of the teams and

the managers. Analysis in a game developmental company is key in all aspects

of the company from developmental to managerial.

 106

Chapter 5: Conclusion
The effectiveness of these networks are based on the efficiency of lines of

communication coupled with personal responsibility for work done. While

Hobbyist, Indie, and AAA companies have differing number of employees, they

all have the same goal, to make games. Hobbyists have three to five members,

which means a small number of lines of communication. Small Indie Developers

have less than fifty employees and larger indie companies have less than 250

employees, (What Is An SME? - European Commission, 2016). With this

increase in scale, it is beneficial to have a more formal structure to facilitate

greater communication needs. AAA companies have hundreds of developers,

which means many teams, and supervisors that brings about a large structure to

keep everyone updated with all the relevant information they need, Ian Thomas

(2017) shows this in Figure 2. These three company types, while having the

same goal, need different management structures that suit their number of

employees.

This paper attempts to analyse the most prevalent management structures

employed in businesses and pair them with a creatively focused environment.

By having the iterative design process as the prominent practice it enables

creative design over a waterfall method, (Manning, no date). All management

networks have their upsides and downsides but clear understanding of the rules
 107

and procedures of a company will limit the issues caused during development,

(Scolese 2006). This understanding comes from clear and constant

communication; trust in employees and management, well-defined goals and

deadlines, and an encouraging work environment. Regardless of the network

being used by any type of company these are all key aspects they need to

employ and enforce. These four simple principles will ensure a company has

strong lines of communication, fluid movement of information, and an

enthusiastic development team.

While managerial structures in a non-creative business will not need to

morph and adapt while providing a constant product, a creative industry needs to

be able to morph and adapt to the development team and the work they are

doing, (Zimmerman, 2003). This adaptation needs to be able to account for

changing team sizes, different and changing project requirements, and

fluctuating lines of communication. If managers can adapt to these shifting

variables, by altering network functionality, then inefficiencies can be avoided

and keep projects on time and in budget.

The small teams of hobbyist developers are the easiest to manage. With

three to five people, there are few lines of communications and the team can be

managed easily with a simple centralised or decentralised network as discussed

in chapter one, (Pettinger, 2001). Either the team can appoint one person to

gather all the information and pass out work in a centralised network; or they
 108

can use a decentralised network and pass information to everyone and all decide

together on what work needs to be done and in what order. There are other

networks that can be used such as Flat, or Briefing, although these may be better

suited to a more complex and larger company structure.

Small Indie companies that are less than fifty employees can elect to

stick with a single network or could branch out and use a matrix structure. The

individual networks that they could use would be the Briefing network,

Hierarchal network, Flat network, and Complex Decentralised network,

(Pettinger, 2001). These four networks all allow information to pass between

developers with ease. Small Indies also have the opportunity to use matrix

systems. They have enough employees and teams that they would be able to

benefit from a mix of networks.

A few matrix systems that companies could benefit from would be a

Briefing and Decentralised matrix, Flat and Decentralised, and a Flat and

Briefing network. The networks listed subsequently are laid out so the primary

structure is first and the secondary structure last. In a Briefing and Decentralised

network, the lead game developers would hand out briefs to either managers of

teams or every employee. The teams would then use a Decentralised network to

develop the game allowing free communication and flow of information

between the developers within the secondary network. Managers of each team

would be able to communicate with each other as well as lead game developers
 109

continuing the flow of information in a structured form. As has been stated these

networks allow clear communication between parties and provide an ideal arena

for agile methods. With a Flat and Decentralised network, the teams would work

and communicate the same but the company as a whole would have less

managers than networks such as Hierarchal in a larger AAA company. Instead,

the employees of the company would decide and agree on the direction of

games, the company, and workloads. The last matrix system, a Flat and Briefing

network would work with a few individuals leading the company that give a

brief to everyone else to prototype. These matrix systems foster an iterative

design method within a company that would ideally employ Agile approaches.

A good example of this is Supercell. They do not have any immediate head of

the company but all work in teams. When a team believes they have a prototype

they feel can be taken further they present the idea to the rest of the company,

every other team, and everyone then votes if they should proceed with that idea.

If they do then every team works together to build and release the game. The

team with the idea become the managers for that game and give the brief to

develop it. They take advantage of the creative freedom the Flat structure

employs. When needed, the companys management structure then mutates to

the Briefing network, which supplies high quality of communication during

companywide development, as stated in Chapter 1.

 110

Larger Indie and AAA companies will either need to use a singular

structure or a matrix structure to allow for greater communication between

teams and managers. The main network that allows for this is the Hierarchal

network. It allows information to travel up and down between managers and

employees. It is, however, a very heavy network with a lot of maintenance. The

advantages of this structure is a clear chain of command, efficient flow of

information, and allows for division of work. Larger companies can take

advantage of having a matrix network that is a combination of Hierarchal and

Decentralized. The Hierarchal network allows all the managers to meet and keep

the flow of large amounts of information freely among teams and lead

developers. The Decentralized network in teams provides the free flow of

information between team members allowing for a more relaxed but efficient

structure, (Pettinger, 2001).

The matrix structures suggested above are just a few examples that can

be used in game development. Even when a company decides on a management

network to use it will evolve to adapt to the needs of the game, employees,

stakeholders, and others. These adaptations are changes in communication,

information flow, and employee satisfaction.

 111

Future Work

Future research in this area could include management methods at a smaller

level. Management at a smaller level would include how leaders encourage and

promote productivity and creativity. Leaders can be broken into two category

types, type A and type B. A type A leader is someone who always wants

things done their way. They keep all of the information to themselves if they

can, answer few questions and maintain strict control, (Boy Scouts of America,

2009). Type B believes I sharing all information with everyone. They want to

enable their team to use all of their talents and creatively find solutions for the

problems at hand. They also encourage and assist in the problem solving and use

everyones knowledge, (Boy Scouts of America, 2009).

There are method of teaching and leading groups of people as well. Two

of these are referred to as teaching and leading E.D.G.E. E.D.G.E. stands for

four simple words in which to teach and lead teams; Explain, Demonstrate,

Guide, and Enable, (Boy Scouts of America, 2016). Explain includes the leader

of the team explaining the task the group is performing and possible ways to

accomplish it. The leader then demonstrates a way in which to achieve the goal

or shows a method which one could use. While the members of the team try the

task, the first time the leader watches and guides them as they continue and

offers corrections, advice, or encouragement if needed. After members, know

how to complete the task or understand the methods to use, the leader then
 112

enables the members to proceed on their own. The position of where the leader

should be during each step is shown in figure 8.

Figure 8, Team Leadership, NYLT Syllabus, (2016)

This E.D.G.E. principle works in conjunction with a four-step stage of

development for a team. The four stages are, forming, storming, norming, and

performing, (Boy Scouts of America, 2016). Figure 9 shows the four stages and

their respective phases the team goes through as well as where they are in

E.D.G.E. During the forming stage, the team has high enthusiasm for the tasks

ahead of them but now training and low skill in accomplishing them. They do

not have a common goal. When the team is storming, they are frustrated because

they have low skill and so enthusiasm drops in the team, they are butting heads

with each other on what the common goal is. As the team progress, they enter

the norming phase where they are learning the skills and understanding what

needs to be done. At this point, they are starting to understand what the goal is

and the path they need to go to achieve the task. When they enter the performing

phase they are now working as a team and understand the skills and concepts,
 113

they need to, to achieve the tasks. At this phase, they are now working towards a

common goal as a team, shown in figure 10.

Figure 9, Stages of Development, NYLT Syllabus, (2016)

Figure 10, Team Development, NYLT Syllabus, (2016)

Future research could go into how leadership at the smaller levels of a

team could help foster and encourage creativity in the game design industry.

Methods could be analysed as well that are employed by Agile at a team level

and how effective they are on a smaller scale compared to the larger company

scale. These methods could be compared to the methods that the Boy Scouts of

America teach and employ at training camps such as Wood Badge and NYLT,

(National Youth leadership Training). These training camps and how the Boy
 114

Scouts trains leaders is relevant to management in that they teach people how to

manage, communicate, and work with other people as a team.

 115

Bibliography
Agile Alliance (2016) What is Agile Software Development? Available at:
https://www.agilealliance.org/agile101/what-is-agile/ (Accessed: 29 January
2016).

Ambinder, M. (2009) Valve's Approach To Playtesting: The Application Of

Empiricism, GDC Conference: Learn Network Inspire, San Francisco, 23-27
March, Valve, [Online]. Available at:
http://www.gdcvault.com/play/1566/Valve-s-Approach-to-Playtesting
(Accessed: 24 February 2016).

APM, (2015) What Is Project Management? Available at:

https://www.apm.org.uk/WhatIsPM (Accessed: 17 march 2016).

Anand, B. (2011) 10 Methods To Keep Your Team Motivated. Conscires

Agile Practises. [Online] Available at:
http://agile.conscires.com/2011/11/03/10-methods-to-keep-your-team-
motivated/ (Accessed: 16 March 2016).

Basecamp, (2017). How Basecamp works, what it's like to organize your
projects & teams in one place. [online] Basecamp.com. Available at:
https://basecamp.com/how-it-works [Accessed 6 Apr. 2017].

Beck, K et al. (2001) The Agile Manifesto. Salt Lake City: Unknown.

Bitcoin College (2014) The Battle of Our Generation: Centralized VS.

Decentralized Networks. Available at:
http://www.bitcoincollege.info/centralized-vs-decentralized-computing/
(Accessed: 11 October 2016).

Birdwell, K. (1999) The Cabal: Valves Design Process for Creating Half-Life,
Gamasutra, 10 December. Available at:
http://www.gamasutra.com/view/feature/131815/the_cabal_valves_design_proc
ess_.php (Accessed: 15 December 2015).
 116

Bjellvaag, T. Skype Interview Date: February 16, 2017. 1:00 pm GMT.

Bono, D. E. (2016) Edward de Bono quotes goodreads. [Online]. Available at:

https://www.goodreads.com/author/quotes/6980.Edward_de_Bono (Accessed:
17 November 2016).

Boy Scouts of America, (2016) National youth leadership Training Syllabus.

[Online]. Available at: http://www.scouting.org/filestore/NYLT2016/511-
490_NYLT.pdf (Accessed: 30 march 2017).

Boy Scouts of America, (2009) Wood Badge Training Syllabus. (Unknown ed.)
Irving, Texas: Boy Scouts of America.

Businessballs.com (2016) Available at:

http://www.businessballs.com/teambriefing.htm (Accessed: 4 November 2016).

Carroll, J. and Morris, D. (2015) Agile Project Management. 2nd ed.

Warwickshire, United Kingdom: Easy Steps Limited.

Chand, S. (2016) 8 Types of Organisational Structures: their Advantages and

Disadvantages, Your Article Library, [Online]. Available at:
http://www.yourarticlelibrary.com/organization/8-types-of-organisational-
structures-their-advantages-and-disadvantages/22143/ (Accessed: 12 October
2016).

CIPR (2016) What is PR? Available at: https://www.cipr.co.uk/content/careers-

advice/what-pr [Online]. (Accessed: 8 November 2016).

Davis, S. M. and Lawrence, P. R. (1978) 'Problems of Matrix Organization,

Organizational Structures, Harvard Business Review, [Online]. Available at:
https://hbr.org/1978/05/problems-of-matrix-organizations (Accessed: 26
October 2016).

DellaFave, R. (2014) How To Fund Your Indie Game, Envatotuts+

(Unknown) [Online]. Available at:
https://gamedevelopment.tutsplus.com/articles/how-to-fund-your-indie-game--
cms-20514 (Accessed: 4 April 2016).
 117

Denning, S. (2010) The Leaders Guide to Radical Management. San Francisco,

California: A Wiley Imprint.

Denning, S. (2011) Is The Goal Of A Corporation To Make Money? Forbes,

pp. 1 [Online]. Available at:
http://www.forbes.com/sites/stevedenning/2011/09/26/is-the-goal-of-a-
corporation-to-make-money/#6e2f1a497658 (Accessed: 10 October 2016).

Devane, C. (2012) Leadership in a matrix. London: The NHS Confederation.

Donald A. N. (2013) The design of everyday things. Cambridge, Massachusetts:

MIT Press.

Diefenbach, T. and Sillince, J. (2011) Formal and Informal Hierarchy in

Different Types of Organization, SAGE Journals, 32(11) pp. 4. Sage Journals
[Online]. Available at: http://oss.sagepub.com/content/32/11/1515.abstract
(Accessed: 7 April 2016).

Drucker, P. (1989) The Practice of Management. London: Butterworth-

Heinemann.

Dynamic Systems Development Method (DSDM) (2011) Wikidot. Available

at: http://dsdmofagilemethodology.wikidot.com/ (Accessed: 3 March 2016).

Forums.factorio.com. (2016). Factorio Forums View topic - Factorio

Roadmap for 0.15 + 0.16. [online] Available at:
https://forums.factorio.com/viewtopic.php?t=678 [Accessed 11 Mar. 2017].

Freeman, J. (1970), Tyranny of Structurelessness. USA: Berkeley Journal of

Sociology.

Fullerton, T. and Swain, C. (2004) Game Design Workshop. San Francisco,

Calif.: CMP.

Furze, D. and Gale, C. (1996) Interpreting Management. London: International

Thomson Business Press.
 118

Encyclopedia.com (2009) Organizational structure Available at:

http://www.encyclopedia.com/social-sciences-and-law/economics-business-and-
labor/businesses-and-occupations/organizational-1 (Accessed on: 11 October
2016).

European Commission (2016) What Is An SME? - European

Commission, Ec.europa.eu. Available at:
http://ec.europa.eu/growth/smes/business-friendly-environment/sme-definition/
[Online]. (Accessed on: 22 March 2016).

Gearbox Software (2009) Borderlands (Standard Edition) PC [Computer

Game]. Steam.

Gill, P. and Vaughan. W. (2006) Engineering Excellence and the Role of

Technical Standards. Reno: Aerospace Sciences Meeting. [Online]. Available
at:
http://www.consortiuminfo.org/linked/AIAA2006RenoEngineeringExcellence.p
df (Accessed: 26 August 2016).

Gill, P. and Vaughan. W. (2008) Technical Excellence: A Requirement for Good

Engineering. Nevada: American Institute of Aeronautics and Astronautics.
[Online]. Available at:
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080014086.pdf
(Accessed: 26 August 2016).

Goman, C. K. The Immeasurable Importance Of Face-To-Face Meetings,

Leadership, Like a Boss, (Unknown) pp. 1-2. Forbes [Online]. Available at:
http://www.forbes.com/sites/carolkinseygoman/2016/03/11/the-immeasurable-
importance-of-face-to-face-meetings/#2b5de3db6574 (Accessed: 6 October
2016).

Haughey, D. (no date) Introduction to Project Management, Project Smart,

Unknown. [Online]. Available at: https://www.projectsmart.co.uk/introduction-
to-project-management.php (Accessed: 17 April 2016).

Harrison, R. (2002) Learning and Development. 3rd. Edition, The Cromwell

Press, Great Britain.
 119

Hierarchical Organisation
http://www.learnmanagement2.com/hierarchical%20structure.htm (no date)
(Accessed: 16 February 2016).

Irish, D. (2005) The Game Producers Handbook. Boston, Mass.:

Thomson/Course Technology.

Ismail, R. (2014) Watch Vlambeer's 17 Lessons for Indie Developers.

gamesindustry.biz: GAMELAB, [Online]. Video. Available at:
https://www.twitch.tv/zeroempires/v/31064617 (Accessed: 10 November 2015).

ISTQB Exam Certification (2016) What is Waterfall model- advantages,

disadvantages and when to use it? Available at:
http://istqbexamcertification.com/what-is-waterfall-model-advantages-
disadvantages-and-when-to-use-it/ (Accessed on: 13 October 2016).

James, M. (no date), An Empirical Framework for Learning (Not a

Methodology) Scrum Methodology. Available at:
http://scrummethodology.com/ (Accessed: 3 March 2016).

Keliom, L. (2013) Valve: How Going Boss-Free Empowered The Games-

Maker - BBC News. BBC News. [Online]. Available at:
http://www.bbc.co.uk/news/technology-24205497 (Accessed: 22 June 2016).

Kniberg, H. and Ivarsson., A. (2012) Scaling Agile @ Spotify With Tribes,

Squads, Chapters & Guilds. UNKNOWN: UNKNOWN.

Krogh, G. V., Nonaka, I., Rechsteiner, L. (2012). Leadership in organizational

knowledge creation: A review and framework. Journal of Management Studies
49(1): 240277. Available at: http://onlinelibrary.wiley.com/doi/10.1111/j.1467-
6486.2010.00978.x/full (Accessed: 21 April 2016).

Krogh. G. V. Geilinger, N. (2015) Valves Organization Opportunities and

Open Questions, Journal of Organization Design, 4 (2) pp. 18-19. Journal of
Organization Design. [Online] Available at:
http://www.jorgdesign.net/article/view/20159/18618 (Accessed: 21 April 2016).
 120

Kruchten, P. (2001) From Waterfall to Iterative Development -- A Challenging

Transition for Project Managers, ResearchGate, 3, 4. [Online]. Available at:
http://www.itu.dk/people/hesj/SUTI/Artikler/waterfall2iterative.pdf (Accessed:
23 June 2016).

Learnmanagement2.com (Unknown) Flat Organisational Structure. Available

at: http://www.learnmanagement2.com/flat%20structure.htm (Accessed: 24 June
2016).

Learnmanagement2.com (Unknown) Matrix Organisational Structure.

Available at: http://www.learnmanagement2.com/matrix%20structure.htm
(Accessed: 12 October 2016).

Lencioni, P. (2016) Communication Needs To 'Cascade' From Executive

Suite. The Table Group. [Online]. Available at:
http://www.tablegroup.com/newsroom/news/communication-needs-to-cascade-
from-executive-suite Accessed: 17 February 2016).

Linkedin. Valve Corporation. Linkedin. [Online]. Available at:

https://www.linkedin.com/company/valve-corporation (Accessed: 21 April
2016).

Luthra, V. (2016) Policies and Procedures, Businessdictionary. Available at:

http://www.businessdictionary.com/definition/policies-and-procedures.html
[Online]. (Accessed: 24 August 2016).

Manning, J. (Unknown) Iterative Design Presentation, Unknown.

Meinhard, A. (No date) Organizational Structure. Available at:

http://www.ryerson.ca/~meinhard/841notes/struct.html (no date) [Online].
(Accessed: 16 February 2016)

Merchant, D. (Unknown) Funding For Game Projects Obscure (Unknown)

[Online]. Available at: http://www.obscure.co.uk/articles-2/funding-for-game-
projects/ (Accessed: 4 April 2016).

Michael, D. (2003) The Indie Game Developer Survival Guide. Hingham,

Mass.: Charles River Media
 121

Mookherjee, D. (2016) Decentralization, Hierarchies And Incentives: A

Mechanism Design Perspective. Unknown.

NASA Directive, 2005, Strategic Management and Governance Handbook,

NASA Policy Directive NPD 1000.0, August 2005, NASA Headquarters,
Washington, D.C.

Obscure (Unknown) Obscure, Biz Dev support for Creative Developers.

Available at: http://www.obscure.co.uk/articles-2/funding-for-game-projects/
(Accessed: 13 April 2016).

Onions, M. Skype Interview Date: February 23, 2017. 8 pm GMT.

Panagiotakopoulos, A. (2009) An Empirical Investigation of Employee Training

and Development in Greek Manufacturing Small and Medium-sized Enterprises
(SMEs). The University of Leeds, Leeds University Business School.

Peter, L. J., Hull, R. (2009) The Peter Principle: Why Things Always Go Wrong.
1st Collins Business Ed. HarperCollins Publishers, United States of America.

Pettinger, R. (2001) Mastering Management Skills. Basingstoke: Palgrave

United States.

Rapid Application Development (2016) Wikipedia. Available at:

https://en.wikipedia.org/wiki/Rapid_application_development (Accessed: Web.
3 March 2016).

Rock Paper Shotgun. (2015). Is Early Access A Good Thing For Players Or
Developers?. [online] Available at:
https://www.rockpapershotgun.com/2015/07/31/steam-early-access-good-bad/2/
[Accessed 11 Mar. 2017].

Rockstar Games (2015) Grand Theft Auto V (Standard Edition) PC [Computer

Game]. Steam.

Schultz, W. (2016) AAA Game. About Money. [Online].

http://gameindustry.about.com/od/glossary/g/Aaa-Game.htm Available at:
(Accessed: 22 March 2016).
 122

Schreiber, I. (2009) Level 2: Game Design / Iteration And Rapid Prototyping.

WordPress. No date, [Online]. Available at:
https://gamedesignconcepts.wordpress.com/2009/07/02/level-2-game-design-
iteration-and-rapid-prototyping/ (Accessed: 23 June 2016).

Scolese, C. (2006) Four Guiding Principles of Technical Excellence, NASA

ASK OCE Newsletter, Vol. 1, Issue 4, NASA Headquarters, Washington, D.C.

Scrum Alliance (2016) Learn About Scrum. Available at:

https://www.scrumalliance.org/why-scrum (Accessed: 10 March 2016).

Scrum Alliance (2016) Learn About Scrum. Available at:

https://www.scrumalliance.org/why-scrum/scrum-guide (Accessed: 2 February
2017).

Scrum (software development) (2015) Wikipedia The Free Encyclopaedia.

Available at: https://en.wikipedia.org/wiki/Scrum_(software_development)
(Accessed on: 3 March 2016).

Segal, J., Smith, M., Boose, G. and Jaffe, J. (2016). Nonverbal Communication:
Improving Your Nonverbal Skills and Reading Body Language. [online]
Helpguide.org. Available at:
https://www.helpguide.org/articles/relationships/nonverbal-communication.htm
[Accessed 11 Mar. 2017].

Shashika, (2011) Dynamic Systems Development Method (DSDM) - AGILE

Methods of Software Development, Dsdmofagilemethodology.wikidot.com.
Available at: http://dsdmofagilemethodology.wikidot.com/ [Online]. (Accessed:
3 March 2016).

Shiralige, A. (Unknown) Agile: Simplicity - The Art Of Maximising The Work

Not Done, Agilebuddha.com. Available at:
http://www.agilebuddha.com/agile/agile-principle-simplicity-the-art-of-
maximising-the-work-not-done/ [Online]. (Accessed: 21 June 2016).

Sinclair, B. (2013) Valve's Flat Structure Leads to Cliques, Says Ex-Employee,

gameindustry.biz. Available at: http://www.gamesindustry.biz/articles/2013-07-
08-valves-flat-structure-leads-to-cliques-say-ex-employee [Online]. (Accessed:
19 April 2016).
 123

St. John, V. (2013). Best Practices: Five Tips for Better Playtesting. [online]
Gamasutra.com. Available at:
http://www.gamasutra.com/view/feature/185258/best_practices_five_tips_for_.p
hp?page=2 [Accessed 13 Mar. 2017].

Sun, L. (2016) Which Organizational Structure is Right for Your Business?,

BusinessDictionary, [Online]. Available at:
http://www.businessdictionary.com/article/557/which-organizational-structure-
is-right-for-your-business/ (Accessed: 28 October 2016).

Tanguay, D. (2016) Chain Of Command Principle - Organization, Manager,

Model, Company, Hierarchy, Current Status, Referenceforbusiness.com,
(Unknown), pp. 1.

Tate, K. (2006) Sustainable Software Development. Upper Saddle River, NJ:

Addison-Wesley.

Thomas, I. Interview in person University of South Wales, Atrium. Cardiff

United Kingdom, Date: January 27 2017, 1:00 pm. GMT.

Unkown, Unknown. 45 Unforgettable Quotes About Ideas. INeedMotivation.

Available at: http://www.ineedmotivation.com/blog/2008/07/45-unforgettable-
quotes-about-ideas/ [Online]. (Accessed: 1 February 2016).

Valve Corporation, (2012) Valve, Handbook For New Employees. United States:
Valve

Valve Corporation (2016) Wikipedia. Available at:

https://en.wikipedia.org/wiki/Valve_Corporation (Accessed: 21 April 2016).

Valve L.L.C. (1998) Half-Life (Edition Standard) PC [Computer Game]. Steam.

Walden, C. (2016) Funding And Opportunities For Game Developers -

Microsoft UK Developers, Microsoft (Unknown) UK Developers [Online].
Available at: https://www.microsoft.com/en-
gb/developers/articles/week03sep14/funding-and-opportunities-for-game-
developers/ (Accessed: 4 April 2016).
 124

Watt, A. (2014) Project Management, Creative Commons Attribution 4.0

Unported License. Available at: https://opentextbc.ca/projectmanagement/
[Online]. Accessed on (4 March 2017).

What Games Are (no date) Vertical Slice. Available at:

http://www.whatgamesare.com/vertical-slice.html (Accessed: 21 April 2016).

Whitwam, R. (2015) A Train You Ride In Fallout 3 Is Actually An NPC

Wearing A Train Hat. GEEK. Available at: http://www.geek.com/games/a-
train-you-ride-in-fallout-3-is-actually-an-npc-wearing-a-train-hat-1628532/
[Online]. (Accessed: 2 January 2016).

Wiley, (2016). Corporate Management, Large-Scale Organization In

Context_WEB. Available at:
http://www.wiley.com/legacy/Australia/PageProofs/BUS_MAN/3_4/c01Large-
ScaleOrganisationsInContext_WEB.pdf [Online]. (Accessed: 16 March 2016).

Zimmerman, E. (2003), Design Research Methods and Perspectives,

Massachusetts of Technology