3. Honours Project

Game Development Plan and Reflective Log

PART 1 – GAME DESIGN OVERVIEW

1.1. PRODUCT OVERVIEW

Name: Daemon Noir

Developer: Silver Bullet Games, Ltd.

Category: FPS / Adventure RPG

Similar titles: Deus Ex; System Shock 2; BioShock; Condemned: Criminal Origins

Overview:

Daemon Noir is a supernatural action thriller from Silver Bullet Games the acclaimed creators of cinematic action games Katana and Polar Paradise. In this groundbreaking game for next generation platforms, players assume the role of “Damien Noir”, a private investigator with an eye for unexplained phenomenon. Players will travel across 1930s Europe, investigating unexplained murders, hauntings, cases of demonic possession, and reports of monstrous creatures. Players will have to use their wits and investigation abilities as well unconventional weaponry to overcome the game’s challenging problems and terrifying adversaries.

Features:

  • First Person Adventure – This isn’t a standard shooting game – mystery, investigation and problem solving go hand-in-hand with the combat.

  • Intense cinematic combat – each battle is a dramatic and memorable life or death struggle, where wits, problem solving, and crafty use of the environment are just as important as raw firepower and combat finesse.

  • Open-ended gameplay — Real-world environments and free-roaming, objective-based missions will allow players choose their own path throughout the game’s scenarios. Players will be encouraged to experiment and come up with their own solutions to problems and challenges.

Development timeframe:

36 months

Formats:

PC and next-generation consoles

  • Microsoft Windows XP and Vista

  • Microsoft Xbox360

  • Sony Playstation 3

ESRB Rating:

The target is Teen or Mature.

1.2. GAME DETAIL

Genre: Supernatural thriller

Setting: 1930s Europe, including cities like Paris, Florence, and Venice.

Visual Style: Film-noir / Gothic horror

Overview – Like a comic book, the game’s overall story arc unfolds across a series of self-contained episodes (cases), quickly dropping the player into exciting and varied gameplay scenarios. Each ‘case’ plays out like a typical episode of The X-Files – the player investigates a small town or location, discovers something wrong with it, and attempts to resolve the problem (e.g. exorcising a demon). For example, one scenario will have the player hunt down vampires in a small Eastern European town.

Investigation – Investigation and problem solving will be integral components of the game. As a private investigator, the player will be able to investigate crime scenes and hauntings; interrogate locals for information; search libraries and museums; as well as break into private property for further clues. Players will use this information to complete their mission objectives such as hunting monsters; exorcising ghosts; and so on.

Hunting Enemies – Unlike most FPS games, the enemies in Daemon Noir won’t be actively searching for the player – instead they will be hiding from him. For example, vampires, werewolves, and demons can disguise themselves as humans; so it will be up to the player to ‘discover’ them before more people are killed. As exemplified by TheSilence of the Lambs, the investigation part will ‘build up’ to a confrontation with the main adversary(s) — typically with dramatic set pieces along the lines of Die Hard, James Bond, and Indiana Jones.

Intense supernatural combat – Enemies will have unique strengths and weaknesses, and the player will have to discover creative ways to overcome them besides conventional firepower. Experimentation and creative use of the surrounding environment will be critical to the combat. For example, players might be able to break apart furniture for make-shift wooden stakes, block doors, and create battering rams. Unique demon-hunting weapons like silver bullets, holy water, and stakes will also be available. However, violence will not always be the best solution – the player will face ‘victims’ possessed by demons, which require non-violent solutions (i.e. exorcism) to prevent the host from being killed as well.

1.3. MARKETING AND COMPETITIVE ANALYSIS

Competitive Analysis

Innovation in the ‘First Person Shooter’ genre peaked between 1996-2002, with titles like Goldeneye 007, Duke Nukem 3d, Rainbow-Six, Half-Life, System Shock 2, Thief, Morrowind, and Deus Ex. These games tried to build on the basic FPS formula of Wolfenstein 3D and Doom, and create something truly groundbreaking. For example, Goldeneye 007 combined the kinetic arcade action of Virtua Cop with the mission design of Super Mario 64 to create a more strategic FPS game (Hollis, M. 2004).

Unfortunately, today the FPS genre has become stagnated – over saturated with military and science fiction games (e.g. Call of Duty 4 and Halo 3). These are obviously still successful markets, but for how long? With a few exceptions like BioShock and Portal, innovations today are mostly technical, not conceptual, which we feel is pushing the genre into a dead end – games are already becoming noticeably shorter to accommodate massive technical and content requirements.

In 1996 Capcom cleverly combined the classic ‘Adventure’ genre with arcade shooting gameplay to create the massively successful Resident Evil franchise. We believe this kind of evolution is the way forward if the FPS genre is ever to mature past its roots of Doom. Games like Deus Ex, System Shock 2, and Morrowind proved the critical and commercial potential of this, and we plan to take it further – before someone else does.

Positioning powered design

Rather than a simple list of unique-selling-points, Daemon Noir is designed with specific positioning principles to generate buzz and make it newsworthy (Miller, 2003).

Leading Paranormal Investigator– We expect Damien Noir to own the category of ‘Paranormal Investigator’ in the games industry; just as Max Payne is the industry’s leading ‘Vigilante Cop’ and Phoenix Wright is the industry’s leading ‘Ace Attorney’. It’s important to be the first in a category like this, to differentiate the game from existing titles and subsequent clones (Miller, 2003). NB: For this reason we’re not going after the category of ‘Demon Hunter’, since that could be disputed with ‘Dante’ from Devil May Cry.

Taps into two popular genres – The unexplained has always been a compelling subject matter for fiction, and there’s plenty of material to draw inspiration from. Recent trends in television indicate that interest in the paranormal is still alive and well, proven with shows like The X-Files, and more recently Lost, Supernatural, and Medium. Likewise, mystery and criminal investigation (re-popularised by CSI) has remained a compelling setting for drama, particularly when combined with the unknown (such as psychopathology, exemplified by the film adaptations of Thomas Harris’ novels).

Character-driven franchise Rather than a standalone game, the Daemon Noir IP has been strategically designed to support follow-up “adventures”. We have taken the comic-book approach of designing the game premise and universe around a central character rather than a specific concept or setting (e.g. Jurassic Park; Tomb Raider;Bioshock). In the long-term, we believe that a character focus enables us to explore a wider range of adventures without being restricted to a particular setting, genre, or media platform (Miller, 2003). Good examples of this include: Super Mario;Spiderman; James Bond; Tintin; and Doctor Who.

Target Market and Platforms

Due to the subject matter and gameplay, Daemon Noir will focus on the traditional ‘Core’ market of male gamers, aged between 17 and 35. These are gamers identified as enjoying challenging games with moderate to difficult learning curves and a strong emphasis on action, problem solving, and large time investment (20-40 hours)(IGDA. 2006 – Present; CGA. 2007). However it’s hoped that the slightly slower pace and investigation aspect of the game will broaden the appeal slightly, without compromising our target market.

The intended platforms for delivery at this stage are:

  • PC (Microsoft Windows XP/Vista compatible)

  • Microsoft Xbox 360

  • Sony Playstation 3

  • Nintendo Wii (still under consideration)

Historically, the PC market, while arguably in decline, is still most suitable platform for first person shooter games. However, it would be risky not to consider the growing console market as well, especially with recent PC-only titles like Crysis apparently underperforming (Boyer, B. 2007).

The Nintendo Wii is flagged as ‘under consideration’ because it’s still a wild card in the console market. The Xbox360, PS3, and PC are all focused on the traditional ‘core’ market, and therefore represent the most realistic opportunities. In comparison, the target market of the Wii is somewhat ambiguous – it currently has the strongest hardware sales, yet it’s unclear what demographic these gamers represent and whether our game would appeal to them.

PART 2 – PROJECT PROPOSAL

2.1. STAFFING AND MANAGEMENT

Traditional Studio Model

The standard team model used by most of the industry is perhaps the natural choice for an AAA game of this size and scope (Meltzer, M. 2006). Starting with a relatively modest sized team in pre-production, the team headcount dramatically grows during production to cope with the significant demands on content and a strict schedule. For example, Bungie’s Halo 3 development team reportedly doubled from around 65 staff to 120 (SPonG.com, 2005). While this does have the main advantage of keeping the entire development team under a single roof (thus simplifying communication and resourcing, improving team culture, etc), there are several distinct disadvantages to the model.

