5 Replies - 734 Views - Last Post: 21 December 2015 - 09:52 AM Rate Topic: -----

#1 bulwark  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 3
  • Joined: 17-December 15

Turn-based 2-person networked card game

Posted 18 December 2015 - 04:31 PM

I am working toward a turn-based 2-person networked card game, that is my goal and one way or another I will do it. What I came here for is to get some opinions on implementing this. Each player will see their cards and the shared cards and the scoreboard. There will be a tcp or udp server, the server will:

  • be private and allow only those users allowed by the server config
  • handle game requests
  • send game requests
  • keep a player db
  • deal the cards so that the card deck state is not known by either player
  • update the scoreboard


I haven't looked but I am guessing that there are some good card shuffling/randomization routines/algorithms in the public domain. If you know of some that are reliable and realistic I would like to know about them.

I'm learning about game programming and I always like to embark on a real project when I learn something. It just sticks better with me.

I'm going to write the client using Godot and I have already spent time learning that. The editor makes me a little insane but I can use an external editor.

Is This A Good Question/Topic? 0
  • +

Replies To: Turn-based 2-person networked card game

#2 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: Turn-based 2-person networked card game

Posted 20 December 2015 - 08:07 AM

Is there a question?

The only advice that comes to mind right off the top of my head is that this is one of the cases where UDP/IP may make more sense than TCP/IP although you could use either.

With TCP/IP, Telnet is your friend especially for testing servers. I'm not sure I've ever even coded UDP before. I've just always gone straight to TCP.

If you're not familiar with coding TCP, it's basically just a byte stream. Anything you put in the buffer on one end appears in the buffer on the other end regardless of what it is. It's just a row of bytes.
Was This Post Helpful? 0
  • +
  • -

#3 bulwark  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 3
  • Joined: 17-December 15

Re: Turn-based 2-person networked card game

Posted 20 December 2015 - 10:49 AM

I have many questions. Didn't want to start off with a long post.

I am leaning toward UDP but it means more work for me. But for this kind of game I think TCP would also be fine.

The card deck randomizing routines was one question.

I also may want to encrypt the data from the server to the players. This game could run on a LAN or WAN.

Any network sniffing should not provide any way for anyone to cheat. I am open to any ideas in this regard.
My thoughts on it are to have the client and server share secrets about the data. At the start of a game the client and server will come to some encryption agreement and then use that scheme during the game.

The client will contain all the card images. The server will send an encrypted message and the client will decrypt the message to show the card the server has instructed the client to deal.

I don't know much about cryptography so tips are welcome.

My goal is to learn but also to have a working game that is solid and reliable.

By two big concerns are a realistic card deck and anti-cheat.

This post is meant as a conversation and not just question and answer. That make sense?
Was This Post Helpful? 0
  • +
  • -

#4 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: Turn-based 2-person networked card game

Posted 20 December 2015 - 12:53 PM

I'm not aware of an easy language/platform to code this with.

Being a card game, you may not need high end graphics especially for something turn based.

Something like C# might work nicely for this since dot Net has a lot of the built in functionality you're looking for including networking and encryption but still allows things to be pretty low level.

This might not be too difficult in C#.Net but in C++ this would be a buggerbear for sure without some very helpful libraries. I don't think it has any built in solution for encryption and encryption is rough although I think compression is even tougher, especially if you are following an established encryption protocol like 3DES.

Encryption can be pretty basic. We learned how to do it as small children. Letters of the alphabet can be assigned a number. You can shift all the letters by a given amount or number by adding that amount to each letter's number.

M is the 13th letter of the alphabet and so I can "encode" it by adding 7 to every letter in the message so that M becomes 20. A would become 8. Z would become 7 if my rule is that the letters wrap around to the beginning when they go out of range. Following that logic, Y would be 6.

This childish cypher has a lot of problems, but it is the basis for a lot of much more usable encryption. I might even be able to decode the message in my head it's so simple. It's great for introducing kids to the subject but certainly not something the CIA would use.

For one thing, you can just try all 26 combinations until you find one that works. And the spaces are a dead give away if you don't get rid of them and know the language is English. By themselves they help you know word length. In English only I and A are single letter words. So, you know right off the bat with spaces that those 1 character words are one of those two words. Even if you remove all spaces to make it harder to decode (even for the person you sent it to since all the words are now run together and the spaces lost forever until the decoder guesses at what they originally were).

