Tag: concept
Traps
by cyunxu on Jan.15, 2009, under Game Features
Traps are currently only for outdoor part of the map. The map will have environmental materials that will be used to build traps. A trap-builder will be able to survey the surroundings and determine what materials are available and thus which traps are able to be built. However, the game does not require the player to go gather these materials. The trap-builder will then be able to choose the best choice of available traps to be build at the best location automatically. For example, the trap-builder will give a high rating for a boulder trap put on a slope and low rating for a boulder trap on flat land. A trap is triggered by the opposing party once it touches the trap, and a penalty will be given. Traps will be visible to the opponent, but the visibility (alpha value?) of the trap will have an inverse relationship to the goodness of the trap. That means a trap with higher rating value will be less visible to the opponent.
Given below is a rough list of the materials, traps and their attributes, which may be amended and expanded.
Types of materials:
Environmental Materials:
- Water
- Sand
- rocks
- wood
- leaves
Default materials (inexhaustible):
- spade (hole digging)
- trip wires
Types of traps:
| Trap | Materials Needed | Build Time | Penalty |
|---|---|---|---|
| Quicksand | Water + Sand |
10s | Morale -10%, 10s delay |
| Pit Trap | Leaves + Spade | 10s | Morale -10%, 10s delay |
| Pit Trap with Spikes | Leaves + Wood + Spade | 15s | Morale -10%, 10s delay, -10HP |
| Boulder Trap | Rocks + Tripwire | 5s | Morale -5%, -10HP |
| Log Trap | Wood + Tripwire | 5s | Morale -5%, -5HP |
Map
by boro84 on Jan.14, 2009, under Game Features
In order to balance the game, the monster layout will be something like below