First, the overheads associated with hiring, supporting, and maintaining a large team are significant. At the bare minimum, each team member requires a competitive salary, office space to work in, and state-of-the-art hardware and software to make the game with. Furthermore, the cost of hiring and relocating new staff is an extremely expensive process (as is firing and replacing staff) – estimated at around $10,000 per person (Seropian, A. 2006). Ultimately, at the height of production, a studio with between 45-120 staff will be spending between $375,000 and $1 million per month (Seropian, A. 2006). With this kind of overhead, it’s not hard to see why next-generation AAA games now cost between $10-20 million to develop (Schoback, K. 2005).

Secondly, large teams lack flexibility and require efficient management processes to be effective (Drake, S.; Seppänen, L. 2007). For example, a large ‘implementing team’ cannot afford to waste time deviating from the original game design to explore potentially more interesting gameplay options (or to correct bad ones) – to do so would be extremely costly. Instead they require a thorough, well-defined GDD; and an extensive list of scheduled tasks to do (Drake, S.; Seppänen, L. 2007). Unfortunately, as Warren Spector points out, game design is an organic process. Ideas change over time; technology constraints demand workarounds; design oversights require documentation redrafts (Spector, W, 2000).

For example, upon realising that their physics engine didn’t work as well as anticipated; the Trespasser team were forced to make drastic last-minute changes to the game design (Wyckoff, R. 1999). Likewise, the development of Deus Ex illustrates how playtesting can reveal fatal flaws in the game design; such as whether or not the core game systems are actually as fun as they sound on paper (Spector, W, 2000). While it’s true that thorough pre-production and early prototyping are clearly critical factors for minimising these oversights, the standard studio approach leaves little margin for error or exploration later on (Meltzer, 2006; Drake, S.; Seppänen, L. 2007).

Lastly, as the production phase winds down, management are left with the problem of what to do with the surplus implementation staff. While large studios are able to transfer inactive personnel to new projects, other studios have to decide whether to keep them or not. In either case, this can be a costly and inefficient use of talented staff, unless the studio manages to establish a sustainable model. For instance, some companies (publisher-developers, typically) maintain a ‘talent pool’ of artists and engineers, allocating them to projects where needed (Meltzer, M. 2006). While this might be an effective allocation of resources, it does cause other problems, such as providing the team with unmotivated staff that are already burnt out from past projects or are simply not interested in the current project (Napier, J, 2000; Spector, W. 2000).

The Small and Agile Approach

An alternative studio model, which we will be adopting, has emerged in recent years alongside the rise of middleware and outsourcing companies. The small and agile approach is based around the idea of forming a small but strong ‘core’ development team. This core team drives the creative vision of the game – including the design, presentation, and gameplay; while external contractors are hired to produce the bulk of the ‘non-gameplay critical’ content on a “need-to-do basis” (Meltzer, M. 2006; Seropian, A. 2006; Drake, S.; Seppänen, L. 2007).

In theory, a smaller team benefits from low overheads and superior management (due to improved communication, flatter hierarchy, and higher motivation), allowing it to respond more swiftly to changes in technology and the market (Meltzer, M. 2006; Seropian, A. 2006; Drake, S.; Seppänen, L. 2007). Indeed, almost by definition, a company utilising an agile production methodology embraces change, and uses it to competitive advantage (Hormozi, A. M. 2001.). As one developer put it, a small studio can “”avoid having to lay down tracks in front of the behemoth,” (Myllyrinne, M; Schoback, K. 2007). While it’s inherently risky, several teams have implemented this model successfully, including Wideload Games (Stubbs the Zombie) and Epic Games (Gears of War) (Schoback K. 2007).

Since we are developing an AAA game for next generation platforms, we will probably have to hire more than Wideload Games’ 12 staff. However, the goal is to avoid the 50+ headcount which drives up the cost of development exponentially; so a team size of around 30 seems like a reasonable compromise. Since we’re only working on one title, the core team comprises of the entire studio (including business, financial, and IT), and will focus on the following areas: game design, art, programming, and production/business management. Everything else will be contracted out (e.g. music and audio).

The Core Team

First, we will be hiring a project director and a professional writer to maintain the creative vision of the project. Likewise, we will be hiring experienced people to lead the art and programming teams. While it’s tempting to let the leads share production responsibilities, there is real a danger of overextending them. We require a dedicated producer, focused on managing the team and keeping the project on track; not someone who is actively involved in development. Otherwise it can lead to awkward situations, as highlighted by the case of Rainbow Six (Upton, B,2000), and Tresspasser:

No lead programmer should be expected to tell their boss that he had better get his work done or take some drastic action to get the project back on schedule.” (Wyckoff,R. 1999).

As for the rest of the staff, we will try to recruit the best possible applicants for the positions available. This is an intentionally vague statement because ‘best’ doesn’t necessarily mean the ‘most qualified’ or ‘experienced’, although those are definitely important factors. Jim Napier (2000) points out that one of the mistakes made on the production of Swat 3 was to underestimate the value of motivated employees over qualified ones. Likewise, GoldenEye 007 producer, Martin Hollis (2004), also stresses that talent, enthusiasm, and “a deep understanding of games” were the most important traits when selecting team members. Ultimately, it seems that it is more important to hire the right people from the very start, with factors like motivation, aptitude, and ‘team fit’ being just as important as qualifications and experience.

While we want to keep the team as lean as possible, the heavy reliance on outsourcing requires some careful management. On the development of “Stubbs The Zombie”, Alexander Seropian (2006) stressed that the lack of producers (on both sides) meant that the tasks of managing and evaluating contractors fell onto their core team – preventing them from doing their actual work. With this in mind, it might be best to hire a producer to manage the core team, and an assistant producer to help supervise the art team with contractor management.

Team management and potential issues

Quality of Life

It should go without saying that maintaining a healthy work-life balance for our employees should be a priority for us. Scheduled time off, regular team events / nights out, and flexible hours are all good practises. Ideally, ‘crunching’ (prolonged overtime to compensate for schedule slips) should be avoided wherever possible. Studies by the IGDA (Robinson, E. 2005; Llopis, N. 2004; IGDA 2004 ) found that the short-term productivity gains from overtime dropped significantly over the course of two months – to the extent where gains were not only cancelled out, but actually lead to negative productivity (further delays). In the short-term, working extreme overtime is not only unhealthy and ethically (if not legally) contentious (we could get sued); but it also drastically increases the likelihood of errors being caused unknowingly (Robinson, E. 2005). It can also cause friction between the team, unless everyone ‘does their part’. The peer pressure on the individual to conform could be considerable (Fristrom, J. 2003).

Unfortunately, in practise, it’s difficult to entirely eliminate crunching – even with extensive use of outsourcing. Almost every post-mortem consulted reported some instance of ‘crunch mode’. At best, we can take conscious steps to minimise it. This starts with a realistic schedule constructed from a thorough, but feasible, game design document (Howie, H. 2005). The key here is staying focused on the core vision: – in other words, resisting ‘feature creep’ wherever possible, and knowing when cuts are necessary (Howie, H. 2005; Spector, 2000). This requires updating the schedule regularly, and ensuring that it’s as accurate as possible so that problems can be spotted early (Howie, H. 2005). While not going as far as adopting a “When it’s done” attitude, some flexibility should be built into the schedule, as a way of anticipating unforeseen problems and delays (meetings, tradeshows, holidays, sick leave, should all be factored in). It’s also essential that the publisher understands and respects this (Howie, H. 2005).

No politics, no egos, no empire building, no nonsense

With a small team, it’s critical that no-one becomes irreplaceable, because it’s likely that some people will leave during the project. Therefore, we cannot afford to let the success of the project hinge on a single person. For example, in the development of both Rainbow6 and Swat3, team leads left or fell ill, causing serious problems for the remaining team who were untrained or too busy to absorb the work (Upton, B. 2000; Napier, J. 2000). To mitigate this, we will encourage self-managing teams and continual training, so that team members are comfortable with taking initiative and organising their own work (Seppänen, L. 2007). Additionally, brief team meetings will be held each week to discuss development progress, goals, ideas, and concerns. The aim will be to encourage open communication, maintain a unified team vision, and give everyone the opportunity to have their voice heard (Drake. S. 2007). Like Remedy and Wideload Games, we believe the decision-making process will be more effective when everyone can meet together in a single room – saving the need for a lot of unnecessary bureaucracy (Seppänen, L. 2007; Drake. S. 2007; Seropian, 2006).

2.2. OUTSOURCING

Outsourcing and contract work plays a fundamental role in our project plan, yet it’s also the most risky (Meltzer, 2006). There are thousands contractors available worldwide, of varying expertise and quality; so careful selection is crucial to avoid problems later during development (Diamante 2007; Seropian, 2006). On the plus side, most contractors charge fixed prices for asset delivery; so there is no additional cost if the schedule slips (compared to a full time employee). Likewise, we can hire additional contractors to cope with increasing production demands; or remove/replace them if they’re not working out as expected (Seropian, 2006).

