Examples:

1. Speed:
• A-Button to shoot the ball,
• Right-Thumb-Stick-Up/Down to change the speed
• Only function to pay attention to is: ComputeBallSpeed()
• Note the World.TicksInASecond constant, this is a not-very accurate approximation of number of UpdateWorld() functions call in a second.
• Note, it is accurate that we cover 100 units in exactly 200 updates.
• Our game world is defined against "Update" calls and not against wall clock.
• Notice: AutoDrawSet functions: AddTo and RemoveFrom

 

2. Constant speed with changing direction:
• A-Button to assign a new direction for the ball.
• Only function to pay attention to is: SetRandomBallVelocityDir()
  • Allocate a random direction (call RandomFloat())
  • Normalize the direction
  • Ball's velocity is the normalized random vector multiplied by the speed
  • IMPORTANT: notice the UseXNACS1Lib compiler directive: the library supports setting velocity direction (mBall.VelocityDirectoin) and speed separately (mBall.Speed)

 

3. Constant direction with varying speed:
• A-Button to assign a new direction for the ball.
• Right-Thumb-Stick-Up/Down to change the speed
• Interesting point:
  • UseXNACS1Lib: DOES NOT WORK!! As the speed decreases and approaches zero, the ball starts move randomly!! (lost direction information when speed is zero)

 

4. Vectors and Seeing Vectors:
• A-Button: to add a new Vector at the end of the current one
• B-Button: Clear all existing work
• Left-Thumb-Y: increase/decrease vector size
• Right-Thumb: change current vector direction
• ShowVector class:
  • math: Pay attention to the UpdateEndPoints() function.
  • XGCS1Lib: RemoveFromAutoDrawSet(),
• Update Vector by right thumbStick notice: Normalize() what happens if we don't call tihs function?
• Button-B: World.RemoveAllFromDrawSet()!

 

5. Changing velocity and speed:
• B-Button: to change direction of the ball (with same speed)
• A-Button: will change the speed without changing the direction
• Above example is constant speed (towards the left)
• But, what if instead of moving towards the right, I want to move in some other direction?
• Roads are now instance variables (to avoid re-creating rectangles)
•  GenerateRandomBallVelocityDirection(): notice:
  • RandomFloat function
  • Normalize()
  • How we line up the raods: line equation somewhere?
  • The two options in the for loop for computing nextPos

• Notice: TopofAutoDrawSet() (in button B Clicked)

 

6. Ball follow path:
For the above Example 2 (See Vector), define and implement a soccer ball that continuously follow the vector-segments defined (follow the direction). The soccer ball should cover each segment in a fixed amount of time (faster on the short segments and slower on the longer segments). This goal of this exercise/example is to demonstrate direction (velocity) and magnitude (speed) of vectors.
• Left Thumb-Stick-Y: Change current road segment length
• Left Thumb-Stick-Y: Change how much time the soccer ball has to cover the segment
• Right Thumb-Stick: Change current road segment direction
• A-Button: Add in new road segment
• Ball follows current segment of road it is on
• MySoccer class: it has AI!? no!!
  • A Simple Finite State Machine, treats each "Road Segment" as a distinct state
  • mCurrentRoadSegment as indication of which "state" it is in
  • two causes of state transition:
    • if travelled distance > current segment size, transit to next state (next road segment)
    • if at the very last state (last segment), transit to the first state again.
• Road class: simple arary of ShowVector
•  Update(): of main program is simple:
  • Insert new road segment
  • Get new direction/size for current road segment
  • Tell ball to update itself (because road's new values)
  • Reset if necessary
• If last segment direction change while the ball is on it, ball direction is correct but position is wrong! How to fix this??

 

7. Ball sticking to path using distance travelled:
Identical to the above example, only differences are
• Instead of moving ball from what every position it is in towards the end of the current road-pathway, we make sure the ball is actually on the road.
• All the actions are in MySoccer::UpdateBallDirAndSpeed():
  • travelled: distance already travelled along the road.
  • Center = road.StartPos + travelled * dirOfRoad
  • Notice, we try to adjust the Speed according to the remaining distance left.

 

8. Ball stick to path using number of ticks left:
exactly the same as above, the only differences here are:
• mNumTicksLeft: this is the instance variable inside the MySoccer class telling us how many more ticks before we come to the end of the current road segment.
• Update(): notice the state transition condition is trivial now! Just check if we have use up all the ticks.
• Once again, all the actions are in the MySoccer::UpdateBallDirAndSpeed() function:
  • Change mNumTicksLeft if this is negative (meaning we are beginning a new road segment)
  • Center position is now a percentage of ticks that has happened, percentage of the entire road length
  • We still compute speed according to how much distance left we have to travel.
     
9. General Observations:
   • Process Button-A  first or process Button-B first? (try it!)
   • Notice, in my code, kUnit, kDistanceCovered, my algorithm/constants does not work if the distance covered is not 100 (change it to 85) and see what happens  (road drawing does not reflect the actual distance needs to be covered). How can we fix this problem? Hint: need an extra constant, if kUnit is unit distance per road-segment, then, we need a kRoadSegmentCount=10 constant.