Indie-Resource.com

Dear members,

Any tips in regard to modelling a database specific for games? How to abstract layers, how to link it all together. Best practices, how to optimize game query`s et cetera.

Any / all tips are welcome!

Kind regards, Xaleph

A pretty common method for database layout for a PBBG begins something like this:

(pseudo-SQL obviously)

Player table:
1. playerid - key
2. username
3. password
4. (anything other uniquely identifying data that is not specifically game-related)

Stats table:
1. statsid - key
2. playerid - foreign key
3. hp
4. strength
5. (the rest of your stats)

Weapons table:
1. weaponsid - key
2. playerid - foreign key
3. weaponsname
4. damage
5. (anything else)

...and I think you start seeing a pattern

I know you said you were rather versed in coding, but not game coding. I think you will come to find that PBBGs actually require only simple SQL queries for the most part when you compare them to the business and academic sectors. When you need to know data, you typically have an ID of the player you need, and you pull them up, or you have an ID of a monster type you pulled from a random number generation, so you pull up the monster, or the ID of an item that a script generated, so you just pull it up.

The requirements of knowing how data interacts and relates in a PBBG is typically quite low. In fact, in all of the PBBG coding I have done, I have not needed any kind of complex joins or any other more advanced aspects of SQL that would make you have to lay your tables out more carefully. Not that you can just throw them together in any old way, but as long as you just be sure to keep different types of data separate, you will be fine (which you can see me doing above). As long as you keep your tables modular like this, your tables can grow easily and painlessly when needed, and it will cut down on the amount of empty spaces in the database, keeping size down and helping with performance. That is really all there is to it, which I have a feeling you may have already known. And of course, only one piece of info per cell (no comma-separated "lists" in a single column), but that is day one stuff that I am sure I don't have to reiterate here

Thanks you for the help! If in fact the SQL is not that hard, pff, worries over nothing right? I was kind of abstracting the weapons too. Given the fact that all weapons have to be stored somewhere, without having an owner. Or let me rephrase that, weapons must have a blueprint in order to be sold to a user. And sold means selling, finding, looting. Aquiring would be a better word.

Anyhow, while i was normalizing i came up with 29 tables, i suppose this is normal for a small brower game? If i include a backend panel for regular updates/maintainance, i normalized it to around 43. This includes the blueprint tables for weapons/housing etc.

Is this all it takes? Besides, i have very little tweeners between the tables, i expected way more.. Odd..

Oh crap, I totally forgot about "master lists" and just got too into making them in that pattern, but you have basically already hit on that. But yes, you would need to have a Master Monster table, which lists the names and attributes of all the monsters in your game, a Master Weapon table (or M. Swords, M. Staves, etc., just depending on how different each category is), Master Armor table, etc. That saves a huge amount of space by simply having to use a weapon ID in the player's inventory, for example, instead of listing out all of the stats for every player who owns one. And even more important than space, it prevents update anomalies from occurring when you change the stats on items, mobs, and other things, since it only has to be updated in one place.

Yeah, masterlist is my definition called "blueprint" i suppose. Like i said, no experience in game dev!

I just realise, weapons tables ( not masterlists ) are merely the tweeners, lol. With a few added parameters. Geez, logic always beats me!

"Master<Blank>" is just how I name them in my database. I don't think there is any real, defined term for them. Even though PBBGs are nothing new (some people have stories of playing old PHP PBBGs as early as the mid-to-late 90's), their development has been largely in pockets of isolation until just the past couple of years. Developer sites like this one and gamer-oriented sites such as Galaxy News are finally having PBBG developers and players connect to each other outside of the games, and real discussion about them has only been going on for a few years now. The change was probably largely brought on by the push to establish the name PBBG to describe them (with a massive effort by the organization linked), thus starting to find ways of categorizing them and bring them into conversation. So while PBBGs are maturing, the lexicon to discuss them is still in its infancy. You won't find nearly as colorful a vocabulary in the world of PBBG development as you would in traditional game development. At least not yet

Hahaha great ! I`m totally new to the gaming scene, let alone the PBBG. I don`t even know what that means, altough a short google query would give an awnser i suppose. I really like this site, if only for the purpose of connecting to fellow soon to be- and game devs. Especially oriented on the browser scene. Not much material to find out there, i reckon it`s not that hard to do it all on your own, but with little help, it saves tons of time / resources. Simple questions as how to model a database can be awnsered straight, whilst the difference is not that big compared to regular applications, it`s still good to know it`s not. When in doubt, asking questions is almost always better then to work around

Absolutely!

And as far as the background on what exactly a PBBG is, you should check out the link I made above (on the term "PBBG"). While likely the PBBG "organization" is just one or two people, I do find it interesting that someone/a group was passionate enough about these types of games to make the website just to try to get the term out there for them. And it seems to have worked. Heck, I am using the term right now!