monster distribution
TBC. Add any map related stuff here!
Monsters
by boro84 on Jan.14, 2009, under Game Features
Monsters are catergoried into a few types, namely
- physical / magical / hybrid
- side a* / side b* / neutral
Some of the monsters, when nearby with another type of monster, might be able to execute a combined skill attack.
Monster table
| Side A* | Neutral | Side B* |
| Archer(P) | Farmer(P) | Wraith(M) |
| Barbarian(P) | Yeti(H) | Bat(H) |
| Spearman(P) | Spider(H) | Necromancer(M) |
| Pyromancer(H) | Treant(M) | Salamander(M) |
* to be changed to an appropriate name for the side
(P), (H), (M) denote physical, hybrid and magical types respectively
In addition to these monsters, there will be passive creatures, chicken and goats, roaming the game world.
Beastiary
Archer
ranged attacker
combo: fire arrows (Pyromancer)
Barbarian
fast melee attacker
attacks to the death
Spearman
stabs enemies
combo: flaming javelin (Pyromancer)
Pyromancer
burns enemies
combo: fire arrows (Archer)
Farmer
attacks with fork
skill: turns goats aggresive
Yeti
crushing attack (20% reduce defence to 0)
Spider
cast spider webs (slows speed by 50%)
Treant
fires magical branches
Wraith
skill: scares away all enemy troops
Bat
combo: turn into Vampire(Necromancer)
skill: sucks blood (Vampire)
Necromancer
shoots magical missle
skill: turns chicken into kamikaze exploding chicken
skill: turns bats into vampires
Salamander
amphibious monster
shoots missles (20% poison)
Character
by boro84 on Jan.14, 2009, under Game Features
This section describes features of the character class in the game.
The current version is not final. Numbers and formulas are now simplistic and subject to testing in order to balance the gameplay.
Attributes
The character itself does not have a level. The strength of the character is dependent solely on its attributes described below.
Visible Attributes
- HP
Determines the health of the character.
Possible UI Implementation is a health bar on top left corner of screen.
Formula: Max 100/100. Regeneration rate 1HP/10s. - SP
Required to use character skills.
Formula: Max 5/5. Regeneration rate 1SP/10s. - Vigor
Determines the character’s attack, defence and capacity.
Formula: Start 10. Alternatively, class dependent. - Sorcery
Determines the character’s magic attack, magic defence and capacity.
Formula: Start 10. Alternatively, class dependent. - Capacity
Determines the number of Items that the character can carry.
Formula: Vigor * 1.5
Hidden Attributes
- Attack
Determines the damage of the character using physical attacks.
Formula: Vigor * 1.5 - Magic Attack
Determines the damage of the character using magical attacks.
Formula: Sorcery * 1.8 - Defence
Determines the damage suffered by the character against physical attacks.
Formula: Vigor * 1.2 - Magic Defence
Determines the damage suffered by the character against magical attacks.
Formula: Sorcery * 1.5 - Speed
Movement Speed of character. Determined by the amount of free capacity character has.
Formula: TBC - Fury
Determined by the amount of damage suffered by the character. A fury meter will be maintained.
Character will be able to release a special “Fury Skill” upon suffering enough damage.
Fury meter will decrease if a character does not engage any enemy within a timeframe.
Fury meter resets to 0 once skill is used.
Formula: Fury Meter 0/100. Increase by 1 per damage suffered. Decrease by 1 after 1st 10 seconds of not engaging enemies, and every 5 seconds there-after.
External Attributes
- Morale
Morale will have a direct impact on the character’s attributes (as well as of all friendly troops).
Formula:
Morale 50% (Default) -> Vigor, Sorcery 100%
Morale 0% (Minimum) -> Vigor, Sorcery 50%
Morale 100% (Maximum) -> Vigor, Sorcery 150%
Attribute Gain
Attribute gain will be hidden from player. Players do not need to assign any of their character’s attributes.
Player’s action however will have a direct consequence on the growth of their attributes. This allows for many different possible character builds.
Players will increase their vigor and sorcery attributes when attacking monsters or enemies. This will in turn affect the other attributes.
Formula:
Each point of vigor / sorcery will require 20 points of experience to level up. The rules which governs the gain of attribute experience is described below.
- Attacking using physical / magical skills will increase 1 experience in vigor / sorcery
- Killing an enemy of physical type will increase 3 experience in vigor
- Killing an enemy of magical type will increase 3 experience in sorcery
- Killing an enemy of hybrid type will increase 2 experience in vigor and 2 experience in sorcery
Skills
Skills will be unlocked based on the character’s vigor and sorcery attribute.
The fury attack is a special attack which can be used when the fury meter is maxed out.
Skills list:
| Name | Requirement | Cooldown | Damage | Description |
| Slash | 10 Vigor | 0.2s | ||
| Fireball | 10 Sorcery | 0.5s | ||
| TBC |
Squad Party Members
TBC
Finalizing prototype requirements
by anselm on Jan.11, 2009, under Meeting Outlines
- magic/fantasy (eg. drawf vs globins)
- start with a 1 unit vs 1 unit prototype
- troops + turrets for bases
- traps
- 1-2 general type of unit?
- feed back and UI
- controls -> xbox controller will be better
- Indoor(castle, tunnel) + outdoor(forest, mountain, river, plain)
- weather -> global effect ( rain = mass slow?, reduce in visibility)
- terrain height map (affect the movement speed in up hill and down hill)
- tentatively will be on PC for prototype 1

2d version of the prototype map
Pre-Conceptualisation 4: Building towards initial prototype
by boro84 on Jan.02, 2009, under Meeting Outlines, Pre-Conceptualisation
Agenda
- finalise roles
- come up with all possible game features
- preparing for initial prototype
Discussion
Implementation – OOP?
The chosen platform XNA has a class ‘Game1′ which holds the bulk of the code the team has seen so far after looking through XNA tutorials and code.
For a medium size game, this could get messy. Without OOP, objects will have to be stored as structure data types. Alternatively, to implement OOP several methods can be used. 1 of the method is to create classes seperately for each object. An alternative is to code the classes inside the ‘Game’ class. The team will research on this and come to a decision in the following week.
Scrum?
The team decided to research on the Scrum development process and will most likely follow a similar workflow.
Shao Chong will be in charged of maintaining the processes. The team will create a product backlog over the next week, which will contain the list of features which could be included in the game. This list will be trimmed into a release backlog where the team will prune away features that are not necessary or ideal.
The first release, or prototype is targeted to be released by 18th Jan 2009.
Roles
Below are the team’s finalised roles for the project:
Shao Chong – Project lead
Anselm - Lead designer
Boon Pin – Documentation
Yunxu - QA
Every team member will be developers as well, involved in the coding of different aspects of the game.
Roles as developers:
Shao Chong
- combat system
- damage locality
- damage feedback
Boon Pin
- Enemy AI including tactics, behaviour, action
- Pathfinding
Anselm
- visual effects
- weather system
Yunxu
- procedural environment
- trap system
Team members may work together (pair programming) or help out each other during the course of the development.
Other discussions
- discussed on the map requirements for initial prototype (start small, build gradually)
- to finalise on version control software by next meeting
- discussed on implementation of trap system
- to research and try on portability of code between PC and XBOX, and decide on platform for final release
Pre-Conceptualisation 3: Gameplay
by boro84 on Dec.22, 2008, under Meeting Outlines, Pre-Conceptualisation
Main focus of the day was to settle on the gameplay aspects.
Goal
Players will be given a choice to choose which side to play as.
Objective of the game:
1. Destroy all enemies
2. Destroy the leader/boss of the enemy
3. Destroy a base/capture the flag
After much discussion, the team decided to take option 3. This however is not final, might be subject to changes as we implement, test and balance the game. Players might even be allowed to choose how to complete the game.
Neutral enemies will be placed on the map that is aggressive to all sides.
Map
Initial decision is to implement a single map over multiple levels.

