Forum BigDB Recommended data structure for a Pokemon-like game

Discussion and help relating to the PlayerIO database solution, BigDB.

Recommended data structure for a Pokemon-like game

Postby Billy » March 10th, 2011, 6:16 am

I'm just getting around to starting with Player.io, and I'm wondering what the best way is to organize the data for a game like this. (Currently, a premium account is out of the question. I literally don't have the money to spare, until the game succeeds and pays for itself ;) lol, economy)

As you may know, in this game users catch monsters, and these monsters have tons of attributes of their own. There's a lot of them, and one goal is to "catch 'em all", so an active player would potentially have hundreds in their possession. Even after playing a few hours they would have dozens.

The problem I have is with:

1) Object count limits
2) Bandwidth consumption (for loading and saving objects)

With only 25K objects, storing each monster as an object would fill the DB quickly. That would be 100 monsters for 250 players. My plan then is to stick a few monsters in the Player object, and have a second object that stores all other monsters (let's call it the box). So, only two objects per player....but one will be kind of big, and the second will be absolutely massive. This would leave room to grow, though; now thousands of users could play long hours without hitting the storage limit.

My question then:

1) What would be your recommended design, if not like above?
2) Will the impact from loading and saving these massive objects be significant? (My intuition says yes!)


Below is a pretty realistic use case. The Pokemon gameboy games have this many values assigned to each monster. Would 400 of these assigned to one user in one object be doable, and would it chew up LOTS of bandwidth?

Code: Select all
'exampleuser' = {
   1: {
      Species: 'Exampachu',
      Nickname: 'Butts',
      isEgg: false,
      Level: 5,
      Exp: 331,
      Status: 'Burn',
      CurrentHP: 40,
      EV_HP: 50,
      EV_Attack: 50,
      EV_Defense: 50,
      EV_SpecialAttack: 50,
      EV_SpecialDefense: 20,
      EV_Speed: 20,
      IV_HP: 20,
      IV_Attack: 16,
      IV_Defense: 13,
      IV_SpecialAttack: 12,
      IV_SpecialDefense: 18,
      IV_Speed: 30,
      Item: 'Light Ball',
      Ability: 'Rain Dance',
      Nature: Timid,
      Cool: 100,
      Tough: 90,
      Beauty: 70,
      Smart: 120,
      Cute: 50,
      Moves: {
         1: {Name: 'Tackle', PP: 15},
         2: {Name: 'Growl', PP: 40},
         3: {Name: 'Thundershock', PP: 20},
         4: {Name: 'Thunderwave', PP: 20}
      }
   }
}
Last edited by Billy on March 10th, 2011, 10:00 pm, edited 2 times in total.
Billy
 
Posts: 4
Joined: June 23rd, 2010, 4:31 pm

Re: Recommended data structure for a Pokemon-like game

Postby HAnz » March 10th, 2011, 1:53 pm

Here is how I would do it.
Each player would have an array with the id:s of the pokemons they have caught: MyPokemons[1,13,3,16,57,43].

Then you would have a table called Pokemons where each Pokemon would be an object and contain all it's data. Then you just pull the data you need from the Pokemon table when you need it.
For example to load all your pokemons: "loadKeys("Pokemons", myPokemonsArray, callback, errorHandler)". <-- I'm not too sure that would be the correct code to do it but you get the picture. :)
I make games and stuff.
User avatar
HAnz
 
Posts: 46
Joined: August 7th, 2010, 2:59 pm

Re: Recommended data structure for a Pokemon-like game

Postby Henrik » March 10th, 2011, 4:28 pm

You obviously need to store each individual player's list of caught pokemons in BigDB, and if they can be customized, then those customizations go there as well.

But you can have a single master list of pokemons that the player lists just point to, and you don't even need to store this in BigDB, you can just hardcode it in both the serverside code and the client. If you store the master list in BigDB, then yes, you can easily change the values when you want to add pokemons or change the balance or whatever, without having to release a new version of the game, but at the same time you have to ask yourself how often you will really change the list?
Henrik
.IO
 
Posts: 1851
Joined: January 4th, 2010, 1:53 pm

Re: Recommended data structure for a Pokemon-like game

Postby Billy » March 10th, 2011, 9:50 pm

No no, the above stats are all "customizations". They are all stats which are unique to a specific monster. I used it to illustrate an actual use case; if you were recreating the actual Pokemon mechanics, you would need this much data for each monster. ("EVs" are trained in battle, "IVs" are like genes that give each creature a unique variation in its stats compared to its "base" stats for that species, their selection of 4 moves can be picked from a list of at least a hundred possibilities, even the PP can be increased permanently through items, etc, etc)

Granted I would shave off a few bytes by using id numbers instead move and species names, but the point remains that each creature absolutely needs 30-50 attributes, and there are lots of monsters per player. Most are in storage (the box) most of the time, but a team of six must be accessed frequently (in each battle).


HAnz wrote:Then you would have a table called Pokemons where each Pokemon would be an object and contain all it's data. Then you just pull the data you need from the Pokemon table when you need it.


Well unfortunately, if I do one monster <=> one object, I'll run out of space very quickly even with a small user base (so small it's not generating 25 bucks a month of revenue ;) ).

My only option seems to be to store a few on the player, and the rest in one or more monolithic "box" objects, and I'm wondering if the bandwidth from .load()ing and .save()ing will be significant
Billy
 
Posts: 4
Joined: June 23rd, 2010, 4:31 pm

Re: Recommended data structure for a Pokemon-like game

Postby HAnz » March 10th, 2011, 10:29 pm

I see, I missed that all the monsters are unique.

The easiest way to do it is actually the way I described, but instead of storing the monsters type id on the player you store it's unique id. It wouldn't use much bandwith since you only have to load the monsters you want to equip or whatever.

DB storage is relatively cheap, on the Plus plan you get 250k objects and you only pay $5 for 100k additional DB objects.

I would let free players keep lets say 20 monsters at once, if they want a new one they would have to "let another one go" (delete the DB object). And then paying players could keep way more, etc. If you start making money you could then increase the 20 monster limit for free players if you want since the income from paying players would easily cover it.

It should take a player at least a few hours to get 20 monsters they want to keep and by then some of them will be willing to pay up to "take the game to the next level".

It is by far the easiest solution as I see it. To get started on it you should make a great game and then you could have a PayPal donations button to get some starting capital and then get a Plus plan and add microtransactions. After that, fortune and fame! (maybe) :P
I make games and stuff.
User avatar
HAnz
 
Posts: 46
Joined: August 7th, 2010, 2:59 pm


Return to BigDB



cron