Another way to break this code is to know which letters most commonly appear in the English language. E is the most common vowel and so you might be able to figure out which are vowels and which are not and guess which code is E. That would make it easier to guess words like _E, _EE, _EE_ and such or especially if you have another letter like _EEK. And so it may not even be necessary to guess the number of the shift.


A little more sophisticated cypher would be to use the byte values of characters in the computer. This now has separate codes for upper and lower case making it a bit more clear on the receiving end but maybe making it easier to decode. And it has a code for spaces and so the spaces are encoded. The big advantage is that you have to try 256 combinations to unlock it, take a bit more time. You can shift the letter by as much as 255 places.

Taking this elementary school encoding method to the next level is actually pretty easy. You use a key.

Instead of using one shift value, you use several! So, instead of shifting 7 places, I use the word ENCODE to encode my message. Going back to the first example (although this applies to all examples), my message might be: "I like card games". I turn it into "ILIKECARDGAMES" to get ready to encode it since my encoding doesn't recognize case or spaces. I would have just shifted every letter 7 values. Encoded that way it would be "PSPRLJHYKNHTLZ". Notice H and L are the only two repeaters. You could guess that one of them is the letter E and you would be right; the longer the encoded message the more this will prove to be true. You might think of 7 as the letter G since that's the 7th letter of the alphabet. So, the secret is the code letter G which tells me to shift all letters 7 positions.

But what if instead of using 1 letter I use 6 and repeat the sequence. The word encode has letters with the following values "E=5 N=14 C=3 O=15 D=4 E=5". So, I use this code word to encode the message "I LIKE CARD GAMES". (Notice E was repeated twice in the code word and again you could guess that the duplicate is the letter E and be right and again the length here matters). So, encoding it you get

E  N   C   O   D   E   E   N   C   O   D   E   E   N
5  14  3   15  4   5   5   14  3   15  4   5   5   14
I  L   I   K   E   C   A   R   D   G   A   M   E   S
N  Z   L   Z   I   H   F   F   G   V   E   R   J   G



So the encoded message is
NZLZIHFFGVERJG

Notice that the E's are no longer repeated in the encoded message. If you guess the repeats are the letter E, you're pretty certain to be wrong. Repeating letters no longer even repeat as the first I became N and the second became L and so both N and L are the letter I!

At this point we're already up to a level where very few adults can break this code without the secret code word. Don't try keeping secrets from the CIA with this but I bet you could keep this message secret forever from your family members if they don't have the code word even as simple as it is. They don't know how long the code word is even if they DO guess how the encoding process works.

For the pros, there are some things that would help them find your secret message. For one thing, the encoding word is an English word and the E's repeated in the code word. This makes it a little easier to guess your encoding word and if that happens it's cracked. The pros know how this cypher works and would probably test for this early on. A simple dictionary attack by trying every word in the English language would be successful at cracking it! Although, due to the small size of the message and no spaces to indicate word endings they might get false positives. There appear to only be 26 message value possibilities which strongly hints at this code not encoding lower case.

Using random characters for the code word would have helped such as "NWVYZD" instead of "ENCODE". But another problem is that code word does not cover the entire message and thus has to loop. The pros will look for this looping occurring. If they can combine all their little tricks such as knowing the message is probably in English and so E's will be the most commonly occurring letter on average, they may be able to figure out how often the code word repeats. If they can figure that out, they've got a huge leg up. They could limit their dictionary attack to only words of that length. That failing because it's just random letters, they still only have to try random combinations of exactly that many letters and no combination with more or fewer letters. With a long message and a short code word, the repetitions become more obvious.

And that brings us to a covering code word. What if the word is longer than the message? Then there is no repetition to be found. If the letters are random, then there's no discernible pattern in the code word. For a non-random example, what if you use the letters in a book to encode one page of information. The person decoding has the same book, maybe "War and Peace" for example and thus has the exact same "code words" as the encryptor. So, they can decode it successfully although it may take a good while to do it (unless you can have a computer do it). Only real pros are going to be able to decode it without knowing it is encoded according to the words in "War and Peace". The code word here is much longer than the message being encoded. But to truly take this to the next level, you want the code word to be longer than the message and completely random. You could even encode lower case, punctuation and spaces and it would be near impossible to crack this if the code word is longer than the message and completely random. And instead of encoding with just 26 alphabet letters, try 256 byte values for both the code word and the message. And now don't have the code word be an actual word but just randomly selected numbers between 0 and 255.