map ideas
1. Initial Idea
Players can choose 1 of 3 sides in the map and will attack each other.
- Balancing issue. Alliance (2 vs 1) might unbalance the game, FFA difficult to manage as well.
2. Central goal
2 teams ( 2/4 players or AI) will start at opposite ends of the map and eventually converge into the goal/flag in the centre of the map. Required to traverse through intermediate nodes/base.
Many variations possible.
a. Get flag from enemy base, then place it at the goal
- with current map configurations, opposite enemies might not meet if different path taken towards goal.
b. Get to goal, then destroy enemy base
3. Distant goal
2 teams start at the same side of the map to eventually reach the goal at the opposite end of the map. Will have to pass through the same route eventually
- Solves the problem of enemies not engaging with each other
Decision:
*what was our decision?* tbc
Character
Characters growth automatic based on player’s choice of actions, weapons.
Player have choice to select controllable allies with different specialisations to aid in battle.
Weapons
Start with a basic weapon. Can get better weapons from defeated NPCs or find from map.
Enemies
Different types, strong and weak against different types of attacks.
Pre-Conceptualisation 2: Admin, Gameplay, Subversion
by boro84 on Dec.20, 2008, under Meeting Outlines, Pre-Conceptualisation
Admin
The team managed to meet with Claude today, following is some of the results of the discussion:
We should try to re-use whatever’s available, this includes libraries, plug-ins, tools and assets already developed by others. We should still check with Dr Ashraf the exact grading requirements and what constitutes plagiarism.
Try to come up with a central mission statement that can guide us in times where we’re lost and need to make decisions.
Sort out our priorities and dependencies in order to build up our milestones.
He also suggests a development framework as such:
Pre-conceptualisation
(we are here!)
↓
Conceptualisation
(decide what we want, come up with a prototype and solicit for feedback)
↓
Pre-production
(AI and gameplay programming done here. Assets development as well if any)
↓
Production
(putting stuff together and building the actual game)
During crunch time should we need to reduce features and tasks, we should always look for whatever provides more fun and pleasure value to the players.
Subversion
As we envision the project to be bigger than what we’ve ever attempted, source version control is an important consideration. Assembla offers both SVN and trac however, all projects are open for public viewing. As far as we know, the faculty doesn’t provide SVN services and we’d need to set it up ourselves.
Our options now are:
- XP-Dev if they allow private SVN
- Check if Dr Ashraf can arrange SVN repositories for the module
- Get a friend who’s webhost allows SVN and Trac hosting
Gameplay
Some quick gameplay idea tossed around:
- control-point based siege base
- traps using waymarkers
- commander and squad selection
- first person vs third person
- pan camera to simulate looking around environment
- first person melee combat
- distance perception and precision of control
Pre-Conceptualisation 1: Initial Idea
by boro84 on Dec.13, 2008, under Meeting Outlines, Pre-Conceptualisation
Initial framework considerations:
- XNA
- C# for either PC or Xbox 360. Focus would be on gameplay
- OGRE 3D
- C++ for PC. Focus would be on game engine
Some initial broad ideas:
- Immersive feedback
- feedback through means other than typical HUD, eg. 3D sound or other cues
- Crowd representation
- heterogeneous representation of massive crowds where it doesn’t look like all clones
- Combat physics
- traps, knock back
- Destroyable world
- players able to shape terrain and world objects
- Damage representation
- damage locality, no representation of enemy health other than visual representation, eg broken limbs, limping, etc.