And the 15 steps for sending a message over the network

The last post was about 13 steps necessary for a release. Now lately I’ve been working on the network communication part of the game (required for a multi player game but also used in single player mode). And this actually also requires a lot of steps. Fortunately once the procedure has been established, one doesn’t need to take care of it anymore.

Just in case you wondered what possibly has to be done to display a few lines of text (names of available scenarios) from one computer running the remake to another and display it there at an appropriate place here is a look behind the curtain:

  1. Create empty list view in one computer (will show names of available scenarios)
  2. Register this list view as destination of any network messages with a certain ID (internally represented by a unique number)
  3. Send a certain request (specified by this ID) to the server asking for scenario titles
    a) Serialize this request and all attached data to a unicode string (using YAML)
    b) Encode this unicode string into bytes
    c) Compress this byte sequence (zip, gzip, ..)
    d) Wrap this byte sequence in a Qt ByteArray (which can be sent as one in Qt)
    e) Send over TCP
  4. Receive a request on the other computer side
    a) Obtain a Qt ByteArray holding all the bytes of the message
    b) Uncompress the byte sequence
    c) Decode into unicode string
    d) Deserialize into Python object using YAML
  5. Look up a table (in Python a dictionary) to find a registered service associated with the ID of the message and call this service
  6. Service looks up all scenario files in the save games directory
  7. Service reads all scenario files and puts scenario titles and file names into a list
  8. Serviceputs the data list and a response message ID together in a struct/dictionary
  9. Other computer sends response message back to Client (as in 3.a to 3.e)
  10. Original computer receives response message (as in 4.a to 4.d)
  11. Response message is transferred to the list view (which had itself registered for it in step 2)
  12. List view updates itself and shows scenario titles
  13. List view deregisters itself (there won’t be another message of this type coming)
  14. User can see and select scenario titles
  15. If user selects a specific scenario the applications sends again another message asking for more details and registers itself to obtain the answer for this new case – this means that step 2-14 are repeated).

Quite a lot that’s going on under the hood, isn’t it.