|
Post by Leif Bloomquist on Apr 20, 2006 12:08:29 GMT -5
Since we're using UDP (it's all that's available at the moment), we need to do our own acking etc. Here are my thoughts so far, any comments?
|
|
|
Post by Leif Bloomquist on Apr 20, 2006 12:16:31 GMT -5
First off, there's the initial "make contact screen".
The game would ask the player for his/her name, desired IP and MAC address (maybe this can be read from a file). The RR-Net would then be set up.
Next, the player would be asked for the IP address of the opponent.
Once this is entered, UDP packets would be sent to the opponent's IP address once a second containing:
-Player's name in PETSCII text -A flag saying whether the equivalent packet had been received from the opponent.
The reason for the flag is to "echo" back that Player A has received these Announcement packets from Player B, and vice-versa.
So once the game receives this flag set to True from its opponent, it will know that two-way communication has been established, and can proceed to the main game screen.
|
|
|
Post by Leif Bloomquist on Apr 20, 2006 12:19:02 GMT -5
In the game itself, we'll need to do a "poor-man's TCP" I think.
I haven't decided whether there's value in sending "keep-alive" packets every few seconds. Probably not. What's your opinion?
|
|
|
Post by Leif Bloomquist on Apr 20, 2006 12:33:37 GMT -5
Also, I am pushing for peer-to-peer communication. While a central server/arbitrator would solve some problems, it would rely on the server being up for this to work. I'd rather have this thing be playable of its own, independent of servers.
|
|
|
Post by fuzz64 on Apr 23, 2006 20:17:07 GMT -5
Hey!
Are you wanting to be server independant so that someone doesn't have to have a server online 24/7, or is it because you are wanting to make this 100% c64 only?
|
|
|
Post by Leif Bloomquist on Apr 24, 2006 8:34:22 GMT -5
Both. Plus, there's no need for a server with head-to-head play. Once we get into games with >2 players, we'll have to get into servers.
|
|
|
Post by fuzz64 on Apr 25, 2006 20:26:53 GMT -5
Fair enough good sir!
|
|
|
Post by Six on Apr 27, 2006 11:44:45 GMT -5
So the protocol will need to do the following: 1. Establish a connection. 2. Allow for packet retry/timeout 3. Buffer packets so they can be re-sent if requested. 4. Allow for packet resend requests 5. Allow for one side to terminate communications At this rate, I might almost be better off just implementing TCP
|
|
|
Post by Leif Bloomquist on Apr 27, 2006 13:25:01 GMT -5
Hopefully it can be simplified somewhat. 1. It's not really a connection, just indication that something is there on startup only. It doesn't have to be maintained. 2. How many retries would be needed? 3, 4. We could combine these as follows: Player A sends a "here is my move packet", and waits seconds for an ACK from Player B. If it doesn't get it, it resends and waits again, up to times. Player B would ACK the move packet when it is received. If it then subsequently receives another move packet with the same sequence # (i.e. if the first ACK got lost), it ACKs it but otherwise ignores it. 5. I don't think we need to get fancy for this - just stop responding.
|
|
|
Post by Six on May 29, 2006 11:43:29 GMT -5
Just thinking, how's all this sound? Is this game going to be turn based, or does it have simultaneous play?
For flow control, we could have a "magic word" that each side increments when it sends a packet. Thus, every packet the program is expecting has a magic word of the last one it recieved +1. If it ever gets one out of sequence, it would send REQ with the magic word of the last packet it expected.
[UDP HEADER][MAGIC WORD][OPCODE][DATA (IF ANY)][PAD bytes]
opcodes would be: (PROTOCOL OPCODES) $01 - CONNECT REQUEST $02 - CONNECT CONFIRM
$04 - RESEND REQ (followed by magic word of desired packet) $05 - PING $06 - PONG $07 - DISCONNECT (expects no ack)
(GAME-RELATED OPCODES) $08 - GAME DATA $09 - GAME DATA ACK $0A - GAME DATA POLL $0B - GAME DATA (I GOT NOTHING)
The two computers would be considered SERVER and CLIENT. The player that opts to be the SERVER goes into a wait state, the CLIENT sends a CONNECT REQUEST, the SERVER stores the magic byte from that packet and sends a CONNECT CONFIRM with it's own initial magic byte. IF the CLIENT doesn't get a CONFIRM within 5 seconds, it resends the CONNECT REQ.
Upon recieving the CONFIRM, the CLIENT sends a GAME DATA POLL. At this point the game has begun. If the server or client doesn't recieve a GAME DATA or GAME DATA POLL within a set time frame, it sends a GAME DATA POLL. IF a GAME DATA POLL is recieved and there is no game data to send, the response is a GAME DATA IGN (I GOT NOTHING). Any time a GAME DATA packet is sent, it is immediately followed by a GAME DATA POLL.
Since the packets would be relatively small, each side could cache the last 8 or so packets in a stack?
Granted, I'm just brainstorming here...
Sound good to you guys?
|
|
|
Post by Leif Bloomquist on May 29, 2006 12:13:36 GMT -5
Weather War would be turn based. I'm also thinking ahead to game #2 though, which would be something like Artillery Duel. That would work pretty well (and be fun!) with a simultaneous play mode.
With a turn-based game, we probably don't have to worry about more than one packet being "in flight" at any given time.
Plus if you look at my flowcharts, my idea was that the two computers would alternate who is acting like a "server" depending on whose turn it is. Sort of like a token that passes "control" of the game back and forth.
Although your approach would migrate to a central server and multiple players more readily.
|
|
|
Post by Six on May 30, 2006 18:02:55 GMT -5
Well in that case, we could ping-pong moves with a sequence number. Then you never should miss a packet because the other side won't send until it gets your last turn packet
Computer 1: send turn seq#1234 Computer 2: send turn seq#1235 [long delay] Computer 2: resebds turn seq #1235 Computer 1: sends turn seq #1236 etc...
I do think we should keep multi-player in mind just in case, but I'm fine with whatever we do in the end.
|
|