Seaman Risk List Risk # 1: Taking care of Seaman may not be as fun as we think. Risk # 2: We may not be able to get the game to recognize voice commands accurately. Risk # 3: We might not have enough time to come up with and program enough Seaman voice responses to keep the player entertained. Risk # 4: Having a school of interactive Seaman on the screen may cause performance issues. Risk # 5: Taking care of and talking to Seaman may not be enough to keep players coming back. Seaman Risk Mitigation Risk # 1: Taking care of Seaman may not be as fun as we think. Have a programmer make a simple version of the game with basic shapes, no animation, and with the games mechanics. Once you have a working prototype play through it to see if the game is fun. If it isn t fun, start make quick adjustments until it is fun. Also while playing through the prototype, write down any commands you d like to give seaman and any responses that pop into your head. Continue this process until the prototype is fun. o I believe this method of risk mitigation would work for a number of reasons. It would save time and money by preventing you from getting far into the development of the actual game before discovering whether the game is even fun and having to recode the game. It also gives you an opportunity to start looking at the types of commands you d like the player to be able to give and the responses they d get in return. Risk # 2: We may not be able to get the game to recognize voice commands accurately. Have programmers develop basic voice recognition software that can recognize ten to fifteen commands. This should be done separate from the game so no animation or any extra work is required. It should be done before the game moves past prototype. Have people from the team (and outside the team if needed) with different vocal ranges and tones speak these commands to see if the software properly recognizes the voices. If the software is not picking up the commands properly, make needed adjustments to the software until it does. o This is a good method of risk mitigation because it can prevent a whole game being designed around a mechanic that doesn t work. If the programmers can t get the software to work, you know you need to go in a different direction. If the software does work, then you can move forward with confidence and start developing the in game software. This method will save time, money, and headaches down the road by eliminating a risk with as little investment as possible. Risk # 3: We might not have enough time to come up with and program enough Seaman voice responses to keep the player entertained.
Sit down and brainstorm different categories of commands you want the player to give, what categories of commands they may try and give, then brainstorm different commands that fall under each category. Do each of these steps in 30 min sessions to see how much you can come up with in that time frame. Next do the same brainstorming process to come up with responses to all the commands generated. Next have a programmer program five commands and responses from each category to see how long it will take. After the programmer is done, take a look at the time spent and figure out if you can realistically fit the scope of commands and responses you want into your schedule. You will probably realize that covering all the possible commands players will try to give is impossible. If that is the case, you should decide whether to come up with a few responses for commands that aren t understood or if Seaman should just not react at all to those commands. You should also make the decision if you want to invest time in trying to guess as many commands players might give or to find another way to add content to the game. If you want to find another way, once again you should brainstorm. You might come up with ideas such as having Seaman ask the player questions to either find out more about the player or to prompt more dialogue from Seaman. o This may seem like a lot of tedious work, but it will give you lots of material to work with and answer some important questions about the direction you should go. You may realize that trying to come up with responses to every command a player may give to be too time consuming or impossible. You may discover mechanics and elements to the game you would have never thought of had you not brainstormed commands. You may come up with clever responses you would have never come up with had you not brainstormed. You might even discover that adding things like random trivia is a good way to add more content and keep the player engaged. Overall I think this is a good method for risk mediation and improving the quality of the game. Risk # 4: Having a school of interactive Seaman on the screen may cause performance issues. Re- use the prototype you built to see if the game would be fun. Program the seaman to understand a few basic commands and give a few basic responses. Load ten Seaman on the screen and start interacting with them. If the game preforms well, keep doubling the number of Seaman until performance slows down. If adding multiple Seaman does affect performance, start brainstorming ways around it. You know that you want the Seaman to grow into a frog- like creature. Frogs lay a lot of eggs so you know that you want to start with a lot of eggs. But you can t have a ton of Seaman on one screen, so what if in order to grow, the seaman have to devour each other, until there are only a couple? This would take place before there is much interaction or animation on the screen. Try out these types of ideas, brainstorm, test, and repeat until you get it just right.
o This is a good method of risk mediation because you re saving time by using an already built prototype. It also allows you to figure out what performance issues you may come up against so that you can solve the problem with little investment in time and money. Through brainstorming ways around the performance issues, you may just discover a good element or mechanic to add to the game. Once again, you are ruling out a risk early instead of late, which could be crippling to the development of the game. Risk # 5: Taking care of and talking to Seaman may not be enough to keep players coming back. The idea of the game is to have the player take care of Seaman as he grows. We want to have this game take place in real time, so we need to brainstorm ways to keep the player engaged daily as seaman grows. Maybe there could be some kind of daily reward for playing? Maybe a consequence for not playing? Daily rewards tend to become meaningless after a while. So what about consequences? What if Seaman can die? What if Seaman needs to be fed and interacted with daily to survive? We should add this to the game and try it out on some play testers. If it s a good element we ll keep it, if it isn t we ll pitch it out. You will need to test both with and without this feature. o Good things can always come out of brainstorming, but certain things can only be answered with play testing. This way you can discover if a feature that you may like or dislike even works and if you re target audience enjoys it. Cause when it comes down to it, it s all about what the audience thinks. If it improves player interaction and doesn t take away from the fun element, then it s a good choice. But if it only momentarily increases interaction and becomes a pain to the player, it isn t a good choice. Full Sail Final Project Risk List Risk # 1: We may not be able to find the right strength and weakness balance between the five ant colonies. Risk # 2: We may not be able to complete the current scope of this game under the given time constraints. Risk # 3: We may not be able to find a good way to display complex ant tunnels. Risk # 4: The idea of playing an ant colony fighting other colonies may not be appealing to our audience. Risk # 5: The game may run gradually slower as ant colonies grow in size. Full Sail Final Project Risk Mitigation Risk # 1: We may not be able to find the right strength and weakness balance between the five ant colonies. In order to make sure the colonies are properly balanced we will need to assign a number value to every weapon, upgrade, structure, and type of ant. We will rank each unit 1-5 based on how valuable we believe each unit to be.
We will then need to have our programmers and designers make a 2D prototype of the game so we can play through and see how balanced the colonies are. If we notice imbalances we will adjust the our rankings of each unit, see where we need to make adjustments, make adjustments, and start the process over with play tests until we get the balancing just right. o By creating a simple playable prototype we will be able to really get a feel for the balance of the game. Even if the game looks balanced on paper doesn t mean that it is. It will also allow us to make and test adjustment quickly. I believe running lots of playtests is the best way to mitigate the balancing risk. Also, by building a simple prototype we haven t invested a lot of time into designing a game that we re unable to balance. Risk # 2: We may not be able to complete the current scope of this game under the given time constraints. We will need to have to have our artist draw up a map, a design for a couple different ants, and a couple structures. We will also need our programmers to develop several different mechanics and create a simple AI for the ants. We can then use the development times to make the decisions as to what to cut from the game, what to focus more on, and what we need to scale back in order to meet our deadline. o Going into this project with team members whom you aren t familiar with and who might be working on their first real game, it s important to figure out how quickly they can produce the desired results. This way you can more accurately schedule the development of the game. For example if it s going to take a long time to create a bunch of different looking ants, you may have to use color and size to distinguish them rather than looks. I feel like this is a good way to get a feel for what the team is capable of and what you have time to develop, making this a good way to mitigate the risk of not meeting your deadline. Risk # 3: We may not be able to find a good way to display complex ant tunnels. Have the artists draw up designs with different views points. View points such as above ground, just below the surface but looking down on the colony, and views from all four sides of the colony or tunnels. Maybe have use the aerial view as a management screen. Then if the player takes control of a certain group of ants the camera will be able to adjust 360 degrees in any direction based on how the ants are moving through the tunnels. We should then create a little promo video that shows all the different camera angles and viewpoints as the ants are moving around. Based on the video we should be able to determine which camera angles and view points we like. We may even think of a viewpoint we hadn t though of previously. We should continue experimenting with viewpoints and camera angles and seeing them live until we find the right approach. o By starting with art concepts we ll be able to get the general idea of what we want, then seeing them in a promo video, we ll be able to
decide if the direction we went is the right approach. This way we don t program a whole game and decide we don t like the look. I believe this is a relatively quick way to determine if we have the look and feel just right. Risk # 4: The idea of playing an ant colony fighting other colonies may not be appealing to our audience. We will need to poll our target audience with the idea. If it polls well, we should then make a promo video or prototype for play testers to really determine if we have a likeable idea. The video and prototype should both contain the core mechanics of the game and the general look and feel that we re going for. It should also be made clear what the purpose of the game is. o Working directly with our target audience will help us to make a game that is appealing to them. What we think our audience will enjoy and what they actually enjoy can be completely different things. So I believe the best way to mitigate this risk is to hear directly from our audience. Risk # 5: The game may run gradually slower as ant colonies grow in size. We will need to have our programmers make a simple 3D prototype of the game and then populate it with more and more ants until the game starts slowing down. Once we ve figured out the maximum number of ants we can have on screen before the game slows we have plenty of decisions to make. Do we cap the number of ants each colony can have? Once a colony has x number of ants do we use one ant to represent x number of ants? Do we show the whole yard or just small sections at a time? o By making a simple unpolished 3D prototype and populating it with a bunch of ants we can get a real idea of the run speeds of the game. I feel like it is a good idea to test the limits of the engine before we get too invested in the design of the game. Once we determine the line we need to stay under, we can make more informed design decisions that won t come back to bite us later. Pushing the limits of the engine early on will save us from many headaches later on. Scribblenauts Risk List Risk # 1: It may not be possible to create a game where the player can literally write anything into existence. Risk # 2: We may not have the time to create art and animations for everything players might write. Risk # 3: Players may not enjoy solving puzzles by writing words. Risk # 4: Players may run out of creative things to write and get bored with the game. Risk # 5: Giving players the ability to write anything might make the puzzles too easy.
Scribblenauts Risk Mitigation Risk # 1: It may not be possible to create a game where players can literally write anything into existence. It would be impossible to create a game that would recognize every single word. But this is a game of writing objects into existence and we describe objects using nouns. So if we narrow the write anything down to write any non- proper noun, it would be much easier to create a game where the player can write anything. In order to capture every noun that describes a thing, it would be smart to pull these lists from online dictionaries, drop them into an Excel spreadsheet and eliminate any duplicates. The nouns that don t work can be removed during the art process. o By narrowing the word list to non- proper nouns it really saves a lot programming time and just leaves the words that are useful to game play. The decision to pull nouns from online dictionary sites would save a great amount of time and it would have been impossible for the team to think of every noun themselves. The decision to remove nouns that don t work during the art process saves time because the list isn t being looked at twice. I believe this was a smart way to mitigate risk and save time. Risk # 2: We may not have the time to create art and animations for everything players might write. In order to conceivably draw ten s of thousands of nouns we would need to keep the artwork and animations very simple and very quick to make. If we keep the artwork of the entire game simple, then the simple artwork of the nouns will fit in perfectly. We should have artists draw up some quick designs and have programmers animate them to see if this art direction will fit in with our timeline. o I believe the approach to keep all the artwork simple was very wise. It would have taken way too long and gone over budget to create AAA graphics. With the main focus of the game being the ability to write anything, solve everything there wasn t time or need to create fancy artwork. By seeing how long it would take to create the artwork and animate it, the developers would be able to verify if it was feasible to take this art direction early on, rather than find out they made a mistake when it was too late to turn back. Risk # 3: Players may not enjoy solving puzzles by writing words. In order make sure writing words to solve puzzles is fun for our audience we should run paper prototypes. Create a few different puzzles with simple artwork then do some in house play testing. We ll have members of our team sit down with our artists and the artists will draw the nouns the team members say. Then it will be determined if that noun solves the puzzle, if not the team member will try again, if it works they will move on to the next puzzle. If the play testing goes well then the play tests should be expanded to the target market. If after a several playtests with the target market the game
seems to be an enjoyable experience, we know we re on the right path and can move forward with the development. o The idea to do paper prototypes for play testing is a brilliant one. The artwork in the game is going to be simple so the prototype art really won t be too far off from the game art. Plus paper prototyping is cheap, quick, and easy for this game. Using this method the team was able to find out this game is fun and they didn t have to do damage to their budget to find out. Risk # 4: Players may run out of creative things to write and get bored with the game. Just because players like to solve puzzles, doesn t mean they re creative. If we left it up to players to come up with ideas, after a while players might get tired of the game because they re seeing the same art and animations over and over. Prompting the player with suggested nouns would take away from the difficulty of the puzzles. After a quick brainstorming session it may have been clear to the team that they should give players access to a dictionary of nouns. This way a player will never run out of nouns to try and might even find the game more enjoyable. The only way to make sure is to do some split play testing. We ll have some players play with the dictionary and some without. After play testing the team would be able to determine if the dictionary was a smart choice. o The decision to add a dictionary was a smart one. It literally prevents players from running out of nouns to try. I think it was smart to playtest with and without the dictionary as anytime you can playtest is a good thing. They may have saved themselves time by giving the player the option to activate or disable the dictionary during game play. Risk # 5: Giving players the ability to write anything might make the puzzles too easy. If players were just allowed to write anything it would make puzzles easy to solve. After some brainstorming it was probably pretty clear to the team that part of the puzzle would need to be solving a puzzle with limitations on the nouns players could use. During puzzle designs would be the best time to determine what limitations the player would have, as that s part of the puzzle itself. During puzzle creation the team would brainstorm ideas on limitations such as, not using any nouns that start with S or no weapons. This is actually an element that should be done with the initial paper prototyping. o Limiting the nouns players can use not only prevents the puzzles from being too easy but also force players to be creative. Brainstorming on what limitations to use on puzzles can keep the limitations from being repetitive and also allow designers to find limitations that are the best fit for a particular puzzle. Play testing this element during the paper prototyping is smart because it saves time, money, and is a quick way to determine if the designers are making the puzzles too hard with too strict of limitations. I believe this was a clever way to not only make
the make the game more challenging but to also make sure the game is still fun. Evolve About Evolve is a first person shooter where a player can choose to play as a monster or a human hunter. The matches are 4v1 as four hunters go up against one monster. The game is built for online matches, but players can play offline. There is also a rumor that there will be a single player campaign. Evolve Risk List Risk # 1: The game might not stand out amongst other first person shooters. Risk # 2: The game humans and monsters in the game might not balance right. Risk # 3: The online match making might pit players of unequal skill against each other, removing the fun factor for less skilled players. Risk # 4: The engine may not be able to handle the large environments full of creatures with AI. Risk # 5: Will we have time to fill all the different planets with unique AI creatures? Evolve Risk Mitigation Risk # 1: The game might not stand out amongst other first person shooters. There are tons of first person shooters out there. So a good way to figure out the direction you need to go is to hold a focus group. Through the focus group you can map out not only what s been done in these types of games, but what hasn t, and what people would like to see in a first person shooter. o Holding a focus group is a great idea. It may reveal old tired mechanics that need a fresh look or elements that players wish were in first person shooters but have never been added. A focus group might be what the developers did to figure out they need to make a game where players can play four on one. Focus groups while some developers hate them, can be worth while and I think it would have been a great way to help mitigate this risk. Risk # 2: The game humans and monsters in the game might not balance right. The developer used an open beta and closed alpha to help get the balance right. After over two million games were played they discovered certain monsters had win ratios in the 70 percentile. But thanks to the alpha and beta they were able to get the win balance close to 50% on each monster versus human battle. It took four years to develop this game and it wasn t until the alpha and beta that they were able to figure out the balance issues. o Running an alpha and beta was a very smart approach to solve the balance issue and other kinks in the game. Gathering statistics off of real players competing against each other is an excellent way to get real usable information to improve the game. I don t see a better way
for them to have figured out their balancing issues. Good call by the development team. Risk # 3: The online match making might pit players of unequal skill against each other, removing the fun factor for less skilled players. The developer created online leaderboards and players stats will be recorded. The more they play the more information is collected and the better the system will be able to match them against competitive opponents. The team could have initially run inter office tests competing against each other to make sure they were on the right track. The best way to achieve the balance would be through the alpha and beta. This would give them real game data to work with and player s comments to sort through. Thanks to the sure volume of games played they would be able to not only see that they need to make some tweaks but also see almost immediate results of their tweaks. o Once again using the beta and alpha to find balance is a smart move. I don t see a better way for the developers to have balanced online match making than to gather data from real online match making. Risk # 4: The engine may not be able to handle the large environments full of creatures with AI. Have the programmers develop a large generic world where maybe the same tree is generated ten million times and the same couple creatures are generated over and over again. There doesn t need to be any detail to what fills the world, it can just be shapes. Just populate the world with more and more objects and creature until it becomes over loaded. Now you know the limits of how far you can push the engine. o Populated a sample world until it becomes over loaded is a great way to test the limits of what the engine can handle. Once you ve pushed too far, you know how far you can actually go in the future. This gives you the data you need when designing worlds to know when to pull back in areas and when you can keep adding to areas. Risk # 5: Will we have time to fill all the different planets with unique AI creatures? The best way to figure this out would be to have the artists draw up several creatures that could/will be used in the game, then have programmers add some AI and drop them into a game map. Then examine the time it took to complete each creature from start to finish, take the average time, then sit down and determine how many unique creatures per world you have time to create. o Doing this will save the developers from populating a couple worlds with tons of creatures only to find out they re running out of time and they can t fully populate the other worlds in a comparable fashion to the first couple of worlds. By testing out the time of the whole process the developer will be able to more accurately forecast the completion of the game, and how much time and focus needs to be given to creature development.