Sign In Register

How can we help you today?

Start a new topic
Answered

Multiplayer Card Game & Fair usage policy

 Hi, I am new to Gamesparks. I am working on developing a turnbased multiplayer cardgame using Unity & Gamesparks. There will be 4 players per room and the people sitting opposite to each other will be partners. I am interested in showing profile pictures for the players (may be through facebook or by letting them set the picture). It would be helpful for me if someone could confirm that this can be done using Gamesparks and give me some directions of the basic steps involved.


I also noticed the Fair usage policy: API Requests: 5,000 per MAU. Data: 20MB per MAU. Bandwidth: 10MB per MAU.

Would the multiplayer card game that I am working on with profile pictures hit the limits mentioned above? What are considered API requests and what are not? Would the profile pictures take up the 10MB per MAU bandwidth? What can I do to make sure that I confirm to the Fair usage policy? Sorry about the many questions and thank you for your help :)


Best Answer

Hi Rajeeve,


API Requests entail any calls the client makes to the server, be it to authenticate, retrieve data such as leaderboards or player information, and interact with any cloud code or events you have defined in the portal. For more information on these requests please visit the Client API Documentation


As for profile pictures it largely depends on the file format and resolution of the picture you would like to upload. JPG's are generally used for this due to their lossy compression, while PNG's addition of an alpha channel can differentiate your images even more. File formats like TIFF and GIF are not recommended. For your purposes, I don't see an issue in using a JPG with a resolution of less than 500x500, and estimate it being only a few KB's in size.


There is also the option of getting profile picture information from external API's provided by Facebook, Twitter and Steam (authenticated with Gamesparks). For more information on how to integrate your game with these services please look at our Tutorials.


If you have any additional questions please feel free to ask more.


Pádraig




Answer

Hi Rajeeve,


API Requests entail any calls the client makes to the server, be it to authenticate, retrieve data such as leaderboards or player information, and interact with any cloud code or events you have defined in the portal. For more information on these requests please visit the Client API Documentation


As for profile pictures it largely depends on the file format and resolution of the picture you would like to upload. JPG's are generally used for this due to their lossy compression, while PNG's addition of an alpha channel can differentiate your images even more. File formats like TIFF and GIF are not recommended. For your purposes, I don't see an issue in using a JPG with a resolution of less than 500x500, and estimate it being only a few KB's in size.


There is also the option of getting profile picture information from external API's provided by Facebook, Twitter and Steam (authenticated with Gamesparks). For more information on how to integrate your game with these services please look at our Tutorials.


If you have any additional questions please feel free to ask more.


Pádraig



Thank you for your reply. In this turnbased cardgame each player would play a card and send a message to the server and then server passes the turn to another player. Hundreds of such turns would take place. Would each of those turns count as API request?

Also if the four players are in a chat system and they each send 100 messages would each of those 100 messages be counted toward the API requests for that player?

 

If a game takes in average of 100 requests per game then that would be on a per player basis, so each player would be able to play 50 games a month on average. Bear in mind that this is not a a hard limit (The service will still serve requests that is) but exceeding this limit will more than likely flag us here at Gamesparks HQ and we will probably get in contact with you.


If you anticipate that your game's average use-case will exceed this monthly limit then please feel free to contact us further to negotiate special terms. I believe if you design your system efficiently, however, Gamesparks will suit your needs for the vast majority of these use cases.


If you have any further questions please feel free to let me know


-Pádraig

Thank you for your response.

 

I too am curious about more details pertaining to fair usage.  What all counts as user data?  Is it just uploaded binary files, or is it also ScriptData?  Goods inventory?  Does it include all challenge data tied to the user, or are those separate since each is tied to multiple users?


I ask because since my game is turn-based and asynchronous, I need to store all details about the game board twice - one for before the turn plays out, and one for after.  Then the client can replay the turn for the next player.  Ideally I'd also keep a tight log of all moves so someone could re-read the history of the match.  This could take quite a bit of data, also considering that a player may have several challenges going simultaneously.


I think each challenge could end up averaging from 20-50 KB of ScriptData.  Even if that doesn't count toward "user data", it would make 10 MB of monthly bandwidth seem pretty low.  I think it works out to 6-7 turns per day.  Max 30-ish turns per day, which is still real low.  I think you said it averages across all players, so maybe it will be fine when averaged out.  Really tough to predict before playtesting and launching...  I am concerned.  It's at least good that it's not an automatic shutoff if I reach the limit.  I'm going to put some more work into compressing the ScriptData.

Looks like I might be able to compress my challenge ScriptData down to average 7 KB.  It's a day or two of work, and it makes the challenges tougher to debug, but it's a considerable savings of bandwidth and storage.  /thinking out loud...

I wasn't aware of this issue, now that you mention it, I have a ton of questions popping out in my head... I hope it doesn't pose a great problem later.

my game aside, how do FPS game developers sync player positions with such limits ? I thought every update on the x, y, z, keystroke, face angle in the x, y, z dimensions, mouse clicks.. all of these, each and every update to those values would fire a request, I feel so wrong now that I see this kind of limit on the platform dubbed as the top BaaS, can someone enlighten me ?

I spent a few hours today examining GameSparks and was quite excited but the useage limits just seem unreasonable for everything but simple games.  The reality is if you want the server to be the authority of your game logic, which you do, then you're going to need to call it a lot.


For example equipping an item to a character needs to be validated with the server, you can effectively bundle things together (ie prompt the player to switch all equipment then confirm it for a single request) but even so if the player switches a lot you're up the creek.


5,000 ad 10M bandwidth means an average of 2.048KB per request, which is only 262.144 characters.  This is fine for a lot of requests, but the initial pull for user data will likely far exceed this.

Hi Ben Keess, 

Could I ask what kind of game you intend to develop. We have a comprehensive RealTime API for games with that level of server authority, along with a separate, bespoke arrangement for its usage. 


Happy to answer any questions you may have.

Look forward to hearing from you - Patrick.  

I know this is an old topic but I have a few questions still. A good question was in regards to chat. If a game chat is implemented with gamesparks going over the fair usage quota is almost certain. Is there a solution? Also, if a game uses the RT matches, do the api requests from the RT scripts count towards the total? What about calls from custom events. I have an event request that client sends, which makes multiple calls to the database api, does that still count as one api request?
Login to post a comment