Just wanted to drop a quick line about the networking module I plan to bring to this Collab. During the course of the conversation last night (Tue evening, 4.12.2016) there were some interesting ideas thrown around for the types of networked play we intend to implement. (Player vs. Player, one player controls ship, another controls weapons fire, etc. etc). I was kind of in and out towards the end of the conversation, but it appears I've been elected to pursue the player versus player mode. That's fine, and sounds like a challenge which will be fun.
However, I feel like I should throw out a little info about the networking module itself.
What I had in mind was just a basic communications module. That is, you can plug it into the existing framework we have, send it data that you want shared between players, and then receive any responses from those players to be interpreted in anyway you feel would be applicable.
I also volunteered to take leadership of the networking… but by that I mean on issues such as transport protocols and network topologies - not necessarily creating any specific implementations for game modes. I'm fine with doing the player versus mode and in fact look forward to it. That should keep me fairly busy throughout the day even if the module is completely done and works well going into the collab.
Now, with that being said, I just want to put it out there that other game modes, perhaps a chat feature, and anything else you might want to do with the networking stuff is pretty open ended. At this point in time, the way the code works is to simply send a byte array (256 bytes in length) to listeners on each client. I haven't quite decided on network topology at this time, so if we go with a server-client plan or peer to peer is still open. I've said before, and I'll say again - I personally kind of favor the 'game-lobby' approach similar to older stuff used in DirectX. It's a pretty simple setup where the client logs into (or onto) a server and gets a list of 'rooms' where other players are waiting to join, or already participating in, a 'session'. You choose what game (or 'room') you want to join and create or join a game from there. For our purposes, we probably don't need actual individual 'rooms', maybe just a quick login and enumeration of current players. I'll get to deciding those final sticky points by Thursday…. so if you have any ideas or suggestions, nows the time to let them fly!
Probably what I'll go with is the server-client setup. The network messages will be sent to the server, which then relays the data to all connected clients. You can think of this in simple terms as 'network broadcasting' where the data is simply received and relayed. The code already supports this for the chat program, and would require only minor modification (mainly just removing server commands from being processed). So, if you plan to use the networking aspect, what I would focus on right now is your messaging system. (Bearing in mind the 256 byte message limit/size) I imagine that something like a packet that contains a 'UserID' and it's (worldspace/screen) location would work pretty well. We'd simply have each player broadcast that packet, add a similar packet for the bullets, and transmit all of that information during each Update. Perhaps add a delay so the datagram is transmitted only 3-4 times a second. That should be enough to keep things flowing well. Since the 'level' itself will be the same for all players, we won't have to worry too much about sending level data between clients. Maybe a small packet containing an 'EnemyID' if the enemy is destroyed. If each enemy is given a unique 'ID' when we receive that ID we'll immediately know it's been destroyed by one player or another and we can add an explosion animation, and remove it from the play field.
A couple datagram examples:
- "Player1=> 250,150"
- "PiscesMike=> 323,215"
- "Bullet=> 245,150" (fired by Player1)
- "Bullet=> 235,150" (fired by Player1)
- "Bullet=> 323, 145" (fired by PiscesMike)
- "Enemy=> Toroid113" (bullet fired by Player1 has struck the enemy identified as Toroid113… we need to play an explosion and remove it)
These are simple examples, and of course does not take into account certain instances…. such as two players firing at the same enemy. I'm not sure how things are going to progress, but if I remember correctly, right now the game supports a simple, one bullet, one death implementation. That is, one bullet colliding with one enemy will destroy the enemy. If we change things up where enemies take multiple hits to kill, we may have to adjust things slightly. Instead of transmitting just the enemies unique ID for example, we might have to transmit the ID and the amount of health to remove from that enemy:
"Toroid113=>5" would remove 5 from the enemies health. Conversely, we could transmit the amount of health the enemy has left:
Either would work just fine, if we get to that point, we'll make the call as needed. Just wanted to point out various instances that may need further adjustment.
Anyways, long enough rant. Hopefully that will clear up some things and help you all decide how to proceed on the networking. Like I said, the module itself will basically just transmit and receive data, and it's up to you how to interpret it. Have a great day all, and good luck in your programming ventures!
"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets