First-Person Shooter Game - Drexel Universityal495/eport/docs/INFO638apfprojectplan.pdfthe...

First-Person Shooter Game

By: Group 3

Adam Lerman

Clement Madya

James Mallon

Timothy Schultz

Drexel University, Philadelphia, PA.

INFO638: Software Project Management.

Assignment 4. December 06, 2010.

Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 2

Table of Contents

1. Introduction ......................................................................................... 3

2. Project Analysis and Scope ................................................................ 3

3. Project Overview Statement (POS) ................................................... 4

4. Requirements Breakdown Structure (RBS) ..................................... 5

5. High-Level WBS .................................................................................. 8

6. Scope Triangle and Prioritization ..................................................... 9

7. Project Features Prioritization ........................................................ 11

8. Mid-/Low-Level WBS and Timeline ............................................... 12

9. Financial Analysis.............................................................................. 16

10. Project Status Reporting ................................................................ 18

11. Project Risk Analysis ...................................................................... 19

Risk Severity ........................................................................................................................... 21

Risk Contingency Planning ................................................................................................... 22

Discussion ................................................................................................................................ 24

12. Project Change Control Processes ................................................. 25

13. Future Version Scope ...................................................................... 29

14. Conclusion ........................................................................................ 29

References ............................................................................................................................... 30

Appendix A ............................................................................................................................. 31

Appendix B .............................................................................................................................. 33


1. Introduction

The goal of this report is to define an Adaptive Project Framework (APF) project plan for developing a video game. We will demonstrate the initial part of the lifecycle, leaving out details of future project development and implementation cycles since these are meant to be covered in depth as the project progresses. Instead, we will outline the entire plan and allow room for additions as the plan gets underway, only focusing in depth on the present tasks. We start with the scope of the project followed by the Project Overview Statement and Requirements Breakdown Structure to provide an analysis of what the project will entail. We then delve further into the project by prioritizing the features and discussing the Work Breakdown Structures and timelines which will detail how to actually complete the project. A short financial analysis will help ensure that the project has the means to be implemented, and risks and change controls will be outlined to help make sure that the project does not go off task and has a means to recover if it does.

2. Project Analysis and Scope

This project is based around a new computer video game to be created by DeathBlow Gamers, a startup video game development company. This is the company’s first project and they are very ambitious and anxious to break into the market. Their vision is to become a recognized leader in gaming and to create enough capital to develop more games. In order to do so, a goal the company has set for itself is to develop a first-person shooter video game that wins at least one prestigious industry award and comes in the top ten in sales for the year.

In order to create the game, the development and project management teams along with a customer focus group brainstormed about what type of game they and their target audience would be most interested in, while attempting to create something new and innovative. Based on the popularity of zombie movies as well as first-person shooter games, the teams decided to merge the two and create a first-person shooter game whose plot is to save the main character from a zombie apocalypse. Since the users wanted a familiar locale, the environment is set in the city of Philadelphia, Pennsylvania, which is a popular city in the United States housing much of the nation’s history. It was deemed to be fitting for this story line since much of the nation’s history started there and the character must keep it from ending there as well. The goal is to get from the center of town to a safe-haven on the outskirts, which the user must determine using reasoning, logic, intuition, and in-game clues. Along the way, he will be challenged by invading armies of zombies in which he must defend himself and other characters he meets along the way. The game is intended to not only be fun and entertaining, but to provide the gamer with decision-making, reasoning, problem solving, and survival skills, as well as game theory and hand-eye coordination without the user being conscious of this. The target audience is intended to be a mature audience, most likely teenage males over the age of 13 and young adults.

The game created by DeathBlow Gamers will be boxed, packaged, shrink wrapped, and sold through local and online retailers. These may include websites such as Buy.com, big box stores such as Best Buy, and gaming stores including Game Stop, for example. The user will then be


able to download expansion packs once the original version is purchased. The scope of the development of the game will be broken down into cycles, each one providing further and more detailed implementations as will be discussed below. The first version will start by creating and implementing the basic foundations of the game, such as characters, the game environment, basic weapons and means of transportation, and will become increasingly more complex. Initially, the game and its prototypes will be single player only, and will then implement multiplayer and, finally, online multiplayer additions in future versions. The initial version will be developed for the PC but future versions will be developed for gaming stations such as the Xbox 360 and the Sony Playstation. Again, this will be discussed in further detail below.

3. Project Overview Statement (POS) The purpose of this section is to provide the stakeholders of the project with a summary that will briefly state what the project will entail, why it will be conducted in this manner, and what value it will hold for the company when it is complete. This may, in turn, be used to gain approval from senior management and to attain the required resources to carry out the project. Once approved, the POS may serve as the base from which future planning and project execution may take place, acting as a reference with regards to the project’s scope and purpose (Wysocki, 2009).

PROJECT OVERVIEW STATEMENT

Project Name First-Person Shooter Game

Project No. FPS-001

Project Manager Susan Gasson

Problem / Opportunity DeathBlow Gamers, a startup video game development company, would like to create their first game: a first-person shooter video game that wins at least one prestigious industry award and comes in the top ten in sales.

Goal Break into the industry and become a recognized leader in gaming. Create enough capital to develop more games.

Objectives • Create an award-winning video game with a save-the-world-from-evil-and-destruction

theme: provide a realistic and comprehensive backdrop for the story to emerge. • Game objectives will be to survive a zombie apocalypse by killing bad guys and

navigating from the character’s home in the center of Philadelphia to a safe-haven on the outskirts of town.

• Enhance the customer’s decision making, reasoning, problem solving, game theory, and survival skills, as well as hand eye coordination and quick-thinking.

• Target the teenage male/mature audience population. • Provide functionality for multiple operating systems and an infinite number of players.

•


Success Criteria • The game is understood and able to be navigated without consulting an instruction

manual for 90% of customers. • The player is able to control the character in the manner in which he desires. • The player is capable of progressing through the game from the beginning to end. • The game provides the appropriate challenge levels for all players. • The game is entertaining to 90% of customers based on a rating of a minimum of 3.5 out

