Author Archive
Chase algorithm for monster
by boro84 on Feb.17, 2009, under Meeting Outlines
monster(s) will chase player when distance is < 100 and stop when distance < 20.
Weekly Discussion – part 2
by boro84 on Jan.29, 2009, under Meeting Outlines
Exploration (Anselm)
Generate game map from real satellite images
Timeline
Stage 1: Image processing on Google Maps image to generate 3D terrain
Stage 2: Generate control points based on generated terrain
Stage 3: Populate the map – trees, building, monsters w influence map (w Yunxu)
Stage 4: Process user input using Google Maps API
Exploration (Yunxu)Terrain analysis for trap placement, high level Squad AI decisions
Timeline
Stage 1: decide best location for 1 trap type – Boulder Trap – high ground facing possible path.
Stage 2: 2 more types of trap, e.g. the powerful Bear Trap – low visibility, high foliage
Stage 3: intelligent squad deployment AI (w Boon Pin)
Stage 4: TBC
Exploration (Boon Pin)
Intelligent Combat AI algorithms for NPCs (Monsters)
Timeline
Stage 1: Basic pathfinding and monster AI
Stage 2: High level Commander AI based on control points (w Anselm)
Stage 3: Squad AI
Stage 4: Advanced squad AI for squad and monster
Exploration (Shao Chong)
Engine development, UI and enhancing game play through camera and controls
Timeline
Stage 1: Engine up w combat capability and fly through camera
Stage 2: Game play coding, camera research
Stage 3: Camera development and combat control
Stage 4: Fine tuning of camera and combat controls via play testing
Weekly Discussion – part 1 (online)
by boro84 on Jan.29, 2009, under Meeting Outlines
Agenda
———–
1] Update
2] Reflections on what transpired last week
3] to-do
Update
The team read through and is in the process of compiling the Innovation Engine into XP-Dev
Abit of research on individual parts
Reflections
Input from Allan:
3D Game is wide (complex) and difficult to implement
individual’s parts are dependent on each other, ie. Map Representation -> Pathfinding -> AI, etc
advise is to scale down on implementation so as to fit into project timeframe
features to show must be obvious (eg. clever AI must be able to be observed by player)
To-Do
Meeting the next day to sort out product backlog and plan sprints
Follow-up on relevant people for update on xbox loan, creators’ club premium account, schedule for meeting with Claude and Dr. Ashraf, updating Allan on meeting timings
part 2 coming up after tommorow’s meeting
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
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.