
We produced some preliminiary tasks for the coming sprint:
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.
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
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.