Sign In Register

How can we help you today?

Start a new topic
Answered

For the game where only 1v1 matches are available, should I create NoSQL collections per challenge's instance?

 For the game where only 1v1 matches are available, should I create NoSQL collections per challenge's instance?


For example, for the card game:


1. collections: cards_at_hand, cards_at_table

or


2. collections: cards_at_hand_game_challenge1, cards_at_hand_game_challenge2...



I mean that two players in challenge plays only with their cards (each one has about 60 of them) in complete isolation to other challenges/players.


So I guess single collection for "cards at hand" of all challenges can be slow. And I know that player will only ask for his cards or his opponents' cards. So if the collections would be per challenge, I would save a lot of searching (through about 120 records instead of 120 x number of challenges, e.g. 12000).


But should I go this way? If so, how should I generate that collections "on fly" when the challenge begins? Wouldn't that be a drawback to create as many runtime collections as active challenges instances?

Best Answer
Hey Peter,

The challenge-instance doesn't have a collection. But you can add script-data to a challenge-instance, along with private script data. Check out the api here for more details.

All data we are sending is SSL secured and in the unlikely event that something is intercepted, it will most likely to be intercepted when leaving the server, rather than on the client-side. So i would keep that in mind if you are worried about cheating. If it is a serious concern though, you could incorporate some checks into the game client-side and upon receiving an event request that would validate or check or anything strange.

I think, if security is an issue, you should keep the amount of data kept about the game at a minimum, and just have the players send the cards they are going to play each turn. You could also store each turn's info in the challenge-script data too. The benefit of this is that you can check in cloud code if the conditions have changed between turns. I.e. if the basic conditions of the opponents hand is different when the player takes their turn, it is likely the player has modified them, and so probably cheated.

You could also have some custom listeners and logeventrequest being sent every seconds or so, checking to see if the gamestate has changed.
Effectively update your game in slow real-time. Because you are dealing with a card game, this might be okay, but you've still got the security issues.

I dont see a problem with your first approach, with saving data into a collection though; i wont be any slower than any other way that will require you to check data in the cloud. If you have a collection for every challenge, and a manager that will drop that collection when a challenge ends, i dont see any problem with that.

Sean

 


Hey Peter,

I wouldn't suggest storing player's hands in a collection at all. If i am thinking about the workflow you described, and i am getting it right, the process should work like a normal turn-by-turn challenge. If all that is needed is for a number of card to be loaded into the game when it starts, and then just a few at each turn, i suggest that an array of cards is sent between each player when turns are taken.

If you wanted, you could get each player to send each other an array of all their cards when the challenge starts. Then this array is stored, but never displayed in the game. Then when each player takes their turn, you send an array of card indexes along with the message telling the opponent a turn has been taken.

I think this is better than a collection, for a few reasons.

First off there is much less persistent data, and without the card-collections being stored in one specific place, the data being sent between turns has less context, so you are more secure against interception (if you are worried about security).
Also, sending only the data required each turn will make it easier to script and manage.

Another alternative if you feel the need for a collection, is to store each player's card collection in the challenge-instance itself. You can add script data to the challenge, so that each time you get a response, you can also access all the cards.

Does that help?
Sean

Thank you for an interesting solution.


I have to clarify that this is not a "normal" card game but the TCG one (like e.g. Heartstone). With hundreds cards types (from which player has chosen about 20 types) and decks of 60 cards instances for each player, each card having several values (attack, defense, cost in mana, initial hp, actual hp, modifiers, special abilities etc.) and stages (at hand, played, destroyed, attacking, exhausted...). It would be quite a huge amount of data to be send between players and it would also allows some "cheating" if somebody has modified the client side of the game (I have it in JavaScript for now - person could rewrite his deck to e.g. legendary/overpowered card types which he haven't won or bought). Am I right?


Or maybe even with such type of card game (that require more data), should I store it between players anyway?


Could you also tell me if collections in challenge-instance are faster then normal one (runtime)? Are they limited to some amount of data?



Answer
Hey Peter,

The challenge-instance doesn't have a collection. But you can add script-data to a challenge-instance, along with private script data. Check out the api here for more details.

All data we are sending is SSL secured and in the unlikely event that something is intercepted, it will most likely to be intercepted when leaving the server, rather than on the client-side. So i would keep that in mind if you are worried about cheating. If it is a serious concern though, you could incorporate some checks into the game client-side and upon receiving an event request that would validate or check or anything strange.

I think, if security is an issue, you should keep the amount of data kept about the game at a minimum, and just have the players send the cards they are going to play each turn. You could also store each turn's info in the challenge-script data too. The benefit of this is that you can check in cloud code if the conditions have changed between turns. I.e. if the basic conditions of the opponents hand is different when the player takes their turn, it is likely the player has modified them, and so probably cheated.

You could also have some custom listeners and logeventrequest being sent every seconds or so, checking to see if the gamestate has changed.
Effectively update your game in slow real-time. Because you are dealing with a card game, this might be okay, but you've still got the security issues.

I dont see a problem with your first approach, with saving data into a collection though; i wont be any slower than any other way that will require you to check data in the cloud. If you have a collection for every challenge, and a manager that will drop that collection when a challenge ends, i dont see any problem with that.

Sean

 

Login to post a comment