Random notes, and todos about blocks, networking.


Fix endianness.  "man htonl" are these function portable?



Make the Shapes as they fall down be the same on both machines.  I think this
has to do with the random number generation.

Movement backwards and forwards needs to be put in a state.  I think it is
done in another way at the moment.






* For 320x200 make the menus bigger, it is nearly impossible to read the text.

* need to look at the rotation stuff a bit more.  See what needs to go into States.

* should change the size of the encoded data when zone_dim is less than 6.  For a 3x3 field this would mean ~ half as much data sent.
Better than this would to send only the rows that have changed.


* Might want to have a look at using elapsed time, instead of using the number of frames to decide when to check the network connection.





 -------------------------------------------
 | Fifth part - displaying another persons game remotely.

Get blocks working so that it can be displayed on another copy of blocks.



Blocks can be two different things.  Either server, or client.

Server blocks will wait for a client connection and display the clients data.



The protocol should be something like this.


client
When receive: "SEND <State stateNumber>"
Send: "STARTSTATE<int stateNumber><States currentState>ENDSTATE"

Server
When receive: "STARTSTATE<int stateNumber><States currentState>ENDSTATE"
Send: "SEND <State stateNumber+1>"

"BYE"  other blocks quits.


Server: is the one that is the MASTER!!!  it controls everything.
Client: Is subserviant to the master.  Displays the servers game on its
        display.






Figure out how we are going to decide who is server, or client.  Some sort of
negotiation would be the best.  But having people decide by themselves would
be easier.



A Queue class for states.
---------------------------

Needed so that when the state falls behind a bit we can catch up without the motion being too jerky.

Possibly just the block which is falling could be queued.

Should use csvector... see csutils/csvector.h



 -------------------------------------------
 | Sixth part - Getting a view in the top corner, of other persons game.

While you are playing have another view of the other persons game going.

Should probably also show the other persons score.  Maybe even have a bar showing the difference between the two scores.




 -------------------------------------------
 | Seventh part - do things that happen to oposition when you get levels.

When you clear a level, the oposition should be punished :)

In order of easiest to hardest.

- Fog increase for 20 seconds.
- Camera moves around sporadically for 5 seconds.
- Key mappings are swapped arround for 5 seconds.
- Make random blocks appear.
- Have a ferret run around their screen for quite some time






--------------------------------------------------------------------------
| DONE stuff.




DONE
* Need to load the network driver plugin.  "cystalspace.driver.sockets"  How do you make this load through the config file?



 -------------------------------------------
 | First part -  Make blocks a peer to peer network app.  Just send data.


Basically mimic how the ndrvdemo works, except that the program is both client and server.


DONE
 -------------------------------------------
 | Second part - Seperate the state information from blocks.

So we can more easily have two players state information available.  Instead of making two of each member.

All stuff related to displays, and player options should not be in a game state class.  Neither should key mappings.



DONE
- not doing this, they can stay in states.
 -------------------------------------------
 | Third part - Move the relevant game play options to a seperate class.

All the things which determine what sort of game everyone is having.

list of things to be moved:

zone_dim
diff_level




DONE
 -------------------------------------------
 | Fourth part - Encoding the game state.


*Represent all of the information from the state class in a string, or strings.

*Figure out what data to send over, and how often it will need to be sent.
- probably cube_x, cube_y, cube_z with verticle and horizontal velocity.


