Bear Studios

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

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.

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.

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:

1. XP-Dev if they allow private SVN
2. Check if Dr Ashraf can arrange SVN repositories for the module
3. 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

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.