Sup! Glad to say that the first week has gone pretty well so far. I’ve successfully managed to implement a few basic classes for Sockets, Sessions and Packets. As I’ve mentioned earlier I want a basic SIP structure for basic communication for gathering data of available games and other types of sessions, while having specific sessions for games later on. This means that more flexibility is added, but also an added responsibility since it requires games wanting to include network functionality to have to define their own network-protocols or handling. This could of course also be done via SIP by embedding all messages in for example SIP INFO messages, but from experience that doesn’t end up working too well, and also disallows any kind of optimization later, which might/will be necessary for games.
I hadn’t really thought of this all when I started this week and threw myself into the work with Sockets, meaning I stumbled upon a “bit” of more work than I’d thought, but as I already have a decent prototype with chat working in a lobby, I’m entirely OK with it. :)
Below I’d added a few inheritance diagrams for the network classes related to the Space Race game, all or most preceded by SpaceRace or SR to know they are associated with this specific game. The diagrams for SIP look similar and have been omitted.
First we’ve got the Session class that will manage the whole gaming session, like accepting or declining new peers, as well as re-routing those messages that should be delivered to other clients. The diagram demonstrates a middle-class called GameSession which I thought might be good for storing general functionality like managing amount of players, spectators, etc.
Next we’ve got the packet-classes. Not much to say here, except that the structure is somewhat similar to SIP in the sense that it should be easy to handle the various packets. For now all packets are text-based, but that might also be subject to change later on. For optimization I might add a SendBinary() function to the SRPacket class, allowing for sending of the data by binary means instead of text-based. As it would require more work I am thinking of doing it after most main features are done, since it requires modifying or adding another packet parser that can handle identifying what packets are receiving properly.
One issue I considered was session-specific user data. Where should it be stored? For example SIP requires knowledge of which registrations and subscriptions are active, while SpaceRace might want to know what ship the player has chosen or how long it was since the peer sent a packet/message in the Space Race-Session. I figured that the best approach would be to have each session that requires additional data will have to define their own “SessionData” structures, and that these then will be attachable to the Peer-classes.
For example consider a complex game later on that enables File-transfers, VoIP, gaming and of course SIP for base communication. In this case all peers would probably have sessionData for each of these sessions that they are involved with, and those peers that have disabled some service would just not have that attached. One advantage to having these session data stored in the Peer-class is that the sessionData can remain more-or-less untouched in the event of dis- and reconnections. Of course it would be up to the specific to the Session to reset their appropriate sessionData variables as they deem fit should any such event occur. Below we can see the two used SessionData-subclasses in use so far.