HI there,

I'm currently working on a 2-player local card game and have run into a problem concerning hidden information.

As in most other card games, I want to keep the cards each player has, hidden from the other player, but when you only have one screen this turns out to be more difficult than you think. I have multiple ideas how to solve the problem, but none of them really seams to be very elegant:

1. Turn around the cards, for the player that currently has to make a turn: This is the first idea that came into my mindt, but it also has a big problem: The other player isn't allowed to look at the screen while the other player is performing his turn. This seems unituitive because your opponent might want to think about his next move, or even worse, might need to respond to your actions depending of the design of the game. It also seems very unfun, to always make sure the inactive player turns around before making the next turn.

2. Encode the cards of each player: My second idea was to let each player choose a seed, to encode their cards. This would work like the following: Each player chooses a seed which then encodes each players cards (gives them random ids, according to the seed) The game would then only show the id's of the card available to the player. The second step would be to create a small phone app, where you could enter the seed and then display your cards by entering the ids shown on the main game. The problem with this would be that each player needs to keep track on his phone which cards he has, which he just played, etc.. This would cause the player to effectively do each turn twice because after playing a card on the main game screen he would need to manually remove it from his phone app.

3. Create a networking system that sends the game information to each players phone: Pretty much the same deal as above, only that you get rid of all the manual work of seed picking and updating the cards in your hand. A downside for me, however is all the code needed for networking to manage this stuff. For now I rather prefer to stay away from the networking aspect, as my project is complicated enough for now.

4. Scrap the idea of the local multiplayer and go full online mode (like Hearhtstone): Same deal as above, would need lots of networking.

As you can see none of the solutions are very practical (if you want the project to stay local and don't use any networking). Do you have any ideas how you could solve this problem more elegant without overcomplicating the hole process of getting the information to the player and breaking the gameflow to much?

Thanks in advanced for your help!

I like the idea of the main game being displayed on screen with the phones being used to view the cards.  The second idea sounds the easiest to implement and I like the idea of avoiding all the network hassle.  The thing is it still has to be convenient, even if the game looked awesome if I had to type in a code I wouldn't play because I'm lazy, as I'm sure many other people are.  You should do scannable QR codes that link to an app and show the player the corresponding card.  You could embed the codes in game art that either gave the other players a hint at what kind of card it was without outright showing them to encourage planning ahead and strategy or make it alternating artwork with codes worked in so that it's always different and there is no to tell your opponents cards before hand to keep the element of surprise up. 

All of this seems a lot harder to implement than something that's always online like Hearthstone but it's also original and I think worth the effort. Good luck with everything.

Thanks for your input.

I thought about both of your points and ultimately it probably comes down to just stop trying to get around networking. It's probably easier than all that design that has to go into making the hole system intuitive and easy to use. While some of the systems might sound interesting, they probably have to many drawbacks to be easy to use.

However, I still want to create it as a video game, mainly because I want to learn more about programming and the modelling that goes into systems like that, which would fall away if you just design it as a real card game.

Pass-and-play style games are a relatively common and are a good solution to this, especially if you are on mobile.

It is basically what you described as the first option, with the addition of a confirmation for each player.

Player one takes their turn, with all their information.

When the turn is over all the information is hidden. The phone displays "Pass the phone to player 2", with a button marked "Ready!" or similar. When the button is pressed, player 2's information is shown.

When the turn is over all the information is hidden. The phone displays Pass the phone to player 3", and the process repeats, turn after turn, for the course of the game.

The screen can also have a button to hide everything, or to show a common, shared screen that everyone can view.  If you do that, make sure you've got a prompt before returning to the individual player's display.

Thanks again, for all your input. It seems like I need to sit down and reassess what exactly I want this project to be in the end and how I want to execute it.

1 hour ago, BG109 said:

I would actually propose another possible option

Instead of worrying about players having to look away or using phones/networking, why not go full frontal?

 

Design the game in such away that it is intended for the players to see each others cards. 

i belive seeing the opponents cards does not necessary mean reduced gameplay, compare to chess; all the pieces are known exactly but that does not mean the player knows his opponents tactic

As a bonus the opponent can get a chance for a "Oh sh*t he drew THAT card" moments forcing him to completely revise his strategy

Wow, this actually sounds like a really interesting idea. It would make the concept of a card game a very different one, as you could even start desiging cards/effects that are used to sabotage your opponents deck before he can make his move.

This of course would need an excessive amount of testing and designing as you would need to make sure, none of the combinations are frustrating (Imagine prepairing for a combo over and over again and the opponent just destroys it every time before you are even able to play it. Not very fun or engaging).

But I definitely like the idea of taking the problem and turing it into a feature.

Thanks for your suggestions!