of 5 stars • The game will sell over 8300 units per month after version 1 release. This will allow the

business to grow and move towards version 2.* • Limit expenditures to under $100,000 per month during version 1 development to remain

viable.* *See Financial Analysis section for more details.

Assumptions, Risks, Obstacles • The game must be compelling enough for the players to want to complete a session. • Players span multiple age ranges and all must be able to play with little to no instruction. • Being the company’s first game, enough interest and capital must be earned to keep the

business in existence

Prepared by Group 3

Date December 06, 2010

Approved by Date

4. Requirements Breakdown Structure (RBS) The requirements breakdown structure is meant to provide a hierarchical description of what the video game needs to include in order to successfully meet the customer’s needs. It will help to determine a baseline set of requirements and it reflects what is currently known about the product. Therefore, it is as complete as possible, but may need to be revisited in future cycles as new knowledge is obtained. The RBS is written at the user level from the game player’s perspective, allowing the development team to interpret the desired features during coding and implementation. The RBS contains the vision of the company and the goal which is anticipated to fulfill that vision, as well as the feature sets that deliver a portion of the required outcomes. The feature sets are then broken down into features which depict the operations that the user can perform with the system, and these are then broken down into low-level features which describe the who, what, & why for each feature from the user’s perspective.

Figures 1a and 1b depict the RBS in graphical format as a hierarchy of features, and Appendix A provides the same requirements in outline form. The figures were broken out into two images to provide enough room to thoroughly examine each feature set, with figure 1a providing feature sets one through three and figure 1b demonstrating feature sets four through six.

Figure 1a. RBS including Feature Sets 1-3


Figure 1b. RBS including Feature Sets 4-6

In order to develop the RBS, a user analysis was first performed by conducting research about the market and forming a focus group of individuals in the potential range of target customers. Based on discussions with these users, a core set of features was created to meet their wants and needs. It was determined that they would like a solid storyline based on popular zombie lore and would like it to unfold as a movie would. Therefore, they would like an introductory “trailer” leading up to the point of the story in which the player comes in, and would like to figure out the plot of the game on their own through personal observation and exploration. The user would like to do this by examining a realistic city with accurate roads, buildings, landscapes, and landmarks, and would like to choose the character with whom they play. As will be discussed later, users


can start with a male or female character and can customize him or her as they desire, and will then use the character to navigate through the game by running and jumping through city streets and buildings and fighting oncoming zombies. Players can interact with other in-game and human-controlled characters and can team up to complete the story together if they so desire. The game provides weapons and other items that can be obtained, as well as vehicles to be confiscated. Additional clues will be provided as the player interacts with different characters and areas of the city map, and users can pull up a list of clues at any time. As will be discussed in later sections of this report, these features will be implemented in an iterative fashion, starting with the most important and critical pieces first and adding the more detailed portions in later cycles and versions.

5. High-Level WBS The high-level WBS (see figure 2) depicts, at a glance, the overall high-level features that will need to be implemented to successfully complete the project. It only shows the first version of the product, but future versions will be discussed later in this report.

Figure 2. High-level WBS

In the first cycle of the project, the basic game characters and environment will be created since these are the foundation of the game. Rough sketches will be implemented as opposed to detailed features so that the project team can receive feedback from the customers as to how they should be further developed and customized to meet their tastes. Only a basic male and female player character, three zombie characters, and a few main roads and buildings/landmarks will be provided for review, as well as basic character movements. In addition, a grid layout of the map will be proposed. In Cycle 2 the basic set of weapons will be created including a bat, knife, and handgun, and basic ammunition will be developed for the gun. The shooting perspective of the player character will also be created since this will be needed for the rest of the game. Developing these first will help provide ample opportunity for customers to help design the proper character view that suits them and a full list of weapons they would like to utilize. Next, in Cycle 3, a basic low-level vehicle and its movements and navigation will be developed so that additional vehicles may be based upon them and the movement mechanics can be tweaked. Cycle 4 will provide character details and supplementary weapons based on user feedback, in addition to their placement on the map and the look and feel of the weapon inventory which users can access to choose their current weapon. The next cycle, Cycle 5, will help develop the storyline and sub-plots of the game now that the main tangible portions have been created. Since the storyline may be further changed, developed, or narrowed as necessary and is not quite a crucial element, it was saved for one of the middle cycles, still offering enough time to further assess it but allowing for the foundational aspects to be created first. Cycle 6 will then provide supplemental portions of the game such as clues and dialogs, and users can present their feedback in enough time before the first version is complete. Finally, to tie everything together and complete version 1 of the game, Cycle 7 will create the install package, retail package, and support structure. Until this is complete, further feedback and changes may be accepted, provided they have been reviewed by the change management board as is discussed below.

6. Scope Triangle and Prioritization In order to meet the expectations of the customer and provide the best quality product with the correct scope, it is necessary to prioritize and maintain the scope triangle (shown in Figure 3). This consists of the constraints on time (schedule), cost (budget), and resources available which will, ultimately, affect the scope and quality. On the other hand, if need be, the scope and/or quality may be limited to meet the demands of the triangle’s constraints instead. Based on the market and conversations with potential customers, as well as decisions made by DeathBlow Gamers’ upper management, development, and project management teams, the scope triangle has been prioritized as depicted in Table 1 below.


Figure 3. Scope Triangle Wysocki, 2009

Quality was deemed to be the most important factor of the game since, without it, the game will not be bought and its creation will be undermined. However, since the company is small, the human resources available to create the game will be limited and must be maintained. There will not be much room to hire additional individuals and the team must generally make do with those who have already been hired to work on the project. The scope of the game is important but can be flexible if need be, because the team has a strong vision for what it will entail but can change the story line without drastically affecting the game if it comes down to it. This would be one of the later changes made to the project, however, after cost and time. Time is the most flexible and most easily changed since it is not as important to release the game in a specific timeframe as there is no direct competition and the company is new. They, therefore, have the advantage of being flexible with their schedule if need be, although every effort will be made to release the game in a timely manner. Specific timeframes will be discussed later. Although cost is important as well, this is another area where the company can be flexible since they have a reasonable amount of startup capital from investors. Budget is important in any project and efforts will be made to keep costs down, but this can be one of the first aspects tweaked as necessary.