What to contract out

The first decision to make is what to contract out and what to develop internally. Given that modern AAA games are expected to be content-rich, we will naturally be requiring a lot of additional artwork to be outsourced. This would include characters, scenery, game objects, weapons, and so on. However, our internal art team will be directing the vendors to ensure that the visual style of the game is consistent throughout (Seppänen, L. 2007; Drake. S. 2007; Seropian, 2006).

Levels will be made internally for two reasons:

  • The levels are the game, and we can’t risk the critical success of it falling to a third party.

  • Level architecture requires tight co-ordination with the gameplay designers – this is difficult to manage with external vendors.

Audio is another area we plan to contract out. It should be cheaper to contract a soundtrack than to employ a musician for the entire duration of the project. Likewise, royalty-free sound effects can be purchased from specialist vendors such as the sound-effects-library.com and the BBC.

Voice acting is harder to organise because many actors belong to a union. While non-union talent is cheaper upfront, they tend to lack experience, range, and reliability. As a result, the time saved during casting, recording, and editing makes union talent the more cost-effective option (Borders, C. Case, M. 2003). To make the most of them, we would also require the services of an experienced VO director (Borders, C. Case, M. 2003).

Selection

While cost-cutting is important, quality is still the priority, and there are some important factors to consider when evaluating potential contractors. For example, is the company focused on outsourcing, or do they make their own games as well? As Lasse Seppänen points out, some contractors reserve their best talent for internal projects, and allocate their junior staff to outsourcing projects (Drake, S.; Seppänen, L. 2007). Therefore it’s important to set the standard of quality from the beginning and avoid underbidding (Seropian, A. 2006).

We worked with one art house in particular that … sold us on the A team, but gave us the B team.” (Seropian, A. 2006).

Microsoft Game Studios use a two-phase process which first tests the contractor on quality, and then tests their ability to deliver assets against a tight schedule and to a precise specification (Diamante, V. 2006). However, as well as evaluating asset quality and specification requirements; Remedy Entertainment stress the importance of evaluating the company as a whole. For example, companies which don’t ask questions or send progress updates could indicate problems later on (Drake, S.; Seppänen, L. 2007). Furthermore, to spread the risk, it’s also recommended that several contractors are utilised, in case one of them runs into financial difficulties mid-way through the project (Diamante, V. 2006; Seropian, A. 2006).

Managing contractors

It would be an oversight to expect our outsourcers to work without some kind of supervision. Co-ordinating several design teams across the globe is delicate operation that is likely to hit a few kinks along the road, which, if left unchecked, could snowball into major production bottlenecks.

Successfully managing an outsourcing operation, as with any business relationship, begins with mutual respect and fairness. Microsoft Game Studios’ Art Director, John Wendl, recommends that studios view contractors as “an extended partner, not just a vendor” (Diamante, V. 2006). Problems on both sides, such as unsatisfactory performance and feature creep, should be raised quickly, and dealt with in a professional and fair manner. This extends all the way down the production chain, including small details such as ensuring that external artists have complete ownership of their tasks, from start to finish (Diamante, V. 2006).

The amount of time and resources required to organise and evaluate the assets being sent from vendors can’t be underestimated. On the production side, the most important task to organise from the beginning is to setup an efficient art pipeline, so that an effective feedback loop can be created between the art department and the contractor (Seropian, A. 2006). In ideal circumstances, it might be reasonable to send the outsourcer a development kit and the tools required to test their assets before submitting them (Diamante, V. 2006). Alternatively, we could host the game database online (on a secure private sever), and allow vendors to drop assets directly into the game (Seropian, A. 2006).

This also raises another complication, which is inherent to all virtual teams – the communication barriers created by working across continents puts an enormous strain on scheduling. Time zone differences, language/cultural barriers, and the inability to communicate face-to-face, greatly encumbers the production and create dependency issues. For example, what might take five minutes to explain in person could take an entire day to resolve via email correspondence (Meltzer, M. 2006). Therefore clear communication channels and the availability of up-to-date documentation becomes even more of a priority for the producer. Effective use of the Internet can help mitigate the risk, by using forums, wikis, and instant messenger software (Seropian, A. 2006).

2.3. TECHNOLOGY

With game engine technology, there are two distinct options – license an existing game engine, such Unreal Technology 3; or develop the game engine from scratch. The main reason we’re leaning towards the former is because of the time and cost it would take to build a new engine from scratch (Spector, 2000; Seropian, 2006) (also, see the technology budget in appendix 1). A custom-built engine would give us more control over the game, but we can’t afford to spend over four years developing it (like Max Payne) (Seropian, 2006), especially if the engine is only used for one title (like Trespasser) (Wyckoff R. 1999). Fortunately, to remain competitive, all of the major commercial engines include high-end physics solutions, meaning that we wouldn’t have to licence out Havok or develop our own one. Furthermore, with commercial engines (especially popular ones like Unreal) there is already a surplus of trained developers familiar with the technology.

There are some drawbacks to licensing engine technology, however. Warren Spector (2000) notes that on the development of Deus Ex, initial time saved was spent on learning the ‘foreign’ technology and superfluous content tuning. Furthermore, unfamiliarity with the technology lead to two distinct problems:

  • A tendency to treat the engine like a ‘black box’, leading to performance issues which couldn’t be resolved.

  • A reluctance to modify the engine; instead building on existing game systems which weren’t appropriate to the game they were making.

It’s worth noting that Deus Ex was made between 1997-2000, and familiarity of the Unreal engine has greatly increased since then. The other extreme would be Duke Nukem Forever, in which 3D Realms have reportedly modified the Unreal engine to such an extent over the years that the code is virtually unrecognisable (Planet Duke, 2003). Essentially, the decision to license a commercial engine can only be justified if the time spent tuning it to our game’s requirements is less than the cost of building the engine from scratch. This is something that could hopefully be determined via prototyping; but as the project budget (appendix 1) illustrates, licensing an engine up front seems like the cheaper option for a 2-3 year project.

2.4. SCHEDULING AND LIFECYCLE PLANNING

Traditionally, game production plans tend to be linear, adapting the standard Waterfall model to meet the publisher’s milestones. Unfortunately game design, as we have previously discussed, isn’t a linear process; and the waterfall model isn’t particularly well suited to handling risk, design changes, or unexpected problems (McConnell, S. 1996). As figure 1 illustrates, this can lead to delays and design changes as the team struggles to pull the project back on track.

hp_fig1

Figure 1, Actual Production Process (Hamann, W. 2000-2003)

Risk Oriented Project Lifecycle

Rapid Development author, Steve McConnell, recommends that the project and requirements are carefully considered before choosing a lifecycle model, since different lifecycle models work better than others under different circumstances. Take, for example, Denki’s ‘lateral development’ method (Jordon, J. 2007) (an adaptation of the design-to-schedule approach [McConnell, S. 1996]). In this model, the foundations of the game are built first, and then progressively refined until the project deadline is hit. This model is ideal for shipping fun but ‘not-quite-perfect’ games to a fixed deadline – perfectly suitable for the casual games market. However, in the AAA market, is ‘not-quite-perfect’ good enough to compete against $20million dollar games?

So what the requirements of Daemon Noir? Like many AAA games, our project is very risky, and contains many unknowns which can’t be answered right away. Like Deus Ex (Spector, 2000), it may become necessary to make mid-course corrections during the project — we don’t want to get caught out if our technology or game systems do not work out the way we expected (as in Trespasser)(Wyckoff R. 1999). It will also be necessary to provide our publisher with some kind of visible progress over the course of development.

While it would ultimately be a team decision, the Spiral lifecycle model (Figure. 2) has some distinct advantages – the main one being that it’s geared towards risk-reduction. It works by addressing the most costly risks first, when the project is relatively small (McConnell, S. 1996). As the project grows in size and cost, the risks become progressively smaller. Questions like: “Which engine should we use?”, “Should the game have a multiplayer mode?” and “How many levels are we going to build?” would be answered very early on in pre-production, resulting in a more feasible scope for the game, and therefore preventing the need to make cuts later on.

hp_fig2

Figure 2, Spiral Lifecycle Model (Boehm, B. 1988)

The more time and money you spend, the less risk you’re taking, which is exactly what you want on a rapid-development project.” (McConnell, S.1996).

The adaptive nature of the model also means that opportunistic and exploratory game design can be managed and scheduled in a realistic (and cost-effective) manner, as each development iteration goes through a deliberate process of goal setting, risk analysis, prototyping, and planning. Should the publisher request additions or new features, their impact to the game and the schedule can be objectively analysed before committing development resources.

