Iterative Design

1
Iterative Design

• A Look At The Design and Structure of

Gundam Wing Rebirth An Internet RPG
A presentation for CSE 197Game Design
Tabin AhmadMarch 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 players 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/axman5k
• http//www.geocities.com/nmz2k
• http//www.geocities.com/gwrebirth/oldish/rules.ht
  ml
• http//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.