Priority Variable

Critical (1)

(2) (3) (4) Flexible (5)

Scope X

Quality X

Time X

Cost X

Resource Availability X

Table 1. Scope triangle prioritization


7. Project Features Prioritization In order to prioritize the features determined necessary to be developed for the game, the project team and their customers both brainstormed and performed a bucket approach to ranking. The features were gathered together and an attempt was made to organize them in order of importance. Factors such as how much of a role each feature plays in the foundation of the game and user preferences were considered. The prioritized features were then used to populate the cycle plan and mid-/low-level WBS, placing the most important ones in early cycles and holding off less crucial ones for future cycles and versions. The following list contains the set of prioritized features, with 1 being the most important and 35 being the least:

1. As a player, choose a male or female character 2. As a player, navigate the roads and landscape 3. As a player, encounter various types of zombies 4. As a player, use character to fight zombies with fists and feet 5. As a player, discover identifiable landmarks 6. As a player, use character to walk or run down streets and thru buildings 7. As a player, jump 8. As a player, navigate buildings and structures 9. As a player, pick up a weapon or ammunition 10. As a player, use character to attack zombies with various weapons 11. As a player, aim and fire weapon 12. As a player, determine a way to gain entry into vehicle 13. As a player, survey surroundings 14. As a player, use character to fend off various attacks from zombies 15. As a player, determine how to drive vehicle 16. As a player, assess the situation 17. As a player, find clues to determine role in the game 18. As a player, use character to manipulate objects in game 19. As a player, use character to pick up and drop items 20. As a player, choose to speak to other human characters 21. As a player, choose to lure zombies by yelling 22. As a player, choose to team up with another human to fight the zombies 23. As a player, choose to kill another human character 24. As a player, discard a weapon or ammunition 25. As a player, scroll thru weapon inventory 26. As a player, select a weapon from inventory 27. As a player, reload weapon from inventory 28. As a player, discard the vehicle 29. As a player, repair damaged vehicle 30. As a player, view text based “tips” 31. As a player, view map area markers 32. As a player, discover in-game “supplemental” clues 33. As a player, converse with in-game characters to progress the story


34. As a player, choose to customize character 35. As a player, watch introductory trailer

8. Mid-/Low-Level WBS and Timeline As was mentioned above, the mid-/low-level WBS was created based on the set of prioritized features as well as the high-level WBS. The intent was to break down the high-level feature sets into mid-/low-level lists of features and tasks that can be considered the release plan as based on the development schedule. They will then be broken down further during each individual cycle so that there is room for change, and nothing is planned in too much detail in advance since change is inevitable and a crucial part of the APF approach. This report, therefore, will provide a low-level WBS only for the first cycle. Because of this, both the mid- and low-level WBS were combined for brevity’s sake. Figure 4 demonstrates the mid-/low-level WBS for the first-person shooter game in outline form for clarity. Please note the difference in the number of levels between Cycle 1 and the rest of the WBS.


Figure 4. Mid-/low-level WBS

As discussed in section 5 above, each cycle will provide additional features and functionality. Before the development can begin, however, the project was scoped by first conducting market research and forming customer focus groups. This served to help determine the interest in the project and what direction DeathBlow Gamers should take when creating the video game. It was here that the idea for a first-person shooter zombie apocalypse game was born, and the strategy, plot, and target market of the game was detailed and confirmed. The initial requirements and overall scope were determined and the features were prioritized based on customer feedback and interaction. In addition, the number and length of cycles was established, and the mid-level WBS was created to provide the tentative path to follow to begin the development process.

The first cycle, Cycle 1, was then further broken down into low-level tasks so that the development team could begin working, but still at a high enough level where they could interpret the features and requirements and not be constrained. Later cycles will be broken down into low-level tasks as well, but not until they are ready to begin the development process. This is because, with constant feedback from the customer, requirements and features may change. Therefore, room is left for these adjustments so that the project is not restricted and time is not wasted planning aspects that will never come to fruition.

Once the cycles have been completed based on customer feedback and interaction, a post-version review will then be conducted. The intent is to evaluate the overall assessment, creation, and development processes and to compare them to initial intentions, goals, and objectives. A post-mortem review of the project will be done as well as the processes and lessons learned. The scope bank will also be reviewed to help plan for future versions. Questions such as “How successful were we?”, “How close did we meet our budget, scope, and time expectations?”, “Was the customer satisfied?”, “What lessons did we learn?”, Etc. will be answered during this time.

Please see Appendix B for a detailed visual depiction of the timescales for all of version 1 and a complete breakdown of the task sequence as well as the individuals needed to complete them for cycle 1.


9. Financial Analysis DeathBlow Gamers was able to secure $1,500,000 in start-up funds for this project. The cash came from a combination of private investments from the principal owners and investments from angel investors. The short term goals of the company are to keep the burn rate under $100,000 per month, to sell 100,000 copies of the games at a price point of $49 (95% in the year following the release of version 1), and to take the company public with an initial public offering (IPO) within the first 5 years. The leftover cash from release one and the monies secured from sales will drive version 2 of the software title. If cash gets tight, another round of venture funding will be necessary. During the first year the principal owners will not take a salary. To keep labor costs down, full-time employees will be offered future shares of the company once it goes public. The company will also benefit from the start-up gaming culture which requires employees to work long hours without the need to provide additional compensation. Motivation to work long hours will be driven by an opportunity to strike it big if the company produces high quality software that sells extremely well within their target market and the company is able to have a successful IPO.