Of course, you would definitely have to give the exact sequence of numbers of the "code word" to the person you want to receive it. But you could email them the code word sequence and then you could give them the message in a crowded room with the whole world listening and recording the encoded message and chances are good even the CIA is going to have a tough time decoding this one. The person you gave the message can then go back in private and successfully decode it. Running it through a computer program fed the code word sequence and message and the computer will almost instantly decode what was tough for even the CIA to decode.

If you can cover the entire message with a random code word that is truly random, there's literally no way for anyone to decode it. That's when the CIA starts trying to tail you to see if you wrote the code word down anywhere or search your email to see that the code word sequence was emailed to you. But I don't think even they can take a completely random sequence of values and make sense of it without having the completely random sequence of numbers that encoded it. I think it can't be done, not by anyone.

Anyway, you can't always cover a message with an entirely random sequence. You have to transmit this sequence to the decoder and the longer it is the harder it is for a person to remember it and so they're going to have to record it somewhere where it's vulnerable to attack. If you use the same sequence over and over again, it's no longer completely random and you've introduced repetition which could give you away albeit only by some truly talented people.

But if you were doing this by computer, the longer the code word the more storage space it consumes and such. Plus, random generators are not truly random and so the longer the code word (or key) gets the easier it is to detect repetition in it.

Anyway, that's an intro to encryption. That alone may be good enough to keep most hackers out of your stuff.

Computer encryption is generally done by using public and private keys (I think those are basically what I called code words here). An encoded message (probably a user name and password or such) is passed back and forth publically.

I think this is typically used to establish the connection and to pass the "code word" with the code word being safely encrypted. Then once you pass the "code word" to the other side you can begin communication and have a completely random code word every time you communicate.

You could for example pass "I am User 2 and my password is Duck23" and the message could be short enough to be completely covered. And the way public and private keys work, I can use your public info to send you a message that you know is from me and is completely covered. No one, including me can decrypt the message I sent to you because that requires your private key. So, your public key encrypts which the whole world including me can see, but no one can decrypt including me without your private key. So, this allows the whole world to send you messages that only you can decode.

However, I think this is only used for very short messages, probably because of how much of the message it can cover. For whatever reasons, I think they switch to another encryption method once the connection is established and we know we are talking to one another and not someone else. You use private and public key encryption to determine if someone is who they say they are (probably by passing info such as a user name and password but the data is encrypted so someone listening can't hear the user name and password I'm sending you). Then once you're convinced it's me and not someone pretending to be me, you can use other methods of encryption for the actual data moving back and forth.

This post has been edited by BBeck: 20 December 2015 - 01:01 PM

Was This Post Helpful? 0
  • +
  • -

#5 bulwark  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 3
  • Joined: 17-December 15

Re: Turn-based 2-person networked card game

Posted 21 December 2015 - 09:35 AM

@BBeck cryptology definitely offers flexibility. I will devise a scheme that isn't hard on the players but provides adequate privacy and security.

The game has to be cheat proof or it's a failure from the start. It has to be built-in and not an optional configuration. As we know optional security usually gets disabled and is therefore useless. Think of SElinux.

I may use the public/private key system. It is not perfect but I think it is adequate.

Regarding the graphics side I am learning Godot and have already done some prelim work. I have placed cards on a table. All 2D which is all I want. Animating the scoreboard should be fairly easy. Check out Godot if you haven't, it is free and there are some complete game examples and other examples that come with it.

The other thing I have to think about is firewalls between players. The general strategy in the game dev community seems to be to have a server between players. But I still need to understand more about that. It may not even be an issue for this game. It is an issue for MMOs.
Was This Post Helpful? 0
  • +
  • -

#6 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13484
  • View blog
  • Posts: 53,825
  • Joined: 12-June 08

Re: Turn-based 2-person networked card game

Posted 21 December 2015 - 09:52 AM

Quote

But I still need to understand more about that.

There's a boat load of tutorials, documentation, and drawings on how a 'client/server' game architecture works.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1