Examples:

Model: user defined, should be in a separate class representing your game state. Must persist over Update/Draw cycles. In our case, instance variable of your class subclassing from XNACS1Base class.
View: The DrawWorld() function. By default, drawing happens automatically. No need to do anything, except when you want to avoid drawing an object (RemoveFromAutoDrawSet()).
Controller: The UpdateWorld() function, accepts user input and modify the Model accordingly.
In this Examples
- Model: SoccerTarget, you can create one, update it (moves towards the right), and destroy it.
- Controller: A: to create, B: to destroy, Right-ThumbStick: to move it.
- Try: press-A button multiple times. See left over soccer, why? How to handle this? (RemoveFromAutoDrawSet());

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

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)

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)

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()!

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)

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??

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.

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.

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.