According to the VGChartz Network (2010), two first person shooter games, Call of Duty: Black Ops and Assassin’s Creed: Brotherhood are at the top of the worldwide top 10 software titles in sales for the week of November, 20, 2010, with each selling almost 2 million copies each. Since Call of Duty: Black Ops was released two weeks ago the title has sold over 10 million copies worldwide. One of the software titles we will be directly competing against is Doom. Doom 3 sold 3.5 million copies for the PC when it was released in late 2009. If DeathBlow Gamers can capture sales from 3% of the Doom 3 PC market, they will be able to reach their sales goals for version 1 of their software title. Since the title will be released in approximately 6 months, the potential to reach this metric is well above average since it will be well over a year since Doom 3 was released and the core audience will be looking for another first-person shooter zombie game for new experiences and new challenges. Once DeathBlow Gamers acquires a name for itself and is able to become self sustaining as a business entity, they can develop their software for game stations such as the Xbox 360 and the Sony Playstation as well as online offerings to establish a well-rounded cross-platform strategy. Below is a breakdown of the finances anticipated to be needed and earned for version 1 of the software:

Startup Cash: $1,500,000

Initial Startup Costs: $250,000 in down payments needed for rent, server hardware, server and software licenses. Cash will be needed for office furniture, office supplies, office PC’s, laptops, telecommunications equipment, wireless technologies, and miscellaneous costs.

Burn Rate Per Month: $100,000


Monthly Breakdown of Costs ($100,000):

Salary: $50,000

Server Hardware: $15,000

Server Software Licenses: $15,000

Rent: $10,000

Overhead: $10,000

Cash remaining after version 1 development: $650,000

Sales Goals for Version 1: 100,000 copies sold in first year.

Suggested List Price ofSoftware: $49.95

Total Monthly Sales Goals: 8300 sales at $49.95 each for a total of $414,585.

Monthly expenditures are expected to rise to $150,000 per month in months 7-12 (Version 2) after the Version 1 release. The additional $50,000 per month in business costs will be needed to hire new employees, account for general overhead expenses, and the establishment of a well-rounded advertising program. An influx of at least $300,000 in software sales per month will be required to break even, assuming a 50% gross profit margin. This equals to approximately 6000 units sold per month. Sales below 6000 units per month will jeopardize the business model and will eventually require a new round of investment capital.

According to MSN Money (2010), Gross Margins for businesses who only produce gaming software are between 23% (THQ), 35% (Take Two Interactive), 50% (Activision Blizzard), and 58% (Electronic Arts) year to date. All of these companies were well established and had significant leverage before the financial meltdown. Since DeathBlow Gamers has a streamlined business model, we recommend a target of 50% for gross margins.

According to MSN Money (2010), Net Profit Margins year to date are between -11% (THQ), -2% (Take Two Interactive), 8% (Activision Blizzard) and -4% (Electronic Arts). All of these companies were well established and had significant leverage before the financial meltdown. Since DeathBlow Gamers has a streamlined business model we recommend a target of 10% for net profits. Figure 5 depicts the monthly cash flow diagram for DeathBlow Gamers for months 1 to 12.

Figure 5. Monthly cash flow diagram for months 1 to 12

10. Project Status Reporting During the cycle builds we will have daily stand-up meetings in the conference room to provide brief issues updates. These meetings will be attended by the project manager and developers who have tasks/deliverables for that specific cycle. This will help keep focus on the current cycle and avoid overcrowding and distractions during the meetings. The meetings will be conducted at the beginning of each day and will last about 15 minutes. Project team members will use this status update as a forum to communicate any obstacles they face during the iterations and give the rest of the team an opportunity to help resolve the issues.

A daily status report will be posted on the whiteboard in the conference room and updated at least once per day by the project manager. The purpose of this status update report is to communicate project progress to the project team. This status report will contain technical issues, updates, and suggested enhancements. It will contain information and issues discussed during the daily stand-up meetings and will be updated as significant progress is made in resolving each issue.

At the end of each cycle we will present a status report prepared by the project manager for DeathBlow Gamers’ upper management. This report will be a brief report with a commentary section on the project status that we will use to highlight any major completions and outstanding components. The report will also include key cycle dates, deliverables and changes in the scope bank. A graphical representation of the functionality delivered per cycle against planned developer hours and actual developer hours will also be included. The variance between planned hours and actual hours can be used to more accurately predicate the planned hours per functionality for the next cycles. This estimate will fluctuate from cycle to cycle as this settles into a constant velocity.


At the beginning of the cycle, the project manager will provide a detailed report to all members of the change management board concerning the high priority items to be discussed at the scope bank/issues log review. Once the board has made their decisions concerning the approval of the requirements, the project manager creates a status report for the customers and updates the scope bank and issues log. The project manager also creates a status report for the project team. High priority items that have been approved are highlighted and the appropriate team members are identified to begin modeling.

A Cycle Test Report will also be created by the Customer Focus Groups for the DeathBlow Gamers’ project manager at the end of each cycle. The test report will include an overview of the features and functionality implemented during that cycle. The test report will have a variance section where the Customer Focus Groups will record any variances of the features and functionality from those areas agreed upon between the development team and the customers. The customers will rank the severity of the variances, and give a brief analysis of the impact of any critical feature and functional variances. The report will have a section for an assessment of the actual test process, including the appropriateness of the test scripts and the comprehensiveness of the test scenarios. Any incomprehensive test scenarios will be documented with a brief explanation of the customers’ expectations against the test scripts. A summary of the test results will be presented for each feature highlighting all resolved and unresolved issues. The report will also include an overall summary of the cycle test process including any logistics issues encountered by the customer.

A longer report to the DeathBlow Gamers’ senior management team will be prepared by the project manager at the end of each version. This report will include summary sections for the post-mortem review, process review, change request review, scope bank review and cycle tests. The project manager will also include a customer satisfaction analysis of the product based on reviews from the Customer Focus Groups.

The end of version report will have a financial cost evaluation that includes the cumulative development costs for the team during the version. It will include a forecast for the cost of the next version based on the Actual Cost figures for the current version.

11. Project Risk Analysis

Problem Description

Game Play Risks

Map contains undetected “pitfalls” from which the character is unable to escape.

Since the large, expansive map proposed in this game should provide a wide array of structures to explore, numerous instances of game spaces in which the player is unable to


maneuver his or her character may go undetected, forcing the player to restart the game from the last save point.

Game does not provide a way for all possible “story paths” to converge to final ending.

Given a wide range of freedom that a gamer can choose a path throughout the game in a non-linear way, all storyline “paths” must converge on final ending.