Lastly, the iterative nature of the model allows us to adopt Hamann’s Critical Stage Analysis (2003). Instead of conducting a post-mortem in hindsight, feedback is requested from the team after each major milestone. Rather than allowing problems to escalate, progress and production issues are addressed before the next development iteration begins.

Meaningful Milestones via Spector’s ‘Proto-Missions’

On the development of Deus Ex, Warren Spector (2000) stresses the value of ‘proto-missions’ as a design and scheduling tool. While it’s important to make milestones meaningful and demonstrate visible progress to our publisher; the proto-mission concept goes further than this. Early on in development, two levels are fully prototyped, ensuring that all of the major game systems are integrated into the game and functional – at least in a basic form. From this point, the team can carefully analyse what works, what doesn’t, what is left to do, and what isn’t feasible. It also gives the team a clear template on how to build future missions, and a good estimate of how long each one will take to finish. Technology expectations and limitations can also be tested at this stage as well. Once all design assumptions are clarified, the GDD and schedule can be amended to resemble a more accurate picture of the game being built.

Again, this is another demonstration of the spiral model in action. The key point here is that the development of the proto-missions would take the duration of a single development iteration, the results of which will ultimately dictate the design and schedule of the rest of the game. In the long run, it’s better to have a flexible but accurate schedule; than to blindly stick to ‘plan a’ regardless of the production issues that come up.

2.5. QUALITY ASSURANCE AND SUBMISSION

It’s important to try and get the game approved by the publisher and console licensor on the first submission – otherwise the game might be delayed by additional testing and bug fixing. Therefore, quality assurance will be undertaken throughout the project, not just at post-production. In particular, there are two main areas to be considered – testing and localisation.

Testing

Testing will be performed on two levels – internally and externally. As we can’t afford an army of full-time testers, it will be up to our existing programming and game design team to document and test their own work. The spiral lifecycle accounts for this with each development iteration going through a discrete phase of planning, development, and evaluation. This should also work to our advantage, since experienced developers will have a better idea of what to test for and when – not all bugs will be high priority, with some merely reflecting the current stage of development. The ‘proto-mission’ concept, for example, is designed to provide the internal team with a clear framework for testing important game systems as early as possible; but it’s given that the game will be in a rudimentary form, lacking key art assets and functionality.

After the project hits significant milestones (beta build, for example), we will contract out a specialised company for more thorough testing. The advantage of outsourcing QA is that these companies have more staff at their disposal; more efficient and systematic testing approaches; and are well versed in testing for console standards and requirements (TRCs) (SQA Partners, 2008). Sony’s memory card operations, for example, can be thoroughly tested for functionality, naming conventions, and translation accuracy – a task which would be overwhelming for a small developer (SQA Partners, 2008). However, the important thing is to try and avoid these issues later on, by planning for them from the beginning.

Localisation and Internalisation

As with testing, we will be contracting an external company to perform the localisation of our game. This covers many areas including:

  • Text and dialogue (UI, subtitles, manual, memory card, etc)

  • Audio (dubbing)

  • Art and video (NTSC/PAL framerate differences; text on art assets; font sizes; interfaces/buttons)

  • Regional (currency, time, date)

  • Cultural sensitivity (public, political, religious, legal issues)

  • Player input (e.g. if the game allows the character naming; the player should be able to do so in their own language)

(Game Localization Network, 2005)

While the process can be left until near the end of development, the entire process can be made much easier on both sides if the developer considers it from the very beginning. Media Sunshine’s Heather Chandler suggests that if the developers begin “considering English as a foreign language” then it’ll put them in the right mindset for organising the code and language assets in a localisation friendly manner (Boyer, B. Alexander, L. 2007).

For example, fonts can drastically increase in size with different languages – in the worst case, requiring an entire redesign of the user interface (Boyer, B. Alexander, L. 2007). Likewise, interface issues, such as PAL/NTSC framerate synchronisation, and more recently SDTV/HDTV differences can be critical to the game experience. For example, Capcom’s Dead Rising has received considerable criticism from customers because on an SDTV the in-game text is reportedly illegible, and therefore making the game incredibly difficult to play. What is perhaps inexcusable is that, according to Capcom, an issue like this is impossible to patch due to the enormity and complexity of the task (Kuchera, B, 2006).

Lastly, cultural sensitivity is especially important (Boyer, B. Alexander, L. 2007). Without dwelling on the issue too much, Resistance: Fall of Man and Manhunt2 are recent examples where some professional awareness could have prevented a public backlash. To spend millions on producing a game, only to have it banned in most major continents is not gamble worth taking. Therefore Chandler recommends that developers conduct a full audit of all culturally ambiguous content before submitting the game (Boyer, B. Alexander, L. 2007).

PART 3 – APPENDICES

APPENDIX 1: PROJECT BUDGET

A.1.1. CORE STAFF AND OVERHEAD

As explained in the staffing chapter, we are shooting for a core development team of around 30 staff, broken down into design, art, programming, and project/business management. This is relatively lean to keep our yearly overhead down (operating costs, salaries, etc), as the following table illustrates.

Description

Budget

Team salaries and equipment (computers, desks, etc)

Game design 6 (avg. Salary $62,000):

Visual Arts 9 (avg. Salary $65,000):

Programming 9 (avg salary $81,000):

Project / Business Management 6 (avg $77,000):

Subtotal:

$372,000

$585,000

$729,000

$462,000

$2,148,000

Monthly burn:

$179,000

12 Months:

$2,148,000

24 Months:

$4,296,000

36 Months:

$6,444,000

  Cost of three-month slip

$537,000

Cost of six-month slip

$1,074,000

Recruitment and relocation:

$10,000 per person

$300,000

Subtotal (36 months):

$6,744,000

20% margin for insurance, taxes, and unexpected costs:

$1,348,800

  Development total: (36 months)

$8,092,800

These figures based on: Seropian, 2006; Gilbert 2004, Duffy 2007.

Team salaries are based on industry averages reported by the 2007 games industry salary survey (Duffy, J, 2007). The yearly margin is included to cover unexpected costs (accidents, damages, illness).

A.1.2. TECHNOLOGY

Unfortunately, in the majority of cases, most companies will only discuss pricing under a non-disclosure agreement (NDA) with other established development companies. The two exceptions are id Software’s ‘idTech 4’ ($250,000 guarantee against 5% royalty) and Touchdown Entertainment’s Jupiter engine (between $15,000 – $95,000 depending on package options). In a legal dispute between Silicon Knights and Epic Games, the licensing cost for Epic’s Unreal Technology 3 was indirectly revealed to be around $750,000 (plus royalties) (Carless S.; Boyer, B. 2008). Our estimate is based on this figure, combined with Epics terms for licensing Unreal Technology 2 ($350,000 per title, plus $50,000 per additional platform, plus 3% royalty).

As previously stated, we will be going for option 1; however, the estimated cost of the in-house option is included for comparison. The figures for developing the in-house engine are based on the estimated overhead incurred by an additional two years development (just over $4m). In addition, while all the major licensed engines include their own physics solution, a custom built engine would certainly need to license one, such as Havok. Again, the actual price of this is undisclosed, but for budget purposes, it is presumed to be around a third the cost of licensing a complete game engine.

Description

Option 1: Licensed Engine

Option 2: In-House Engine

Game Engine (single title, multiplatform license)

Viable options:

  • Unreal Engine 3 (Epic Games; Unreal Tournament 3, Gears of War)
  • Source (Valve Software; Half-Life 2)
  • idTech 4 (id Software; Doom 3, Prey)
  • JupiterEx (Touchdown Entertainment; F.E.A.R)
  • CryENGINE (Crytek; Crysis, Farcry2)
  • Between $95,000 – $750,000
  • Plus 3- 5% royalty of wholesale price (minus COGs) on all revenue from the game.
  • Plus $50,000 – $100,000 per additional platform
  • Plus 2 years development
  • Plus additional programmers & testers

Physics Solution

Options:

  • Havok Physics
  • AGEIA PhysX
  • Unreal 3: AGEIA PhysX
  • Source: Havok
  • idTech 4: Internal
  • JupiterEx: Internal
  • CryENGINE: Internal

Havok Physics – Undisclosed, Budget: between $125,000 – $250,000

AGEIA PhysX – Free

Subtotal:

Between $150,000 – $600,000

Plus 3-5% royalties

2 years additional salaries ($4.2m)

Plus $0 – $250,000 on physics solutionGame Technology Budget:$750,000, plus royalties up to 5%Around $4,500,000

