Gilese 581

1. Gilese 581

2. Management

3. Focus of this iteration; don’t just finish, but polish our product. • All software must be efficient, proficient and usable; our game must be something more. • Tweak the user experience • Examples: • Display damage value per attack, not just an ambiguous health bar. • Further options added, i.e. concede defeat. • Art, voice acting & sound effects improved • Interface streamlined and polished.

4. Focus of this iteration; don’t just finish, but polish our product. • Everyone wore multiple hats: • We were fortunate to have multiple levels of experienced engineers on our team. • The size of our team required us to push our skills & abilities • Finish line in sight, all pushed hard to make the final iteration/product a success. • With further goals still on the drawing board, not all were reachable within our timetable. By keeping tight reins on the scope of the project, we drilled down to what was possible.

5. Project Risks: • Budget – $0. WE HIT OUR GOAL! • Schedule – 5 adults with hectic schedules. Worked around, adapted. • Personnel – many diverse skills/talents. Each person found their niche but still worked outside their comfort zone. • Resources – luckily, what we needed was freely available to students. • Customer – our first customer was us, the most demanding customer. • Requirement issues – XNA provided a bit of a learning curve. • Complexity – Not just a software product. Needed to do more than process input to output. Needed to be polished, nuanced, enjoyable.

6. Technical Risks: • Specification ambiguity: we knew what we wanted to make from the outset, not 100% certain of the specifics. • Leading-edge tech: XNA is a leading production environment for small scale or not-for-profit game production. • Potential design: from concept to product, we stayed true to the original concept design.

7. Business Risks: • Market/Sell risk • Current incarnation, most likely not a mass market release. • Scalable to mobile device format, monetizing through in-game ad revenue or micro-transaction game add-ons. • Major success has been achieved for similar games.

8. Generic Risks: • Product size: small in current incarnation but could be scaled up through future additions, downloadable content. • Development environment: Visual Studio 2010 & Microsoft XNA • C# based, but with peculiarities. • Staff size/experience: 2 senior engineers, 2 mid-tier and 1 novice. • All were familiar with VS & C#, all had to learn XNA. • Given experience with C# gave us a leg-up on the learning curve.

9. Functional Design

12. The purpose of the game setup screen is to allow the user to determine the parameters of a new game before it begins: These parameters include: • Selecting two players to participate in the match:- The user selects from a list of player profiles, which is loaded from the disk when the Game setup screen is initialized

13. Creating and Saving Player Profiles:- In addition to a list of current player profiles, the user is able to create new profiles by clicking “Click here to create new player profile”. The profiles include name, portrait and unit color

14. Loading saved profiles from disk:- Player profiles are saved in xml format in directory called “PlayerProfiles”. Any profiles found in that directory are automatically loaded when the game setup screen is initialized • Editing and Deleting player profiles:- Properties of player profile can be edited after the profile has been created and profiles can be deleted.

15. Customizing player forces and choosing Victory conditions:- The players have to agree on the size of the army, the map they will be playing on and the victory condition before the match begins • Victory conditions: Elimination or Assassination • Elimination:- In an elimination game, a player must destroy all the opponents units in order to claim victory. • Assassination:- In an assassination game each player designates one of their units as the “commander”. The first player to destroy the opponent’s commander unit is the victor.

16. The purpose of the options screen is allow user to adjust sound volume, adjust screen size, Enable unit voices,…

17. This is the screen where players play the game. • This screen contains • The Game map- Displayed as a hexagonal grid which can be zoomed in and out • Player status display – Shows the name and portrait of the player participating in the match whose turn it currently is. • Unit Status Display – When a player selects one of his/her own units, its statistics such as unit name, HP, movement speed, recharge, attack type and Damage will be displayed in the unit status display

18. The Escape pop up menu: • Pressing the “Escape” key on the key board during the game will bring a pop up with the following options: • Main Menu- brings the user to the main menu screen • Options Menu – brings user to the options screen • Surrender – Ends the game and award the victory to the opponent of the player whose turn it currently is • Return to Game- Brings user back to the main Game screen

19. Victory Screen:after the game is over victory screen gets displayed

20. Software Design

30. Testing Overview With a relatively simple game, and a small group that is continuously developing and testing, it is easy to test the limits of the game and verify functionality.

31. Unit Testing • Unit testing is always preformed by each developer • Code is submitted after the developer is satisfied with his work (yes this can be subjective)

32. Code Review • Code is reviewed after check-in by another developer (a new set of eyes always helps) • Iterative testing – need to make sure a change doesn’t affect functionality somewhere else in the game

33. Beta Testing PARTY! • Coding, defect write ups, feature requests, food, friends and gaming. • All group members are developers, so it goes without saying that our game is fully functional and perfect. • …Good thing we had input from the users as well. • Game was played continuously by multiple people on different machines to gauge user satisfaction and game functionality.

34. Gliese 581g STP • The standard test procedure outlines user stories to verify that the game is functional and also tests boundary conditions

35. Lessons Lrned Lens on Leed Lessons Learned

36. Software Development • Patient • Time Management • Solve Problems • Communication!!!!!

37. 7 different unit types • Diverse and competitive game play • Units are balanced • Each unit has their own strengths and weaknesses Unit Tactics

38. Artillery • Low health • Slowest Movement • Largest, most flexible attack range • Area Of Effect • Decent damage • Camp this guy somewhere safe and bombard the enemy lines!

39. Commander • Medium movement range • High HP and damage • Amazing reach with “5 in a line” attack…if your own units aren’t in the way. • WHAT ARE YOU DOING THAT’S YOUR COMMANDER!

40. Infantry • Low health • Large movement range • Small Attack Range • Small-ish Damage…but it adds up. • Fast Recharge • Harass your enemies! Block their movement and tank-fire!

41. Mech • Most Powerful Unit in the game. • Huge HP, high damage, great reach and AOE. • Like an even better commander and you don’t lose if he dies. • Look I got a triple kill!

42. Rough Rider • Fast movement • Large flexible attack range • Medium recharge • Low health • Low damage • Great for finishing off weakened targets that try to flee and heal!

43. Scout • Largest movement range • Fastest recharge time • Low damage, Low health, Low range • Can be killed by a tank with one shot. • Best used to block enemy movement andfinish weakened enemies.

44. Tank • Highest single-target damage • Medium movement range • Medium attack range • Attacks in a straight line, impacting first obstacle • Long recharge