CMG2
From Computing and Software Wiki
m |
(→Overview) |
||
Line 4: | Line 4: | ||
==Overview== | ==Overview== | ||
- | ( | + | The general purpose of this multiplayer game it to build an army of characters by means of catching them through a number of ways while avoiding enemy characters. The main character, (TBD), runs through various maps, building his army of little minions in order to destroy any enemy characters that prevent him from advancing to the next stage. |
+ | <br/> | ||
+ | “Catchable” characters are easily distinguished by enemy characters. (TBD) Both types of characters have different types of behaviours; characters which move randomly with no intelligence, fast characters that move faster then the player can move but move predictively (to some different patterns), “intelligent” objects that evade the players, and “intelligent” enemies objects that are chasing the players and try to catch/eat them. | ||
+ | <br/> | ||
+ | All objects and players are physical. The main character is equipped with a ‘gravity’ weapon that is able to repel/attract (TBD) other characters within a certain radius. The main character has all the attributes of a real human-being, including but not limited too, jumping, running, crouching (TBD), etc. | ||
+ | <br/> | ||
+ | Once a character has been caught, it will begin to follow the main character as miniature helpers in order to defeat enemy characters. Points are awards for capturing/defeating characters using a predefined scoring system (TBD). The main player receives three lives for each level (TBD) and if killed by an enemy if it does an appropriate amount of damage (TBD). | ||
==Customer Requirements (CuRS)== | ==Customer Requirements (CuRS)== |
Revision as of 20:47, 24 October 2009
(TBD) is a computer game developed by Group 2 of the Software Engineering & Game Design 2009/2010 4GP6 Capstone Project. It is a first-person strategy computer game developed under the C4 Engine.
All sections of this document are subject to change as the full scope of the product requirements and restrictions become available.
Contents |
Overview
The general purpose of this multiplayer game it to build an army of characters by means of catching them through a number of ways while avoiding enemy characters. The main character, (TBD), runs through various maps, building his army of little minions in order to destroy any enemy characters that prevent him from advancing to the next stage.
“Catchable” characters are easily distinguished by enemy characters. (TBD) Both types of characters have different types of behaviours; characters which move randomly with no intelligence, fast characters that move faster then the player can move but move predictively (to some different patterns), “intelligent” objects that evade the players, and “intelligent” enemies objects that are chasing the players and try to catch/eat them.
All objects and players are physical. The main character is equipped with a ‘gravity’ weapon that is able to repel/attract (TBD) other characters within a certain radius. The main character has all the attributes of a real human-being, including but not limited too, jumping, running, crouching (TBD), etc.
Once a character has been caught, it will begin to follow the main character as miniature helpers in order to defeat enemy characters. Points are awards for capturing/defeating characters using a predefined scoring system (TBD). The main player receives three lives for each level (TBD) and if killed by an enemy if it does an appropriate amount of damage (TBD).
Customer Requirements (CuRS)
(THIS SECTION NEEDS TO BE CHANGED LATER INTO FORMAL REQUIREMENTS "STYLE")
The game will be implemented using the C4 Gaming engine. The C4 engine provides the tools, such as graphics rendering, scene graphs, networking.
The following is a list of the features the minimal system should contain:
- Interface such that a non-expert programmer can customize the game. This includes the development of script elements (the non-expert uses scripts to develop a particular game play). Script elements include: spawn scripts (select object type and parameters to spawn an object), message scripts (display a message on the screen)
- Moving Objects, must have one of the following properties/controller assigned:
- Random move controller,
- Path following controller
- Intelligent evasive controller
- Intelligent chasing controller
- Random move controller,
All objects, including the player will respect each other (collision detection) and the environment.
- Sound effects are played if you catch an object, if you are caught, and a danger warning sound is played if an object or character is approaching you and there is danger that you could be caught.
- Worlds, Artwork, must have at least two sample worlds such as a city and a forest environment. The types of objects should be identifiable by there shape. Other players should be animated, and look different then the default C4 Soldier character.
- User Interface, must implement a splash screen, a menu system (choose network mode, character name, etc.), a current score report, and pop-ups if other players join/leave the game.
- Networking, the game has to be multi player and you have to implement a Server Mode (host a game) and a Client Mode (join a game and participate in play).
- Documentation, must use a documentation tool (e.g. Doxygen or DocBook) for your code, a code repository (so many people can work on the same code), and an on-line electronic tool to write your documentation in your group (e.g. a Wiki).
Functional Requirements (FuRS)
(describe the game play, all the characters) Your idea about the Game
System Requirements (SyRS)
SubSystem Requirements (SuRS)
X SuRS
Y SuRS
Z SuRS
Usage Aspects
Players
they need an interface, and other things to make it fun, convenient and interesting).
World Designers
they need scripts, ways to change models without programming, ....).
Programmers
Based on the current customer requirements as well as the game concept/play mechanics outlined in this requirements document, the developers will required the following set of design tools.
Controllers
- Path followers
- Given a set of location markers in the world/level an NPC should follow the path marked out by these markers in a repeating loop.
- A path follower will travel faster than the player such that the player will be required to first analyze the path being followed before he/she can effectively capture the unit.
- Evaders
- Evasion NPCs should simply try to avoid being captured by ALL active players.
- Evaders will attempt to run from the closest player using different strategies such as zig-zag, random turns and random direction changes.
- Evaders will run only slightly slower than the player, making it possible for the player to capture the unit.
- Attackers
- Attacking characters will actively seek out and attack players as well as a players friendly units.
- Initially, attackers will simply "roam" or "wander" in designated areas based on map design and placement.
- Should an attacker encounter an enemy, he or she will then actively seek out that enemy in an attempt to destroy it. If the enemy is too quick and can distance itself adequately from the attacker, the attacker ::will simply return to its original roaming zone and wait for the next attacker to approach.
- Random Runners
- Place in the world based on map design these NPC simply run around in random directions waiting to be captured. Random runners will run slightly slower than the player making it possible for the player to ::capture the unit.
- Follower
- Once a unit has been captured, the unit will follow the player as a "friendly unit". The unit should always follow the player within a given radius. Unit speed will be based on the units' size and properties.
- Larger units may walk slower than the player.
Tools
- Enemy Manager
- The enemy manager will enable programmers to maintain a working list of the current active enemies or non "friendly units" in the world.
- Friendly Unit Manager
- The friendly unit manager will enable programmers to maintain a working list of the active friendly units tied to a specific player.
- Controller Manager(Local)
- The controller manager will enable programmers to attach and manage multiple controllers designated to a single unit.
- Selection Manager
- The selection manager will enable the programmer to maintain a working list of the current friendly units that are selected to perform an action.
- Path Determination
- Given two points, mainly the units current location and a destination, the unit should dynamically find the most efficient path to its destination taking into account the terrain as well as any potential obstacles.
- Multiple Unit Selection
- Based on a geometry drawn by the user onto the playing field, a list of friendly units that appear within that bounding geometry should be built.
- Console Commands
- (for world design / testing?? I think this should go in user section)
Artwork, Sounds & Animations
Artwork
What do you need in terms of these things?
Sounds
What do you need in terms of these things?
Animations
What do you need in terms of these things?