A.1.3. SOFTWARE

Ultimately, the team would determine the specific software required; however this list attempts to identify the major options (e.g. art, programming, project management, etc), plus a small margin for additional software. Consistent figures for multi-user licenses are currently unavailable (pending discussions with vendor representatives), so these figures are based on single-user licenses unless otherwise specified.

Description

Budget

3D Art Package (For models and animation)

  • Option 1. Autodesk 3DS Max 2009 (10)

3DS Max: $3,495 per license

= $34,950

  • Option 2. Autodesk Maya (10)

$1,995 – $4,995 per license

= $19,950 – $49,950

2D art package (textures, hud, menus, & misc 2d art)

  • Adobe Photoshop CS3 (10)

$650 per license

= $6500

Integrated Development Environment (IDE) (for programming)

  • Microsoft Visual Studio Pro (10)

$689.99 per license

= $6899

Word processing, spreadsheets, database, etc.

  • Microsoft Office (30)

$324.99 per license

= $9750

Project Management software (Gantt charts, task tracking, resource management, etc)

  • Option 1. Microsoft Project (2-4)

$500 per license

= $1000 – $2000

  • Option 2. Microsoft Visio (2-4)

$210 per license

= $420 – $840

Wiki software (online documentation, etc):

  • e.g. Atlassian Confluence

$2200 (25 users)

Plus $2200 36 Month Maintenance Period

Bug Tracking Software:

  • e.g. Atlassian JIRA

$2400 (Professional)

Plus $2400 36 Month Maintenance Period

Additional Software Budget

$15,000

Subtotal

Between $68,719 – $99,299

Total Software Budget

$100,000

A.1.4. CONTRACT WORK AND OUTSOURCING

Description

Budget

Art Outsourcing

  • Characters
  • Animation & Mocap
  • Vehicles
  • Game objects / scenery
  • Weapons
  • Menus

$2,000,000

QA Testing

  • Game engine and stability
  • Front end and UI
  • Gameplay and AI playtesting
  • Console compliance checks (TRC and TCR)

$100,000

Audio

  • Music
  • Sounds
  • Voice acting (union)
  • Voice recording

$100,000 – $200,000

Localisation

  • Game text
  • Subtitles
  • UI
  • Art
  • Audio dubbing
  • Manual / packaging

$100,000 – $200,000

  Business / Legal

$50,000-100,000

Subtotal:

$2,600,000

As there are no reliable figures for outsourcing publically available, these figures are estimated based on the work required. In practise, our team would draw up a list of assets to be outsourced during pre-production, and then approach contractors for pricing quotes. QA testing, and localisation are further unknowns, but text translation is typically charged between $0.10 – $0.15 per-word, with AAA action games like BioShock containing around 60,000+ words. RPGs with an emphasis on dialogue and storytelling, such as Mass Effect, are estimated to have around 400,000 words ($60,000) (Boyer,B. Alexander,L. 2007). Combined with multiple language support, voice dubbing, text, subtitles, user-interface, etc, the localisation costs will undoubtedly add up, therefore a budget of $200,000 seems prudent.

A.1.5 TOTALS AND PROFIT MARGIN

Totals

Budget (in USD)

Development total (Staff Overhead)

$8,092,800

Technology

$750,000

Software

$100,000

Contract Work

$2,600,000

Grand Total

$11,542,800

The publisher will not pay for the cost of development; they will simply provide us ‘advances’ which will be ‘recouped’ back after the game goes to retail (Charne, J. 2003; Gilbert, R. 2004; Miller, 2003; UKTI, 2007). Therefore, any funds they ‘loan’ us will be paid back in full (via our royalty stream) before we receive any profit. As a result, our royalties will need to exceed $11.5 million before we receive any profits from the game.

hp_fig3

Game retail revenue splits (UKTI, 2007)

The above table demonstrates the typical revenue split of a console game. Based on these figures, if the publisher pays $11,500,000 advance, and we get $5.40 royalty per game sold (about 20%), then:


Publisher Break even units 737,180 (approx)

Developer break even units 2,129,630 (approx)

As these (very rough) figures show, unless we self-fund a good portion of development upfront, the game would have to sell extremely well to make us a profit (i.e. over 2m units). Clearly, we would have to fund at least a third of development upfront (i.e. pre-production), or find an alternative/additional funding source from publishers, such as a venture capitalist or game production company like the Radar Group. Unfortunately, it seems that the VC route isn’t really reliable:

When it comes to venture funding, the have’s don’t need it, and the have-not’s can’t get it. … for most independent developers, venture capital is an enormous long shot. The state lottery is a more reliable source of funding.” (Miller, 2003)

APPENDIX 2: SCHEDULING EXAMPLES

A.2.1. NOTES

The examples that follow represent a snapshot of the overall project schedule. Specifically they focus on level design, and represent how the art and gameplay teams would work in tandem to develop two ‘proto-missions’. Since gameplay can only be implemented after the levels have been constructed (at least partially), one notable feature of this schedule is how the tasks become staggered slightly between the art and gameplay teams (i.e. the art team starts level 2, while the gameplay team are still wrapping up level 1). The challenge here is ensuring that everyone remains engaged and contributing meaningful work to the project.

The examples also demonstrate how outsourcing might be factored into development, with asset delivery represented as recurring weekly milestones. In this example, part of the art team would be responsible for specifying the contract work required, and then evaluating and preparing the delivered assets for the level designers.

Lastly, everyone on the team will have at least 4-5 weeks paid vacation time, so this has to be factored into the schedule as well. The following examples demonstrate how scheduled time off (in this case, the Christmas vacation) affects the overall schedule.

hp_fig4hp_fig5hp_fig6

APPENDIX 3: GAME INDEX

Development, publishing, and release data collected from mobygames.com and wikipedia.org

Alan Wake – Remedy Entertainment Ltd, Microsoft Game Studios, TBD

BioShock – 2K Boston/2K Australia (formerly Irrational Games); 2K Games (Take-Two), 2007

Call of Duty 4: Modern Warfare – Infinity Ward, Inc., Activision Publishing, Inc., 2007

Condemned: Criminal Origins – Monolith Productions, Inc., SEGA of America, Inc., 2006

Crysis – Crytek GmbH, Electronic Arts, Inc., 2007

Dead Rising – Capcom Co., Ltd., Capcom Entertainment, Inc., 2006

Deus Ex – Ion Storm, Eidos, 2000

Devil May Cry – Capcom Production Studio 4, Capcom Entertainment, Inc., 2001

Doom – id Software, Inc., id Software, Inc., 1993

Duke Nukem 3D – 3D Realms Entertainment, GT Interactive Software Corp., 1996

Duke Nukem Forever – 3D Realms Entertainment, Take Two Interactive, ‘WID’

F.E.A.R.: First Encounter Assault Recon – Monolith Productions, Inc., Vivendi Universal Games, Inc. 2005

Gears of War – Epic Games, Inc., Microsoft Game Studios, 2006

GoldenEye 007 – Rare, Ltd., Nintendo of America Inc., 1997

Half-Life – Valve L.L.C., Sierra On-Line, Inc., 1998

Half-Life 2 – Valve Corporation, 2004

Halo 3 – Bungie Studios, Microsoft Game Studios, 2007

Indigo Prophecy / Fahrenheit – Quantic Dream, Atari, Inc., 2005

Manhunt 2 – Rockstar Vienna, London, North, Toronto, Leeds; Rockstar Games

Max Payne – Remedy Entertainment Ltd, 3D Realms, Take-Two/God Games 2001

Phoenix Wright: Ace Attorney – Capcom Co., Ltd., Capcom Entertainment, Inc. 2005

Portal (The orange box) –Valve Corporation, 2007

Resident Evil – Capcom Co., Ltd., 1996

Resistance: Fall of Man – Insomniac Games, Inc., Sony Computer Entertainment America, Inc., 2006

Stubbs the Zombie in Rebel Without a Pulse – Wideload Games, Inc., Aspyr Media, Inc., 2005

SWAT 3: Close Quarters Battle – Sierra On-Line, Inc. 1999

Super Mario 64 – Nintendo EAD, Nintendo of America Inc., 1996

System Shock 2 – Irrational Games (presently: 2K Boston/2K Australia), Looking Glass Studios, Inc., EA, 1999

The Elder Scrolls III: Morrowind – Bethesda Softworks LLC, 2002

Thief: The Dark Project – Looking Glass Studios, Inc., Eidos Interactive, Inc. 1998

Tom Clancy’s Rainbow Six – Red Storm Entertainment, Inc. 1998

Tomb Raider – Core Design Ltd., Eidos Interactive, Inc., 1996

