CMG2
From Computing and Software Wiki
(→Controllers) |
(→Programmers) |
||
Line 48: | Line 48: | ||
===World Designers=== | ===World Designers=== | ||
they need scripts, ways to change models without programming, ....). | they need scripts, ways to change models without programming, ....). | ||
- | ===Programmers=== | + | ===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. | 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==== | ====Controllers==== | ||
- | |||
<br /> | <br /> | ||
:'''Path followers''' | :'''Path followers''' | ||
Line 75: | Line 77: | ||
====Tools==== | ====Tools==== | ||
- | + | <br /> | |
=====Enemy Manager===== | =====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. | ::The enemy manager will enable programmers to maintain a working list of the current active enemies or non "friendly units" in the world. |
Revision as of 18:33, 24 October 2009
(TBD)is a computer game developed by Group 2 of the Software Engineering & Game Design 2009/2010 4GP6 Capstone Project.
All sections of this document are subject to change as the full scope of the product requirements and restrictions become available.
(ADD MORE STUFF HERE AFTER)
Contents |
Overview
(similar to the one I gave you, perhaps a bit more "catchy"
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)
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?