Usable vehicles are found within areas that do not provide suitable map areas for utilizing them.

Poor planning of vehicle placement within a map reduce their importance in the game, and become burdensome features when they encounter confined areas of game play - especially those created by debris.

Users experience a dearth of weapons/ammunition to appropriately fend off enemies in a certain area with appropriate level of ease.

Poor planning of gear placement within a map provide situations where players find a given task to become too difficult to complete.

Damage produced from attack weapons are not appropriate for the proposed set of varied game enemies.

Players may become frustrated when damage issued to game enemies are either too underpowered (too hard) or too overpowered (too easy).

Game play does not lend itself to have a great deal of “replay value”

The game is perceived by users to be too “linear” and not worth another play-through once the game has been completed.

Computer Requirement Risks

Game requirements do not satisfy those of the present-day average-powered machines.

A large, complex map with countless enemies and situations failed to appropriately handle and free computer resources such that the game can reach the widest audience as possible.

Supporting a nearly infinite number of custom computer configurations creates unforeseen installation/game play issues.

Since each customer’s computer is most likely a “custom” setup in the sense that different applications, libraries, runtimes, and configurations are present on the system, it is difficult to be definitely certain that the game will behave as tested but to the high variation in environments.

Technical Risks

Saved game files become corrupted and are no longer able to be used to retrieve a game save state.

Numerous conditions can occur which render saved-state files (which contain information about a player’s current progress) corrupted, causing frustration and wasted time with the player having to back-track from an older saved file.

Game files are easily accessible on the system, leaving them open to tampering, corruption, or removal.

Giving the users access to tamper with game files opens the possibility for corrupting the game completely, resulting in broken installations.


Licensing Risks

The game is easy to pirate due to lacking licensing schemes.

Mechanisms are not in place which allow users to freely copy and distribute the game without paying for it.

Game licensing activation mechanism does not work properly and thus renders a legitimately purchased game unplayable.

Licensing activation mechanisms for purchased software must properly authenticate legally-purchased software without any issues; failure to do so will result in an unhappy customer.

Game Rating Risks

Game rating review board provides the game with a strict rating, making it difficult for reaching out to the widest audience possible.

The appropriate amount of gore and violence is not implemented with properly such that the game is restricted to a limited older audience and receives scrutiny from parents.

Risk Severity

Problem Probability Impact Overall

Game Play Risks


7 8 56

Game does not provide a way for all possible “story paths” to converge to final ending.

4 8 32


6 6 36


5 7 35

Damage produced from attack weapons are not appropriate for the proposed set of varied game enemies.

6 5 30

Game play does not lend itself to have a great deal of “replay value” 3 7 21

Computer Requirement Risks


3 6 18


7 6 42


Technical Risks


7 7 49


3 4 12

Licensing Risks

The game is easy to pirate due to lacking licensing schemes. 7 6 42

Game licensing activation mechanism does not work properly and thus renders a legitimately purchased game unplayable.

8 8 64

Game Rating Risks


5 8 40

Risk Contingency Planning

Problem Sev. Contingency Plan Responsibility

Game licensing activation mechanism (server-based) does not work properly and thus renders a legitimately purchased game unplayable.

64 Implement help desk support for handling such incidents in a manual fashion until the issue can be resolved; in the meantime, the game should provide a 10-day activation grace period so activation is not immediately needed to play the game.

Software Engineer, Business Analyst


56 While extensive testing of the map with a large contingency of testes should locate most of these issues, an “unstuck” button should be implemented to transfer character to a very nearby area, effectively freeing the character from the obstacle.

Map Developer


49 CRC checks should be computed to determine the integrity of save files on a regular basis within the game, taking incremental snapshots of game progress.

Software Engineer, Programmer



42 Beta testing on tester’s home computers can reduce the occurrence of system-specific issues. Significantly minimizing the amount of specialized frameworks and developing the game based on well-known libraries (such as DirectX 11) will avoid the occurrence of this issue.

Game Designer

The game is easy to pirate due to lacking licensing schemes.

42 Provide a standard and invasive licensing mechanism to authorize legitimately-purchased software.

Software Engineer, Programmer


40 While the designers will develop the game with a specific target rating constantly in mind, provide users with an option to toggle gore and violence settings, such that the game is appropriate for a somewhat younger audience as well.

Business analyst, Project Manager


36 Extensive map testing a vehicle placement should detect these issues, as well as purposely placing “natural” game barriers to direct users to areas where vehicles can be used freely.

Game Designer, Customer Focus Group


35 Extensive gear placement and beta testing should ensure that weapons and ammo can be found in ample supply. However, characters are given the ability to carry a sufficient amount of gear with them from area to area, as well as easily locate additional areas to purchase gear.

Game Designer, Customer Focus Group

Damage produced from attack weapons is not appropriate for the proposed set of varied game enemies.

30 Difficulty settings can be changed throughout the game should the user feel they are not on the appropriate skill level.

Game Designer, Programmer

Game play does not lend itself to have a great deal of “replay value”

21 A complex series of storylines in which the user may pick throughout the game should ensure replay value, however, mission package extension have been planned for future releases to provide additional survival scenario add-ons.

Customer Focus Group, Business Analyst



18 Extensive beta testing should minimize this risk, however, a comprehensive list of audio and graphical settings will be provided to ensure that users can alter performance of the game according to their specific system.

Software Engineer, Customer Focus Group


12 Tampering clause and warranty void statements should be added to the licensing document which users accept during the same installation process. To minimize the occurrence of this issue, game files will be compressed within package files and therefore not directly accessible.

Programmer

Discussion

The risks associated with making a state-of-the-art game, which presents a realistic and expansive landscape of identifiable buildings, structures, and artifacts are vast – covering game play, computer requirements, technical, licensing, and game rating risks. Game play risks, the majority presented here, involve issues experienced by the user while manipulating the character in-game. They generally surface due to the very complex nature of implementing a playable “world” in which the player is free to move in a number of directions rather than in a linear, level-based game. Since the game proposed involves a realistic landscape of a post-apocalyptic situation, chaotic rubble, destroyed buildings, and restricted areas, it is quite difficult to plan for all contingencies for where a user may travel. Consequently, an ample amount of weapons should be dispersed and relatively easy to locate within a given area to complete game tasks, as well as provide ample space for the user to maneuver vehicles.