Trespasser: Jurassic Park – DreamWorks Interactive L.L.C., EA, 1998

Unreal – Digital Extremes, Epic MegaGames, Inc.; GT Interactive Software Corp., 1998

Virtua Cop – AM R&D Dept. #2, SEGA Corporation, 1997

Wolfenstein 3D – id Software, Inc., Apogee Software, Ltd.,1992

PART 4 – REFLECTIVE LOG

Early stages – Semester 1 2007

Semester 1 was mostly spent drafting an initial game concept for the project, gathering initial research material, and revising the main areas of game production. As I settled on a topic for my dissertation (honours project 1), it became fairly obvious that I should co-ordinate the two so that I could share the research. However, this made the project conceptually more complicated than perhaps it ought to have been.

My dissertation revolves around a production model called the ‘Small and Agile’ approach (among other names), which theoretically allows smaller studios develop bigger games. As a result it seemed appropriate that my game project should adopt this model as well. However, the main problem with this model is that it’s extremely high risk, and success hinges on careful management of the team and contractors, plus a very clear and focused game design. As a result, the biggest challenge early on was coming up with a compelling game concept which had AAA potential, but was still feasible for a team of 30.

Initial ideas and dead ends – December 2007 – January 2008

After brainstorming and throwing away several ideas, I eventually settled on an FPS-adventure hybrid along the lines of Deus Ex and System Shock2. As I’d been playing Phoenix Wright over the Christmas vacation, I was interested in the idea of criminal investigation as game concept. However, the original concept was much darker – something along the lines of Manhunter and Se7en. You would play a profiler for the FBI, assigned to track down and stop a deranged serial killer before he strikes again. Gameplay would revolve around investing bizarre crime scenes, piecing together clues, and setting traps for the killer – all leading up to a violent confrontation with the killer himself.

While I think the idea had potential, I was having serious problems fleshing out the gameplay (e.g. is crime scene analysis actually fun? If there’s only one serial killer, what other enemies/obstacles do you face during the levels?). It was around this point I became aware of Monolith Productions’ Condemned: Criminal Origins and Condemned 2: Bloodshot. Disappointingly, a quick run of the demo was more than enough to convince me that I had to rethink my game concept. While there were some subtle differences in execution; the basic premise, visual style, and emphasis on investigation and close-quarters combat were exactly the same. Ultimately, it would have been impossible to sell my game convincingly as anything other than a clone of Condemned.

While I didn’t want to drop the basic premise of the game, I realised that I had to distance myself from the Condemned series in style and setting. After trying a few alternatives, I eventually moved the concept away from Manhunter and closer towards Supernatural and The Ninth Gate – you’d now play a private detective who investigates the paranormal and the occult. To make the game more interesting for gaming, I kept the hunting element and expanded on the supernatural / gothic horror theme. This lead to the idea that the combat should be slower paced and integrated with problem solving. Thanks to popular fiction, the idea that certain monsters can only be defeated with unique weaponry (e.g. vampires: garlic, sunlight, stakes, crosses, etc) worked well for gameplay and makes sense conceptually.

Research and key case studies – January – February 2008

Once I had settled on the idea of developing a first person ‘adventure’ game, it became clear which case studies I should be looking for:

  • FPS games which tried to be innovative or buck the trend

  • Large games by very small developers

  • Any other standout / innovative games

Of these, the most interesting and useful were:

  • Deus Ex

  • Trespasser

  • Stubbs the Zombie

  • Rainbow 6

  • Swat 3

  • Indigo Prophecy / Fahrenheit

  • System Shock 2

  • BioShock (extracts)

  • Goldeneye 007

  • No One Lives Forever

In particular, Deus Ex and Trespasser were interesting games to compare because both were very similar in their ambitions and scope, yet they each took different paths, resulting in success for Deus Ex and disaster for Trespasser. Stubbs the Zombie was a useful post-mortem because it raised numerous issues concerned with successfully implementing the small and agile approach – particularly concerning the management of contractors.

Industry visits – February – March

Between February and March 2008, we were visited by a number of industry professionals from local games companies. Of particular interest to my project were Colin MacDonald from Realtime Worlds and Colin Anderson from Denki Games.

Realtime Worlds are the antithesis of the ‘small and agile’ approach – they’re a large developer with three offices worldwide (Dundee, USA, and Korea), hiring over 195 staff, which allows them to work on several projects in tandem. They’re also very successful – their debut title Crackdown sold over 1.5m copies within 6 months and won numerous awards, including two Baftas. Naturally I was interested to learn how they manage the well documented weaknesses of the traditional studio model, such high overheads and the staff transition between projects.

Unfortunately my conversation with Colin MacDonald was all too brief, but what I did learn was that studios of their size can mitigate these problems by staggering the development of projects, so that as one project hits the post-production phase, another moves into pre-production. My overall impression from both Colin and Russell Murray the following month, was that the traditional ‘large studio model’ can be maintained effectively, but it requires an incredible level of management organisation and control. Given this, I found it a little surprising to hear that they’re using an Agile development methodology, but nevertheless, it appears to be working for them.

The most striking part of Colin Anderson’s talk, besides claims that the staff at Denki rarely work overtime, was the concept of ‘lateral’ development. Developed from the background of print media (where the press absolutely have to hit their monthly deadlines), he likened their production process to the construction of housing property – they start from the foundations and work up from there. Though impressed, I was sceptical that the ‘lateral’ kind of model would work for an AAA game. Fortunately I managed to find an interview on Gamasutra which elaborates a bit further:

“People often tell us, ‘That only works because you’re working on such technically limited platforms’, but we know that’s a lot of crap,” he argues. “Recently we produced an internal PC demo as a way of determining the potential scale of our future casual game titles, and the result was stunning in an unbelievably short amount of time. It seems like all our practice on short interactive television products has left us in good shape for tackling some of the larger formats again. I’m really looking forward to the challenge.” (Jordan, J. 2007)

After a bit more research, I realised that the ‘lateral’ model is not too dissimilar to the ‘design to schedule’ lifecycle discussed in Rapid Development. The main disadvantage of this approach is that time and cost are prioritised ahead of quality; and while I definitely think the model has potential (especially in maintaining a realistic schedule and minimising overtime), I’m not 100% comfortable with cutting back polish and QA on a $10m game – especially if it’s trying to compete with titles that cost double that.

Scheduling and Budgeting – April

Once all the research was collected, final tasks included scheduling and budgeting. The example schedule I devised was based on my past experience working in level design for Max Payne mods. In essence, it represents the complete development of two ‘proto-missions’ – almost an entire development iteration. In particular, I wanted to highlight the dependencies between level design and gameplay scripting, and also demonstrate how outsourcing would factor into the schedule. Some notable features of the schedule include the fact that the two processes (art and gameplay) can’t be synchronised easily – gameplay designers generally have to wait for the artists to finish designing the levels before they can start working on them. As a result, it becomes a difficult balance to keep all members of the team engaged in meaningful work.

To create a semi-accurate budget, I drew up a shopping list of likely software, technology, staff, and contractors I thought were necessary for the project (given the limitations I had set, such as a small team). I tried to be as accurate as possible by looking up available data on average developer salaries, engine & middleware licensing costs, and so on; but in some cases there were gaps where I had to take an educated guess. Unfortunately outsourcing is one of those areas because, in most cases, pricing details are negotiated between the developer and the vendor. While the same is true for licensing games engines, I found enough data to come up with a ballpark figure (largely thanks to the legal dispute between Silicon Knights and Epic Games). In contrast, I’m confident that my staff overhead figures are not only accurate, but clearly demonstrate the benefit of maintaining a low overhead. I wouldn’t be surprised if companies like Realtime Worlds and Bungie are spending over five times the amount per year. This effectively forces them into a tight development window, because you can only spend so much before the game becomes unprofitable.

Overall, the grand total of around $11.5 million was slightly more than I was expecting ($10m), but that’s largely due to the 3 year development time. What I wasn’t expecting was how disappointing the profit margin was, in spite of everything. The way the publisher’s advances system works, at a 20% royalty the game would have to sell over 2,000,000 units before we broke even. Given that the majority of AAA titles sell between $1-2 million units, this was a pretty disappointing revelation. However this does confirm the findings by the UKTI (2007), and reflects the reality that most small independent game developers are struggling to survive.

PART 5 – REFERENCES AND BIBLIOGRAPHY

