Coders' meeting

We produced some preliminiary tasks for the coming sprint:

• NetworkSchedule
• Create a basic structure. Discuss and test it.
• Create a structure that's ready for implementation.
• Should have a manager.
• Should have terminals with Time Slot functionality.
• EventHandler
• Posting events.
• Listening for events.
• Can handle global and local events.
• Movement
• Physics.
• Gravity.
• Physical collisions.
• Sprinting (only forward).
• Stamina drain/regeneration.
• Animations
• Customized blending.
• Improve animation scripts.
• Variable speed.
• KeySampler
• Take key samples.
• Network synchronization of key samples
• Weapon
• Collisions.
• Inflict damage on players.
• Shield
• Collisions.
• Able to block attacks.

Coders' meeting

We estimated features and created some basic acceptance tests.

Move player on level with physics, without animations, with orientation. - 16h

AC: Move player on level to test interpolation/extrapolation.

R: The movement is smooth.

Draw with the mouse and perform all combat moves, perform animations. - 32h

AC: You draw with the mouse for a specific move.

R: The corresponding combat move is performed.

R: The drawing can be seen by other players.

R: The move's animation can be seen by other players.

Strikes should hit and harm players. - 16h

AC: A player strikes another player.

R: The struck player is harmed.

Blocks and parries should affect other players. - 16h

AC: A player blocks/parries an attack of another player.

R: The player that attacks notices (text output) that his attack has been blocked/parried.

We also discussed the network structure.

Coder's meeting

15/2
Discussed new Animation system.
Discussed and decided how to prototype the different parts of the new network structure.
Finished programming first version of the new network structure.
Started implementing it in the scripts (movement etc).
Discussed what we need to test/benchmark in the new network system.

Coder's meeting

Friday 12/2.
Discussed how to interpolate time when latency is improved.
Started programming the basic structure, discussing the different approaches as we tested it.
Tested "Saving BitStreams", did not work. Discussed other solutions for saving future events.
Discussed the new animation system.

Coders' meeting

We discussed and planned our Time Slots system and different scenarios and problems for server-client communication.

Which slot to use would be calculated by X = ServerTime - ClientTime.

Time Slot index:

1 -> 20 = i + 0

21 -> 40 = i + 1

… ...

We also discussed peer-to-peer vs server.

We came up with a list of stuff left to do:

EventHandler

NetworkSchedule

Movement (Physics)

Basic Combat

Animation

Effect System

Stuff to test:

Saving Bitstream

SetSending false to avoid "Client->Client" communication

EventHandler, Finalize functionality

Tool using RigidBody

Coders' meeting

Discussed pros and cons with physics and trigger collisions.

Using built-in physics:

Pros: Less to manage.

Cons: Hard to simulate gravity.

Using trigger collisions:

Pros: None (but it seemed like the only solution at first).

Cons: Self-authored physics system. Possible collision problems.

Later on we prototyped a solution that used physics to move the player around the sphere - it worked well.

The coders' meeting

Our discussion mainly handled the topic of using a single or several Netviews per player.

A single Netview:

Pros: Knowing the exact order of messages. Easier to modify the structure. Implementation of the Time Slot structure in one place.

Cons: Less dynamic code structure.

Several Netviews:

Pros: Easier to manage.

Cons: No way of predicting the order of messages. We would have to do the sort ourselves.

We also discussed different scenarios and solutions for the Time Slot buffer.