SOLVED RPG's on BrainCloud?

  • Hey folks,
    I am trying to figure out whether BrainCloud would be a good fit for an RPG game I am making. I have some questions.

    1. Would Braincloud handle RPG style games well? Multiple characters, character inventory, stats, multiple classes, skills, Powers, etc? How would you track them?
    2. Where is profileId and anonymousId stored, and is it stored securely with the web SDK on mobile devices?
    3. How would I track IAP items per character as well as currency, etc?
    4. What happens if a player is playing offline (no internet)? Will braincloud hold all changes until they connect? Is there a limit to how many calls that will be 'held?'
    5. Any other helpful tidbits?
      Thanks in advance,

  • bitHeads

    Hi Chad,

    Sorry for the late reply.

    1. Yes, brainCloud can handle RPG style games well, it provides a rich set of features that benefits any type of game - includes very flexible multiplayer tech, Our built-in real-time multiplayer services are more based around the idea of shared game experiences that last a finite period of time (i.e. arena shooters, casual multiplayer, etc.). Our matchmaking, lobby services, room server system, etc are all geared toward making this sort of experience easy and inexpensive to build - but also can integrate with 3rd party or custom tech. brainCloud provides support for custom Room Servers that can support any type of custom or 3rd party multiplayer tech. For all these characters related data (user data), you can use User Entity or Custom Entity to store and trace them.
    2. The end-user profileId and anonymousId are stored securely in the client library wrapper on user devices.
    3. Users' IAP items and currency end up “unlocking” “awarding” these to the associated profileId, so that will never be lost.
    4. If a player is offline, you need to have some code on your side to handle this situation with the request callbacks, as long as “update()” is not called, it will not process sending packet bundles or process callbacks from the received packets. Shouldn't keep all calls for later. Instead, update player stats once connected, in 1 call.

    Hope that helps!

  • This post is deleted!

Log in to reply