Technical game risks such as maintaining the integrity of game files from corruption or tampering is another issue to consider to ensure that game installations remain intact and do not cause the customer a great deal of frustration fixing issues or interacting with the help desk. Additionally, computer requirement issues remain a problem due to the high level of uncertainty across non-standard system setups and configurations. The goal is to reach as many customers as possible and, thus, one cannot rely upon game features which require specialized hardware or software which cannot easily be configured with a supplemental installer. This will reduce the amount of variability needed to consider when dispensing the product to customers.

Lastly, due to the proposed gore and mature nature of the game, computer rating risks must be considered. In order to provide a wide array of gamers with access to this game, developers


must walk a fine line between gore and appropriateness. Additionally, the company wishes to evade any controversy from anti-game-violence groups and parent scrutiny, and instead provide an entertaining game for people to enjoy. Overall, the risks presented cover a wide array of issues that can be encountered with developing a large-scale commercial-grade game, covering both technical and game play problems.

12. Project Change Control Processes Change management for an adaptive project differs from traditional projects because it is based upon responding to change as opposed to following a specific plan with formalized processes. Much like our traditional project approach, we decided to establish a change management board. The members would consist of the different project areas and be represented by artists, graphic designers, programmers, software engineers, and writers. The board would be responsible for deciding how to properly respond to change based on customer feedback. For tracking purposes we decided to create two categories, one for defects (issues log) and one for enhancements (scope bank). Since our game is still in development we do not need an emergency defect remediation process but we will need to consider the impact and risks the defect poses. After version 1 is released, a defect remediation plan will be needed. The change management board, scope bank, and issues log will be created in cycle 1 as our first tasks and this will provide the necessary change infrastructure for the rest of the project. We believe the best feedback from our customers will occur after the prototyping and storyboarding sessions at the end of the cycles. When updating the scope bank and issues log we will ask the customers to rank the items in order of priority. Those with the highest priority will be placed at the top and the remaining work items will descend in value. Once the items have been prioritized the board will convene to determine the relative impact on the system. If a high priority work item cannot be deployed in the next cycle or it needs to be scrapped altogether due to scope, risk, or impact assessment, it will need to be communicated to the customers so further negotiation can begin and updates to the scope bank and issues log can be re-prioritized. High priority items to be implemented in the next cycle will be modeled more thoroughly than the remaining items. Once the items are modeled they will become part of the design process and will be included in the software prototype design. Once the design phase has ended, the items will be placed in the build phase to be developed so they will be included in the software prototype for the customers’ review. The changes will be detailed during prototyping in the client checkpoint phase and the customers will be asked to evaluate the change. The feedback gathered from the customers during the prototype and storyboarding reviews will be placed in the scope bank or issues log, depending on how the requirement is categorized. The requirements will be prioritized and the process will continue through the next cycle.


Potential Scenarios:

1. During the enemy prototyping and storyboard sessions the customers indicated the enemy was not scary enough and they wanted the enemy to be partially transparent and difficult to kill. We asked them to prioritize their concerns and rank them in order from high to low:

a. Make the zombies more scary. b.Make the zombies partially transparent but once spotted and engaged in fighting have them morph into more fully defined representations.

c. Make the zombies difficult to kill and allow some of them to come back to life.

These three changes were identified by the customer and, after working with the project manager, they were added to the scope bank after it was discovered they were not defects. They were discussed in greater detail at the scope bank/issues log review meeting. The change management board decided that a. would be the easiest to provide, approved the change, and communicated to the project team to begin modeling the design in cycle 2. They felt c. could be accomplished but it may have to be incorporated in a later cycle, such as cycle 4, when the enemy specialization design is tentatively set to occur. After much discussion the board decided that the company did not have the proper skill set or experience to develop b. at the present time but are hopeful this can be worked into a later version. The project manager met with the customers to discuss the results of the meeting. They were disappointed that b. would not be made available in version 1. After considerable negotiation in which neither side could agree upon a modified requirement, the customer decided to scrap the feature but expressed intent to revisit the issue in version 2. With this new information the customers reviewed the scope bank with the project manager and re-prioritized their requirements. The project manager brought an artist to the meeting and while the artist sketched, the customers provided input into what a scary enemy should look like. Once the customers agreed to the final rendition, the artist forwarded the sketches to the graphic artists to begin modeling.

2. During the client checkpoint in cycle 3 the storyboard showed plenty of vehicle movement and special effects to the customers’ approval; however, the software prototype revealed movement issues and the customers had problems manipulating the vehicle. The customers placed this issue as a high priority requirement and it was placed in the issues log. After much internal discussion the board could not determine the impact of the issue so they requested a code review. The movement issues were determined to be a defect with limited impact. During the scope bank/issues log review the board approved the defect fix and the request was sent to be modeled. The project manager communicated to the customers that the movement issue would be remediated and available for review in the next cycle during the client checkpoint.

Since we are using an adaptive framework methodology for our development activities, we can utilize the change control process throughout all cycles and all versions. However, once a


version is released, we will need to incorporate an emergency defect remediation process to account for defects not found during testing. The defects will need to be replicated and prioritized and a plan needs to be established for their removal. Once removed, the fix will need to be made available online for all current users, and forwarded to manufacturing to be incorporated into a new version of the shrink-wrapped packaged product. Please see figure six for the change control process.

New Requirement

Is Requirement a defect?

Scope Bank Issues Log

Prioritize Requirements

Scope Bank/Issues Log Review

Is Requirement Approved by the

board?

Begin to model the Requirement

Begin negotiation with the customer

Can the Requirement be re-prioritized

Discard Requirement

YesNo

Yes

No

No

Yes

Implement change in build phase

Add change to prototypes

Customer evaluation of

change

Does change meet customers expectations

Close change item in scope bank/issues log

Yes

No

Figure 6. Change control process

