Implement two way communication between client and game

[Rackover]

Currently, the client doesnt send information to the game very well, it can only do so with command line arguments or the initial game start.

To fix this we can use the CreateLobby command currently used by the game to process json tables, containing information we want the game to have, such as player information, and arbitrary content really. So this is both extremely useful and extremely important.

The client already has some functionality to send the game messages, as seen in game_session.py
so what needs to happen is for the code to be expanded to include a general communication feature as well.

This can be done with

self._game_connection.send("CreateLobby",
                           self.init_mode,
                           -1,
                           messagecontent)

where messagecontent is a json table.

The game currently is set up to process json tables when they are sent to a port of -1, but it currently doesnt do anything with those messages should they arrive.
sending the game messages on that port will allow it to recieve data, and its up to whichever feature needs it to decide how to process that.

The json table should be structured as follows:
Messages are JSON strings containing two fields:
command_id: A string identifying the type of message. This string is used as a key into
MESSAGE_HANDLERS (defined in the game code) to find the function to use to process this message.
arguments: An array of arguments that should be passed to the handler function.

[Geosearchef]

I suggest delaying this. The implementation will be made redundant and will need to be redone once ICE comes into play. Also this will need support of both clients.

[ChrisKitching]

The implementation will be made redundant and will need to be redone once ICE comes into play.

Rackover is talking about how to send messages into the lobby lua scripts from the client. Isn't this unrelated to ICE?

[Geosearchef]

There is no communication between the client and the game with ICE. Currently the client has it's own GPGNet server. This will be moved to ICE once it's integrated. Implementing this now will make you implement it again in a few weeks as you will have to make the relevant calls to the ice adapter. The CreateLobby call e. g. is sent by all (4) ice adapter implementations automatically.

So you won't be able to put any data in there without ICE supporting it, which will be worked on once ICE reaches production state.

Also this would need to be coordinated with the java client and I don't think they (including me) will be very pleasant to implement this twice.

[ChrisKitching]

Since the actual decision-making about what to send will originate in the client, the ICE adaptor needs only to proxy the message between client and Lua. There will, therefore, be no duplicated work.

The work to be done is:

• In-lobby logic for handling messages
• In-client logic for deciding which messages to send and what to do with them.
• Teaching the ICE adaptor how to proxy the game<->client RPC protocol.

There is clearly value in beginning this work without delay, not least because it will allow the elimination (or at least significant hinderance) of current exploits to do with name/score spoofing. Migrating the client from sending its messages directly to the game vs. sending them via the ICE relay is a small task that need not involve touching the message processing logic.

[Geosearchef]

The ICE adapter will not proxy that message. It will have to build that message itself, as it has to be part of the CreateLobby command

[ChrisKitching]

The ICE adapter will not proxy that message. It will have to build that message itself, as it has to be part of the CreateLobby command

At the transport level, yes. But at the application level, no. The lobby is deciding what to send, the ICE client is merely sorting out the details of how to send it.

This is what I mean when I say there will be no duplication of work: the client work (deciding what to send and when) is separate from the ICE work (taking the client's input and converting it into GPGNet messages for the game).