2008:SOFTENG450:MaramaTool: Difference between revisions

From Marks Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
==Motivation==
==Motivation==
There are thousands of role playing games in existence. Starting off as old text based games played through a terminal like interface on a single machine, to three dimensional games played in a "massively multilayer" environment. These games are often very similar in dynamics and organisation. Our tool will help designers of these games experiment on new variations to the classic design by easily changing things such as character classes before committing to a design. This tool will also make it easier for software engineers to understand the relationships between these objects in the system and reduce development time.
There are thousands of role playing games in existence. Starting off as old text based games played through a terminal like interface on a single machine, to three dimensional games played in a "massively multilayer" environment. These games are often very similar in dynamics and organisation. Our tool will help designers of these games experiment on new variations to the classic design by easily changing things such as character classes before committing to a design. This tool will also make it easier for software engineers to understand the relationships between these objects in the system and reduce development time.
possible shortcomings,
*limited in what it can show.
*Hard to use
*Constraints between ideas
*viscosity, terseness, bla bla bla.

Revision as of 20:11, 2 April 2008

Motivation

There are thousands of role playing games in existence. Starting off as old text based games played through a terminal like interface on a single machine, to three dimensional games played in a "massively multilayer" environment. These games are often very similar in dynamics and organisation. Our tool will help designers of these games experiment on new variations to the classic design by easily changing things such as character classes before committing to a design. This tool will also make it easier for software engineers to understand the relationships between these objects in the system and reduce development time.


possible shortcomings,

  • limited in what it can show.
  • Hard to use
  • Constraints between ideas
  • viscosity, terseness, bla bla bla.