13. Future Version Scope While version 1 of the first-person shooter game will provide the foundation of the game and be a completely interactive for-sale item, future versions will add further functionality and will have a two-fold purpose. Version 2 will additionally offer supplementary platforms including Xbox 360 and Sony Playstation, as well as being sold as expansion packs for the PC. The cross-platform games will cost as much as the initial version 1 PC game since they will provide the full equivalency, but the expansion packs will be cheaper since they will be built on top of the existing architecture, and may be downloaded or bought online and in-store. Version 2 intends to implement additional weapons and vehicles, in addition to providing multiplayer capabilities for up to two players. In version 3 which will solely be sold as expansion packs, the player will have the option to customize his character and choose from additional pre-built ones instead of only the generic male or female. This will prove to be useful for the added enhancement of online multiplayer capabilities that will be implemented with this version. Here, players can meet other individuals in the virtual world and choose to interact with them in various ways. This may include exchanging items and clues, teaming up against the zombies or other players, and killing one another to create additional hostile environments.

14. Conclusion Deathblow Gamers is in a unique position to take advantage of the growing first-person shooter market by developing a new title for the mature teen to young adult player. Using adaptive project management methodologies will allow the company to fully engage their perspective customers in the software design and development process. The company has performed a proper financial analysis and risk analysis of their business model to justify moving forward with this project. Providing they manage their risks in an adequate manner and pay close attention to their financial metrics, they should be able to gain enough market share to sustain their vision for success that puts them in a healthy position to plan and develop a subsequent version. Additional financial success will be possible if they are able to achieve a prestigious gaming award and move into the top ten in gaming sales.


References

MSN Money. (2010). Retrieved December 4, 2010, from

<http://moneycentral.msn.com/home.asp/>.

VGChartz Network. (2010). Retrieved November 30, 2010, from <http://www.vgchartz.com/>.

Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme (5th ed.).

Indianapolis: Wiley Publishing, Inc.


Appendix A

Vision: Become a recognized leader in gaming

Goal/Outcome: Develop first-person shooter game that wins at least one prestigious industry award and comes in top ten in sales

• Feature Set #1: Develop a storyline

o Feature #1: As a player, watch story unfold

o Low-level Feature #1: As a player, watch introductory trailer

o Feature #2: As a player, choose story path to follow

o Low-level Feature #1: As a player, assess the situation

o Low-level Feature #2: As a player, find clues to determine role in the game

� Feature Set #2: Create an immersive and to-scale accurate representation of a factual city layout and landscape

o Feature #1: As a player, view/discover city

o Low-level Feature #1: As a player, survey surroundings

o Low-level Feature #2: As a player, navigate the roads and landscape

o Low-level Feature #3: As a player, navigate buildings and structures

o Low-level Feature #4: As a player, discover identifiable landmarks

� Feature Set #3: Develop a compelling set of characters and enemies to bring additional depth to the game.

o Feature #1: As a player, choose a character for game play

o Low-level Feature #1: As a player, choose a male or female character

o Low-level Feature #2: As a player, choose to customize character

o Feature #2: As a player control playable character with the ability to walk, run, and fight within close and far range.

o Low-level Feature #1: As a player, use character to walk or run down streets and thru buildings.

o Low-level Feature #2: As a player, jump.

o Low-level Feature #3: As a player, use character to manipulate objects in game

o Low-level Feature #4: As a player, use character to pick up and drop items

o Feature #3: As a player battle enemy characters.

o Low-level Feature #1: As a player, encounter various types of zombies.

o Low-level Feature #2: As a player, use character to fight zombies with fists and feet.


o Low-level Feature #3: As a player, use character to attack zombies with various weapons.

o Low-level Feature #4: As a player, use character to fend off various attacks from zombies.

o Feature # 4: As a player interact with a comprehensive set of life-like and relateable characters to provide an interactive and humanly experience throughout the course of the game.

o Low-level Feature #1: As a player, choose to speak to other human characters.

o Low-level Feature #2: As a player, choose to lure zombies by yelling.

o Low-level Feature #3: As a player, choose to team up with another human to fight the zombies.

o Low-level Feature #4: As a player, choose to kill another human character.

� Feature Set #4: Create a wide array of close and far-range weapons to appropriately counteract enemy attacks.

o Feature #1: As a player, discover weapons and ammunition for protection.

o Low-level Feature #1: As a player, pick up a weapon or ammunition.

o Low-level Feature #2: As a player, discard a weapon or ammunition.

o Feature #2: As a player utilize a robust set of weapons.

o Low-level Feature #1: As a player, scroll thru weapon inventory.

o Low-level Feature #2: As a player, select a weapon from inventory.

o Low-level Feature #3: As a player, reload weapon from inventory.

o Low-level Feature #4: As a player, aim and fire weapon.

� Feature Set #5: Create a set of vehicles for the user to navigate the city.

o Feature #1: As a player, find a vehicle.

o Low-level Feature #1: As a player, determine a way to gain entry into vehicle.

o Low-level Feature #2: As a player, determine how to drive vehicle.

o Low-level Feature #3: As a player, discard the vehicle.

o Low-level Feature #4: As a player, repair damaged vehicle.

� Feature Set #6: Provide in-game clues and assistance to guide player to goal locations in a given task.

o Feature #1: As a player, request in-game guidance and tips to help advance the game at a reasonable pace

o Low-level Feature #1: As a player, view text based “tips”.

o Low-level Feature #2: As a player, view map area markers.

o Low-level Feature #3: As a player, discover in-game “supplemental” clues.

o Low-level Feature #4: As a player, converse with in-game characters to progress the story.

Appendix B

The following images depict the project timeline as a Gantt Chart. This allows us to easily see in what order the tasks are completed, as well as by whom.

ID Task Name Duration

1 Pre Development Activities 33 days

2 Version 1 Scoping 33 days

3 Conduct market research 15 days

4 Form customer focus groups 2 days

5 Define game strategy, plot, and target market 1 day

6 Create COS 1 day

7 Create POS 1 day

8 Requirements Breakdown Structure (RBS) 2 days

