- Start game loop timer.
- Establish the client connection.
- The WebSocket request received from client connection.
- The connection is kept in hash map.
- From the game loop response back to the client after processing the data.
- Updates other clients about the current client .
Remember no threads here per connection .
Each request will call callback function that the server must handle asynchronously.
The client and the server have pre defined simple protocol which defined and inform both sides
about the state they are in .
This is the state protocol used in this tutorial :
0 : login
1 : login success acknowledgment
2 : send move request
3 : response move acknowledgment
4 : other player register
5 : other player movment
6 : delete user from client
7 : gem scatter
8 : gem eat and score increment
9 : gem eat and score increment acknowledgment
I will explain the important Sections of the code , not in descending order,
But in the order of execution
Line 331: This is the main function we defined in the previous PART 2 .
This is the entry point in which all request will be captured .
Line 336 : init the hashmap which will hold all of our connections ( clients )
Lines 339 - 341 : init the session data structure , the one we defined in PART 2
in the protocols array
The big switch of web sockets connection States ,
each connection has state on his life cycle on each state callback will fire ,
this big switch will handle those callback by name
Lines 346 - 354: LWS_CALLBACK_PROTOCOL_INIT
This state will be called only ONCE per session Usually good place to init stuff .we init here the Game Loop timer
Lines 356 - 366: LWS_CALLBACK_ESTABLISHED
This state called when client connected to the server for the first time , called once per connection We allocate the session data structure and the basic parameters.
Lines 368 - 384: LWS_CALLBACK_SERVER_WRITEABLE:
This callback will write back to the client , ONLY when the client ready to receive the response .
Lines 375 - 392: when client request registration , which means client hold the 0 state .
collect all data from the client request which arrived as JSON format in to the session data structure.
Lines 393 - 422: when client request is movement , ( client is moving ) . which means client hold the 2 state . collect all data from the client request which arrived as JSON format in to the session data structure.
Lines 425 - 483: collision detection code which is not implemented fully . so you can ignore it.
Lines 486 - 500: LWS_CALLBACK_RECEIVE:
Client request frames that are receiving . can be called several times per request .
Line 493: mark as binary request type
Line 499: libwebsockets API that command the server to send replay only when the client is ready to receive it .
Lines 518 - 600: LWS_CALLBACK_WS_PEER_INITIATED_CLOSE
When client connection is close for example when browser tab in which the game running is closed
When network is stop working , when game is closed and so on .
This callback will trigger , init we will clean the client connection from the main hashmap that holding the connections and do some memory cleaning .
And inform OTHER PLAYERS that this current player has disconnected from the game .
Lines 527 - 558 : set this current player state to 6 which means this player is dead.
Lines 531 - 557 : send response to other players and inform them about the dead player.
Line 573: remove current player from the users hashmap
The event driven programming is usually involve event that is fired on every event occurred .
And in this server is there is no exception , we using callback functions . allot .
Lines 147 - 284 : response_to_client_cp
This callback function will be called each game loop tick every time there is a need to response to clients . It will response to clients based on states the client handled is in .
Lines 162 - 220: build response on registration state , inform others about new user joined to the game Lines 221 -277:response to build response on movement state , inform others about new user joined to the game Lines 281:response to current connection ( current player ) .
Lines 314 -229: game_loop_cb
The game loop which will fire every 100ms , this will simulate the client game loop
And check the game logic , and response according to game events back to the clients
Continue to PART 4 where we examine the client side