Anon. 2007. 2006 Game developer salary survey reveals industry trends [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=13352 [Accessed on May 8, 2008]

Barrow, C., et al. 2005. Enterprise Development, [s.l.]: Thomson Learning pp109-112

Boehm, B. 1988. A Spiral Model of Software Development and Enhancement. Computer. 21 (5), pp. 61-72.

Borders, C. Case, M. 2003. GDC 2003: The seven secrets of voice-over production [online] Gamasutra. Available from: http://www.gamasutra.com/gdc2003/features/20030307/borders_01.htm [Accessed on May 8, 2008]

Boyer, B; Nutt, C. 2008. DICE Keynote: EA’s Riccitiello On A New Future For Publishing [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=17313 [Accessed on May 1, 2008]

Boyer, B. 2007. Analysts: Wii to top 1.7m in December, high requirements hurt Crysis [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=16653

[Accessed on May 1, 2008]

Boyer, B., Carless, S. 2008. Epic, Silicon Knights Clash Over Access To Engine [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=17121

[Accessed on May 1, 2008]

Boyer, B. Alexander, L. 2007. MIGS: Media Sunshine’s Chandler talks localization from the inside out [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=16410

[Accessed on May 1, 2008]

Brodbeck, P.W. 2002. Implications for organization design: teams as pockets of excellence. Team Performance Management: An international journal. 8 (1/2), pp. 21-38.

Bungie, LLC. 2007. The History of Bungie. [online] Bungie.net. Available from: http://www.bungie.net/Inside/content.aspx?link=HistoryofBungie_p8 [Accessed May 1, 2008]

Carless, S. 2006. Exclusive: Epic Announces Epic China Outsourcing Division [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=10971

[Accessed on May 8, 2008]

Carmel, E., Sawyer, S. 1998. Packaged software development teams: what makes them different? Information Technology & People. 11 (1), pp. 7-19.

CGA. 2007. The casual games industry summary 2007 [online] casualgamesassociation.org Available from: http://www.casualconnect.org/newscontent/11-2007/CasualGamesMarketReport2007_Summary.pdf [Accessed on March 22, 2008]

Charne, J. 2003, Famous last words: settle a bet [online] IGDA. Available from: http://www.igda.org/columns/lastwords/lastwords_Oct03.php [Accessed on May 1, 2008]

Cifaldi, F., 2006. Telltale tells all (pt. 2) – hit by the business end of the rabbity-thing [online] Gamasutra. Available from: http://www.gamasutra.com/view/feature/1854/telltale_tells_all_pt_2__hit_.php [Accessed on May 1, 2008]

Costikyan, G. 2006. Games, genres, and why independent games are vital [online] Texas Independent Games Conference. Available from: http://www.costik.com/presentations/texasindie06.ppt [Accessed on May 1, 2008]

Crawford, C. 2006. Video Games are Dead: A Chat with Storytronics Guru Chris Crawford. [online] Gamasutra. Available from: http://gamasutra.com/features/20060612/murdey_01.shtml [Accessed May 1, 2008,]

Drake. S. 2007. The small and agile approach [online] The Escapist. Available from: http://www.escapistmagazine.com/articles/view/issues/issue_109/1332-The-Small-And-Agile-Approach [Accessed May 1, 2008]

Diamante, V. 2006. GDC: Successful outsourcing on AAA games [online] Gamasutra. Available from: http://www.gamasutra.com/features/20060323/diamante_01.shtml [Accessed on May 1, 2008]

Diamante,V. 2006. Game outsourcing summit: anatomy of an outsourcing deal [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=10523 [Accessed on May 8, 2008]

Duffy, J. 2006. Are you in demand?: 2006 Game industry salary survey [online] gamecareerguide.com. Available from: http://gamecareerguide.com/features/266/index.php?cid=GCG06_ENDEX3 [Accessed on May 8, 2008]

Duffy, J. 2007. Game industry salary survey 2007 [online] gamecareerguide.com. Available from: http://www.gamecareerguide.com/features/416/the_game_industry_salary_survey_.php [Accessed on May 8, 2008]

Duguay, C. R., Landry, S., Pasin, F. 1997. From mass production to flexible/agile production. International Journal of Operations & Production Management. 17 (12), pp. 1183-1195.

EA_spouse’. 2004. EA: The Human Story.[online] Available from: http://ea-spouse.livejournal.com/274.html [Accessed May 1, 2008]

Epic Games, Inc., 2007, Unreal technology [online] unrealtechnology.com. Available from: http://www.unrealtechnology.com/licensing.php?ref=terms [Accessed on May 1, 2008]

Ford, S. 2006. What’s wrong with the games industry (and how to make it right) [online] Gamasutra. Available from: http://www.gamasutra.com/view/feature/1804/whats_wrong_with_the_games_.php?print=1 [Accessed on May 1, 2008]

Fristrom, J. 2003. Manager in a strange land: Crunch [online] Gamasutra. Available from: http://www.gamasutra.com/features/20040123/fristrom_pfv.htm [Accessed on May 8, 2008]

Game Localization Network Ltd. 2005. Internationalisation – information for developers [online] gamelocalisation.net. Available from: http://www.gamelocalisation.net/localization_internationalization_s.html [Accessed on May 8, 2008]

Gilbert, R. 2004. The economics of a 2D adventure in today’s market [online] Grumpy Gamer. Available from: http://grumpygamer.com/4904226 [Accessed on May 1, 2008]

Heir M. 2008. Design Lesson 101 – Condemned: Criminal Origins [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=18360 [Accessed on May 8, 2008]

Hamann, W. 2003. Goodbye postmortems, hello critical stage analysis [online] Gamasutra. Available from: http://www.gamasutra.com/resource_guide/20030714/hamann_pfv.htm [Accessed on May 1, 2008]

Hollis, M. 2004. The Making of GoldenEye 007 [online] Zoonami. Available from: http://www.zoonami.com/briefing/2004-09-02.php [Accessed on May 8, 2008]

Hormozi, A. M. 2001. Agile manufacturing: the next logical step. Benchmarking: An International Journal. 8 (2), pp. 132-143.

Howie, H. 2005. Making great games in 40 hour weeks [online] Gamasutra. Available from: http://www.gamasutra.com/features/20050131/howie_pfv.htm

[Accessed on May 8, 2008]

id Software. 2008. Technology licensing [online] idsoftware.com. Available from: http://www.idsoftware.com/business/idtech4/ [Accessed on May 8, 2008]

Ip, B., Jacobs, G. 2006. Quality in the games industry: an analysis of customer perceptions. International Journal of Quality & Reliability Management 23 (5), pp. 531-546.

IGDA, 2004, Quality of life white paper,[online], IGDA.org. Available from: http://www.igda.org/qol/whitepaper.php [Accessed on May 1, 2008]

IGDA 2006 – Present. Casual Games SIG/Whitepaper [online] IGDA. Available from: http://www.igda.org/wiki/Casual_Games_SIG/Whitepaper [Accessed on March 22, 2008]

IGN 2008. The official Duke Nukem Forever faq [online] Planet Duke. Available from: http://www.planetduke.com/duke4/faq/ [Accessed on May 8, 2008]

Jin-Hai, L., Anderson, A.R. and Harrison, R.T. 2003. The evolution of agile manufacturing,

Business Process Management Journal, 9 (2), pp. 170-89.

Jordan, J. 2007. Interview: On Denki’s stealth success [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=13147 [Accessed on May 1, 2008]

Keith, C. 2007. No silver bullet [online] Agile Game Development. Available from: http://www.agilegamedevelopment.com/2007/06/no-silver-bullet.html [Accessed on May 1, 2008]

Kuchera, B, 2006. Capcom to Dead Rising customers: if you can’t read the text, you’re just out of luck [online] ars technica. Available from: http://arstechnica.com/journals/thumbs.ars/2006/9/12/5264 [Accessed on May 8, 2008]

Llopis, N. 2004. All work no play, makes Jack a dull game developer (part 2) [online] Games from Within. Available from: http://www.gamesfromwithin.com/articles/0412/000056.html [Accessed on May 8, 2008]

McConnell, S. 1996. Rapid development: taming wild software schedules, Microsoft Press pp. 133-161

McGuire, R. 2006. Paper Burns: Game Design With Agile Methodologies [online] Gamasutra. Available from: http://www.gamasutra.com/features/20060628/mcguire_01.shtml [Accessed on May 1, 2008]

McMaster, J. 2006. The Miller’s Tale: 3D Realms’ Scott Miller [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=17313 [Accessed on May 1, 2008]

Meltzer M. 2006. Team & corporate structure: is the standard way, the best way? [online] Gamasutra. Available from: http://www.gamasutra.com/features/20060303/meltzer_01.shtml [Accessed on May 1, 2008]

Microsoft Corporation 2008. Globalization step-by-step: establishing localization guidelines [online] Microsoft.com. Available from: http://www.microsoft.com/globaldev/getwr/steps/localization/loc_est_loc_gls.mspx [Accessed on May 8, 2008]

Microsoft Corporation 2008. Designing a World-Ready Program – Introduction [online] Microsoft.com. Available from: http://www.microsoft.com/globaldev/getwr/DesignWRProg/default.mspx [Accessed on May 8, 2008]

Miller,S. 2003, Royal Tease, [online] Game Matters. Available from: http://dukenukem.typepad.com/game_matters/2003/12/royalties_and_a.html [Accessed on May 1, 2008]

Miller, S. 2004, Contract deal points, [online] Game Matters. Available from: http://dukenukem.typepad.com/game_matters/2004/01/contract_deal_p.html [Accessed on May 1, 2008]

Miller, S. 2003, Max Payne: the making of a franchise, [online] Game Matters. Available from: http://dukenukem.typepad.com/game_matters/2003/11/max_payne_the_m.html [Accessed on May 1, 2008]

Miller, S. 2003, Non-venture funding, [online] Game Matters. Available from: http://dukenukem.typepad.com/game_matters/2003/12/nonventure_fund.html [Accessed on May 1, 2008]

Miller, S. 1998, G.O.D.’s Ten Developer Commandments, [online] IGDA. Available from: http://www.igda.org/articles/smiller_commandments.php [Accessed on May 1, 2008]

Miller S. 2004, Going once… going twice… sold!,[online] Game Matters. Available from: http://dukenukem.typepad.com/game_matters/2004/03/going_once_goin.html [Accessed May 1, 2008]

Miller S, 2008. Does the game industry need a radar? [online] Radar Group. Available from: http://www.radargroup.com/blog.html [Accessed on May 1, 2008]

Napier, J. 2000. Postmortem: Sierra’s Swat3 close quarters battle [online] Gamasutra. Available from: http://www.gamasutra.com/features/20060303/meltzer_01.shtml [Accessed on May 1, 2008]

National Instruments Corporation., 2006. Lifecycle Models [online] zone.ni.com. Available from: http://zone.ni.com/reference/en-XX/help/371361B-01/lvdevconcepts/lifecycle_models/ [Accessed on May 8, 2008]

NaturalMotion, 2008. NaturalMotion euphoria [online] Gamasutra. Available from: http://www.naturalmotion.com/euphoria.htm#video [Accessed on May 1, 2008]

Nutschan, C. 2008; Boehm, 1988. Spiral Model [diagram] Wikipedia. Available from: http://en.wikipedia.org/w/index.php?title=Image:Spiral_model_%28Boehm%2C_1988%29.png&oldid=204286386 1

Nutt, C. 2008. Under the radar with Raphael van Lierop [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=17922 [Accessed on May 1, 2008]

Pelit Magazine, 2006, Birth Process Of Alan Wake.[online] Available from: http://www.alanwake.com/forum/showpost.php?p=18698&postcount=1 [Accessed May 1, 2008]

Philip, B. 2006, How important are independents? [online] Game Matters. Available from: http://dukenukem.typepad.com/game_matters/2006/04/how_important_a.html [Accessed on May 1, 2008]

Rees, E., Fryer, L. 2003. IGDA business committee – best practices in quality assurance/testing [online] IGDA. Available from: http://www.igda.org/qa/docs/IGDA_Best_Practices_QA.pdf [Accessed on May 8, 2008]

Robinson, E. 2005. Why crunch mode doesn’t work: 6 lessons [online] IGDA. Available from: http://www.igda.org/articles/erobinson_crunch.php [Accessed on May 8, 2008]

Roch, S. 2004. The New Studio Model [online] Gamasutra. Available from: http://www.gamasutra.com/view/feature/2155/the_new_studio_model.php [Accessed on May 1, 2008]

Rogers, D, L. 2004. The end game: How top developers sold their studios part one [online] Gamasutra. Available from: http://www.gamasutra.com/features/20040303/rogers_pfv.htm [Accessed on May 1, 2008]

Roper, C. 2008, Scott Miller Interview [online] IGN. Available from: http://pc.ign.com/articles/860/860147p1.html [Accessed on May 1, 2008]

Ross, E. M. 1994. The twenty-first century enterprise, agile manufacturing and something called CALS. World Class Design to Manufacture. 1 (3), pp. 5-10.

Schoback, K. 2005. The economics of a next-gen game [online] IGDA. Available from: http://www.igda.org/biz/GDC05_NextGenEconomics.ppt [Accessed on May 1, 2008]

Schoback K. 2007. Nordic: Remedy’s Myllyrinne on large games from small teams [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=13988 [Accessed on May 1, 2008]

Schoback K. 2007. GDC China: Epic’s Meegan talks gears of war outsourcing [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=15279 [Accessed on May 1, 2008]

Seropian, A. 2006. Postmortem: Wideload Games’ Stubbs the Zombie [online] Gamasutra. Available from: http://www.gamasutra.com/view/feature/1846/postmortem_wideload_games_stubbs_.php?print=1 [Accessed on May 1, 2008]

Seppänen, L. 2007. The future of innovative studios: team and tools behind Alan Wake [online]. Available from: http://shinyidol.spaces.live.com/blog/cns!3323B4AFE60951C5!174.entry?_c=BlogPart [Accessed May 1, 2008]

Sound Effects Library 2008. Sound-effects-library.com [online] sound-effects-library.com. Available from: http://www.sound-effects-library.com/index.asp [Accessed on May 8, 2008]

Sound Ideas. 2007. The BBC sound effects library – original series [online] sound-ideas.com. Available from: http://www.sound-ideas.com/bbc.html [Accessed on May 8, 2008]

Spector, W. 2000. Postmortem: Ion Storm’s Deus Ex [online] Gamasutra. Available from: http://www.gamasutra.com/features/20001206/spector_01.htm

[Accessed on May 1, 2008]

SPOnG.com Limited., 2005. Bungie doubles Halo resources for Xbox 2 debut – movie-like experience promised. [online] SPOnG. Available from: http://news.spong.com/article/8414 [Accessed on May 8, 2008]

SQA Partners Ltd, 2008. Games testing [online] sqapartners.com. Available from: http://www.sqapartners.com/gametesting/game_testing.html [Accessed on May 8, 2008]

Touchdown Entertainment. 2007. Licensing Information [online] touchdownentertainment.com. Available from: http://www.touchdownentertainment.com/licensing.htm [Accessed on May 8, 2008]

UK Trade and Investment, 2007. Playing for keeps: Challenges to sustaining a

world-class UK games sector; Commercial Models [online] uktradeinvest.gov.uk. Available from: https://www.uktradeinvest.gov.uk/ukti/fileDownload/Mono3GamesReport_LR.pdf?cid=411884

[Accessed on May 1, 2008]

Upton, B. 2000. Postmortem: Redstorm’s Rainbow six [online] Gamasutra. Available from: http://www.gamasutra.com/view/feature/3422/postmortem_redstorms_rainbow_six.php?page=1 [Accessed on May 1, 2008]

Vázquez-Bustelo, D., Avella L., Fernández, E. 2007. Agility drivers, enablers and outcomes: Empirical test of an integrated agile manufacturing model. International Journal of Operations & Production Management. 27 (12), pp. 1303-1332.

Wallis, A. 2007. Q&A: Hothead’s Ceraldi & Bocska Wax Lyrical [online] Gamasutra. Available from: http://www.gamasutra.com/php-bin/news_index.php?story=14135 [Accessed on May 1, 2008]

Wu Dong Hao. 2003. Postmortem: Tom Clancy’s Splinter Cell [online] Gamasutra. Available from: http://www.gamasutra.com/view/feature/2830/postmortem_tom_clancys_splinter_.php?print=1

[Accessed on May 8, 2008]

Wyckoff R. 1999. Postmortem: Dreamworks Interactive’s Trespasser [online] Gamasutra. Available from: http://www.gamasutra.com/features/19990514/trespasser_01.htm [Accessed on May 1, 2008]

1 Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

http://en.wikipedia.org/wiki/Wikipedia:Text_of_the_GNU_Free_Documentation_License

This file is licensed under the Creative Commons Attribution-ShareAlike license versions 3.0, 2.5, 2.0, and 1.0. http://creativecommons.org/licenses/by-sa/3.0/

 ___

(c)  2008 – 2013 Jonathan Hallier.  All rights reserved.

The game Daemon Noir and development studio Silver Bullet Games are entirely fictional works, used for illustrative/educational purposes.  Any likeness to real products (published or in developmetn), companies, trademarks, or copyright works/property is unintentional and entirely co-incidental.

Advertisements