9 Prioritized scope triangle 1 day

10 Prioritized features 1 day

11 Mid-level work breakdown structure (WBS) and dependencies 2 days

12 Cycle timebox 2 days

13 Number of cycles 1 day

14 Cycle 1 26 days

15 Cycle Plan 5 days

16 Conceptualize team reporting/risk structure 1 day

17 Create Change Management board 1 day

18 Create Scope Bank 1 day

19 Create Issues Log 1 day

20 Conceptualize basic game characters 4 days

Business Analyst

Business Analyst,Project Manager

Business Developer,Game Designer,Customer Focus groups

Project Manager

Project Manager

Project Manager

Project Manager

Project Manager,Customer Focus groups

Project Manager

Project Manager

Project Manager

Project Manager

Change Board

Change Board

11/21 11/28 12/5 12/12 12/19 12/26 1/2 1/9 1/16 1/23 1/30 2/6November 21 December 1 December 11 December 21 January 1 January 11 January 21 February 1 February 11

2011


21 Conceptualize basic player character 2 days

22 Basic character concept 2 days

23 Conceptualize basic enemy character 4 days

24 Basic enemy concept 4 days

25 Conceptualize game environment 4 days

26 Conceptualize basic road grid layout 4 days

27 Road surveying/field work 4 days

28 Road plotting 4 days

29 Conceptualize initial basic building structure/layout 4 days

30 Building surveying/field work 4 days

31 Building sketching 4 days

32 Terrain surveying 4 days

33 Artifact selection and sketching 4 days

34 Cycle Build 10 days

35 Develop character 10 days

36 Basic character design development 10 days

37 Character movement development 10 days

38 Character rag-doll physics development 10 days

39 Character attack development 10 days

40 Develop enemy 10 days

Artist,Graphic Designer








Programmer,Software Engineer,Graphic Designer




1/9 1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27January 11 January 21 February 1 February 11 February 21 March 1 March 11 March 21 April 1



41 Basic enemy design and development 10 days

42 Enemy movement development 10 days

43 Enemy attack development 10 days

44 Enemy damage design development 10 days

45 Enemy rag-doll physics development 10 days

46 Develop game landscape 10 days

47 Road development 10 days

48 Building development 10 days

49 Terrain development 10 days

50 Client Checkpoint 13 days

51 Prototyping 6 days

52 Character prototyping 6 days

53 Enemy prototyping 6 days

54 Terrain prototyping 6 days

55 Artifact prototyping 6 days

56 Customer interaction and feedback 13 days

57 Storyboard game simulation (comic book detail of how game would look and basic character interaction)3 days

58 Customer instructions to properly interact with each prototype 1 day

59 Customer feedback for each prototype and storyboard 2 days

60 Update scope bank 13 days









Customer Focus groups




Writer,Artist,Customer Focus groups

Writer,Customer Focus groups


Customer Focus groups,Project Manager

1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3January 11 January 21 February 1 February 11 February 21 March 1 March 11 March 21 April 1


61 Cycle 2 25 days


63 Scope bank/issues log review 2 days

64 Model high priority items approved by the board 2 days

65 Basic weaponry design 4 days

66 Character shooting perspective 4 days

67 Software Prototype design 8 days


69 High priority items development 2 days

70 Basic weaponry/1st-person shooter perspective development 4 days

71 Initial software prototype development 10 days


73 Review Prototypes 3 days

74 Storyboard game simulation (comic book detail of how game would look and basic character and weapons interaction)3 days


76 Cycle 3 25 days




80 Software prototype design 2 days

2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3 4/10 4/17 4/24 5/1February 11 February 21 March 1 March 11 March 21 April 1 April 11 April 21 May 1



81 Basic vehicle and special effects design 4 days




85 Vehicle movement and special effects development 4 days

86 Software prototype development 10 days



89 Storyboard game simulation (comic book detail of how game would look and basic character, weapons, and vehicle interaction)3 days


91 Cycle 4 25 days




95 Character facial and dialog design 2 days

96 Enemy “specialization” design 2 days

97 All weaponry special effects, selection, and map planning design 4 days




3/20 3/27 4/3 4/10 4/17 4/24 5/1 5/8 5/15 5/22 5/29 6/5March 21 April 1 April 11 April 21 May 1 May 11 May 21 June 1 June 11


101 Character facial and dialog options development 4 days

102 Enemy “specialization” development 4 days

103 Advanced weaponry development 4 days





108 Cycle 5 24 days




112 Main story line creation, sub plot design, and recurring situtation design 4 days




116 Main story line creation, sub plot, and recurring situtation development 4 days



119 Review prototypes 3 days


4/24 5/1 5/8 5/15 5/22 5/29 6/5 6/12 6/19 6/26 7/3 7/10April 21 May 1 May 11 May 21 June 1 June 11 June 21 July 1 July 11



121 Cycle 6 25 days




125 Textual “tips” system design 4 days




129 Textual “tips” system development 4 days



132 Review prototypes 3 days


134 Cycle 7 25 days




138 Installer, package, and support design 4 days



7/3 7/10 7/17 7/24 7/31 8/7 8/14 8/21 8/28 9/4 9/11 9/18July 1 July 11 July 21 August 1 August 11 August 21 September 1 September 11 September 21



142 Installer, package, and support development 4 days



145 Review version 1 prototype 3 days

146 Installer testing (multiple system configurations) 3 days

147 Customer feedback on configuration, test plan, and support 3 days


149 Conduct Post-Version Review 1 day

150 Post mortem review 1 day

151 Process review 1 day

152 Change request review 1 day

153 Scope bank review 1 day

154 Lessons learned review 1 day

155 Overall business review 1 day

8/7 8/14 8/21 8/28 9/4 9/11 9/18 9/25 10/2 10/9 10/16 10/23August 11 August 21 September 1 September 11 September 21 October 1 October 11 October 21

First-Person Shooter Game - Drexel Universityal495/eport/docs/INFO638apfprojectplan.pdfthe...

Documents

Transcript of First-Person Shooter Game - Drexel Universityal495/eport/docs/INFO638apfprojectplan.pdfthe...