1. Iterative Design A Look At The Design and Structure of Gundam Wing: Rebirth An Internet RPG A presentation for CSE 197 Game Design Tabin Ahmad March 13, 2007

2. Background An Internet Based Role-Playing Game –Similar Mechanics to Tabletop RPGs –Operated Across Message Boards, Chat Rooms and a Central Webpage Founded in 1998 by Robert Hebert Passed on to me in 1999 Game progressively grew until 2001 First major overhaul attempted at end of 2001 Concurrent development of new system at end of 2003 – Rebirth is retired after this

3. Background Gundam Zero development began in February of 2005 System was rapidly developed with a new vision and new plan until August of 2005 System Development was halted pending new planning and setting due to legal issues and lack of staffing System is currently in limbo. (Update: System is no longer in development) Released under Creative Commons

4. The Game Game consisted of 3 separate yet inter- related parts. –Character Management –PvP Combat –Mission Write-ups The game was very simple, involving no dice, spinners, etc. All calculations could be done quickly by hand or with a 4-function calculator.

5. Character Management A player had to create a pilot and pick a “Mobile Suit” from a list of pre-determined archetypes, each with their own strengths and weaknesses. A player had to create a persona within the game –This creative leeway provided the random chance and X-factor within the game Organizations and alliances were formed by players of like-minded characters

6. PvP Combat Mobile Suits were assigned stats in the following categories: –Hit Points, Long-Range, Short-Range, Defense, Speed, Reaction Time. (HP, LR, SR, DE, SP, RT) Players each possessed different weapons which provided bonuses and special effects to their attacks. All attacks were resolved with this simple formula: –Damage = Attack Base + Weapon Bonus – Opponents Defense

7. PvP Combat Combat is Turn-based During a player’s turn, they can choose to either: Move, Attack, Full Defense, Do Nothing When a player moves, they can move to SR or LR, this determines the attack base used When a player attacks, the defending player chooses to either dodge the attack or take the damage A full defense gives the player a bonus when defending against the next attack against them.

8. Mission Write-Ups A “Briefing” is posted on the message board –Contains a synopsis of the mission, difficulty and approximate reward Any player can accept a mission, but they can only have one mission at a time. The deadline timer begins from the time they accept the mission. Player must write a story about how they completed the mission. The mission is graded based on creativity, faithfulness to the series, and style and clarity of writing. The grade determines the amount of the reward to the player.

9. WebPages Show: –http://www.geocities.com/axman5khttp://www.geocities.com/axman5k –http://www.geocities.com/nmz2khttp://www.geocities.com/nmz2k –http://www.geocities.com/gwrebirth/oldish/rules.htmlhttp://www.geocities.com/gwrebirth/oldish/rules.html –http://www.gundamzero.nethttp://www.gundamzero.net

10. Iterative Design The game saw progressive growth through the years of 1999 to 2001 where the game was being tweaked and reworked while playing the game. This constant rebuilding and testing is iterative design in the purest form.

11. Failures After 2001, system overhauls were executed with a top down approach. Only 2 or 3 people were involved in designing the system, and there was minimal testing until a majority of the systems were completed. The systems ended up to be overly complex, tedious to work with, or were just not fun to play in.

12. Game Design Project Tips Have more than one idea Test and analyze ideas early An idea is only a failure if nothing is learned and applied to future attempts Use the concepts from class, they are very helpful START SOONER rather than later Know your tools

13. Failures After 2001, system overhauls were executed with a top down approach. Only 2 or 3 people were involved in designing the system, and there was minimal testing until a majority of the systems were completed. The systems ended up to be overly complex, tedious to work with, or were just not fun to play in.