question

harsh avatar image
harsh asked

Data Model for Pokemon-Like Game

Hey there,


I'm creating a game that is in theory very close to Pokemon. Thus, I'm using its example as most readers should be aware of the game already.

I want to store almost all of the logic/data on PlayFab itself. However, I'm running into some design problems and would like advice on which PF feature to use for each game feature.

1. Pokemon

It seems the general idea would be to have a Catalog for the pokemon themsevles, with each item describing a unique pokemon in its custom data, such as base stats, stat gain/level, base skills, possible skills it can learn, etc. Then, each item instance can describe each pokemon instance, e.g. current level, current total xp, current HP, current stats, current skills, nature, shiny/notshiny, etc. I'm hoping to compress this data as much as possible, as I know space is limited in custom data.

2. Skills

The skills themselves will follow rather simple mathematical formulas, so carrying them out as logic isn't a problem for me. However, I'm wondering where I could store this information. Should I just have another catalog and make each item a skill? Then I could store the ItemId of the skill wherever I need to reference it.

3. Battles

I'm thinking of using Cloudscript for all other game functions, and Azure Functions for battles because of the comparitively larger amount of processing required. I believe I'll have to pre-compute the whole battle and send back the record to the client? I don't believe I can have live, choice-based battles, right?

4. Maps

The only map data I require is the ability to have an associated drop table for each "region" of the map, so I can determine what drops or pokemon are encountered by time of day and region. My game will use an energy based system for encounters, instead of plain roaming in the grass.

5. Equipments

The player can equip certain items to each pokemon. I believe this will be a catalog-item system as well.

6. Quests / Rewards

I need some way of being able to give the player story-based quests and keeping track of which quests have been completed/rewarded. Essentially, a way to store game progress.

7. Growth Items

Think of the "fishing rod" in Pokemon. I want to give certain items to my player that will unlock zones and aid in other things (e.g. more movement speed). However, I also want these items to be able to be upgraded, e.g. by feeding game currency. Should I go for another catalog-items system?

8. Player Config

Things like currently selected team, current fashion, etc. Ideally, I'd want a way so this can't be changed during battle.

So far, I've only encountered Catalog Items and Shared Group Data for storing such custom data. I'm not sure what are the extents of storage for Title Data and Player Datas. Are there any "data storage" options available in PlayFab?

If some of this stuff can't be solved inside PlayFab, or would just be plain better if done in a custom service or another azure service (anything easily attachable with PF), please recommend that as well.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Seth Du avatar image
Seth Du answered
  1. Pokemon. It should work fine.
  2. Skills. I believe it is a shared resource that shouldn’t be changed frequently, which means you may store it in Title Data.
  3. Battle. As it is a turn-based game, you may consider using Shared Group Data and PlayFab has provided a official sample on: https://docs.microsoft.com/en-us/gaming/playfab/features/social/groups/using-shared-group-data#example-turn-based-multiplayer-async-games
  4. Maps. Title data is still a good choice. However, since querying title in Cloud Script every time is not optimized and resource wasting, I will consider to pre-define those drop table in a static value in the Cloud Script/Azure function.
  5. Equip. Yes, it should be defined in the catalog. You may store a mapping value in Player Read-Only Data. If possible, using custom data of inventory items(pokemon) will be another workaround.
  6. Quests. It should be stored in Player Read-Only Data, or Entity Objects without player’s write permission (it should be verified and updated by server side)
  7. Growth items. Can be stored as a durable inventory items. The “update” feature can be implemented by Cloud Script.
  8. Player Config. Player Read-Only Data should work. Cloud Script/Azure function can detect the state and do the update.
6 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

harsh avatar image harsh commented ·

A bit of a digression: Entity API vs Older Player API? Would I be missing any features by using the newer API? My only bias is that I'm used to the older API, but since this is a new project, I wouldn't mind using Entities from the get-go. Not to mention, it seems storage for entities is much lesser (5 objects, 1kb each). Let me know if there's any significant benefits to this.

Other than that, the game will have a bunch of maps, let's say 50 for starters. Each map will then have 5-6 regions which will each have a drop-table depending on the time of day (say 3 -- morning, evening, night). We're looking at 750-1000 drop-tables. Now, I could setup an admin-side thing where this is all defined in an sql table or something and then formatted and added to a CloudScript file that is revisioned through GitHub, but I'd really like to know if there's a much simpler alternative, especially considering the 1mil byte limit.

Finally, are there any real-life records of Cloudscript vs Functions cost-wise? It is my understanding that Functions are objectively better than than javascript Cloudscript, but they seem to cost more.

As for turn-based, the matches will actually be automated.

0 Likes 0 ·
Seth Du avatar image Seth Du ♦ harsh commented ·

>>if there's any significant benefits to this.

Classic Player Data will be more convenient to use and certain APIs can be restricted by editing API Access Policy, meanwhile entity data model is still in development, yet it can be more flexible. By editing Entity Policy, the access permission of different keys can be varied. However, the API call itself cannot be restricted by any policies. Please feel free to use both of them.

>> maps

I will still recommend to directly define drop tables in Catalog. Define static value in Cloud Script/Azure function can be another workaround, while you have noticed the size limit. PlayFab doesn't support customized database, If necessary, you may implement an external database, and use Cloud Script/Azure function for retrieval or update.

>>Cloudscript vs Functions cost-wise?

The cost will be very close. The execution time consumption will be the same, while for Azure Function, PlayFab will charge additional $0.2 per million executions (if in standard plan), and the rest is charged on Azure-side. In total, both of them will have very similar cost, but Cloud Script doesn't support importing external module, libarary.

0 Likes 0 ·
harsh avatar image harsh Seth Du ♦ commented ·

The 0.2$/1mil execs is nothing.

When you say "the rest is charged on Azure-side", are you factoring in this cost when you say Cloudscript and Azure costs will be very similar? Or is that separate?

0 Likes 0 ·
Show more comments
harsh avatar image harsh commented ·

Another follow-up question.

It says the limits for inventory item custom data key is 20 bytes and value is 100 bytes, with up-to 5 updates per request. However, the Limits page doesn't say how many key-value pairs I can have inside an inventory item custom data. Any idea about this?

0 Likes 0 ·
Seth Du avatar image Seth Du ♦ harsh commented ·

If the quantity is not stated in the limit page, it means only the total data size will be counted.

1 Like 1 ·
harsh avatar image
harsh answered

Thankfully player data limit is VERY generous. I won't need to worry about cutting corners like with catalog items.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.