An event can be identified as a 32-bit integer. The most significant 16 bits represent an event group, and the least significant 16 bits identify the particular event. For the purposes of the initial build, though, I only expect to use group 0, which will be used for named built-in events. Within that group, I’m thinking of splitting the 16-bit word into two bytes, the first being a type (like KEY and SWITCH) and the second allowing up to 255 of that type of event to be predefined.
Obviously, I’m unlikely to make use of even 255 distinct types of event, but there’s no reason not to leave some room to grow. Defining predefined ranges of events should make easier to think about puzzles in a symbolic manner — if you don’t use more than one type of key or switch etc. on a stage, you can just think of “key” as opposed to “key 1” or “event 7”. It’ll also make it easier to write level creation tools.
Events don’t necessarily have to be defined this way in the game’s internals, but we’ll need some way to represent them over the wire (and probably in saved level files). An alternative would be to actually represent them as string symbols: “key”, “key b”, “super special key”, etc. This would possibly make the network representation of events larger, but that might not be an issue.
As far as networking goes: it’s important that events be delivered successfully. It’s possibly important that they be delivered in order. On the other hand, we don’t expect to be particularly chatty, and we’re not trying to track realtime movement from the other side. As I understand it, this fits TCP better than UDP. My (poorly informed) understanding is that if you can transmit your data in discrete chunks of less than around 1500 bytes, and if you set NODELAY on your socket, you get relatively low latency from TCP. Everything I just wrote might be half-misremembered nonsense, though.
I’m interested in researching some open source netplay code. This might be my next step.