The problem is that you have an object with a ton of properties that are incredibly similar and they describe the object in a yes|no fashion. In my case, players can do 24 types of research and the state of the player is “yes, I have done that particular research” or “no, I have not done that research”.

One solution is to make a table with a column that associates with the player id and a boolean column for every type of research that you have. Now if you have 24 types of research your table is 25 columns big. This can get out of hand pretty quickly. The table becomes hard to read and you have to use different code (or procedurally dynamic code) to set individual columns.

Another solution is to add a column to your player definition table and make it type INT UNSIGNED. Then you let your code efficiently handle interpreting the integer as the player’s research definition through bit masking. Here’s how it works.

The maximum value of an unsigned INT in MySQL is 4294967295. In binary this number looks like 11111111111111111111111111111111. That is 32 1’s in a row. Each of those digits can describe a research type as ‘have’ (it is a 1) or ‘have not’ (it is a 0). Now in a global file for your code you need to define each research type as a number that is a power of 2. It would look something like this in PHP:

$g_shield_research = 1;              // in binary 001
$g_armor_piercing_research = 2;  // in binary 010
$g_mining_research = 4;             // in binary 100

Now if you want to know whether you have a particular research you would perform a bitmask operation on the integer you retrieve from your database using the & operator.

// will mask players research and return true if the mining bit is set to 1
if ($element->research & $g_mining_research)

The bit masking procedure is extremely efficient and fast and you can see how it compresses all the research information into the size of an integer. Also, if you want to know everything about a player’s research you only have to retrieve a single integer from the database.

Assigning research to a player is also very easy. Simply bitwise OR the current research integer with the set bitmask using the | operator:

$newPlayerResearch = $element->research | $g_shield_research;

You can technically add the two numbers to get the same result, but this is unsafe because if you add the research when it is already there it will throw everything off.

There are some pitfalls to using this trick. While it is easy to add another type of research just by assigning its mask to the next highest power of 2, you are limited to 32 total research types. One way to get around this is to make the column type BIGINT which would give you 64 bits to work with, but at the end of the day you are still limited. Also, once a game starts the research you choose for that bit position is pretty much stuck there unless you want to do some math maintenance.

While this trick will tend to make your code more readable because database statements won’t be as long, your database entry will not be human readable so it could slow down your debugging efforts.

So there you have it. A very powerful tool if used wisely. Please design well before you start writing code. It makes life easier.

To begin with, we’ll need a users table.

CREATE TABLE users (
	id int NOT NULL AUTO_INCREMENT,
	username text,
	password text,
	PRIMARY KEY(id)
);

And once we have that, a stats table:

CREATE TABLE stats (
	id int NOT NULL AUTO_INCREMENT,
	display_name text,
	short_name varchar(25),
	PRIMARY KEY(id)
);

If this all looks familiar so far, that’s because it should – this is the exact same table structure(currently, anyway) as the game we’ve been working on. I’m taking all of the design decisions and changes that we made in our other project, and doing my best to apply them here – thereby continually improving my code, and my design.

Because Working Title will have a few distinct ‘entities’, my entity_stats is going to look a little bit different than the one we’re using right now. According to the design document, there are 4 main entities – players, rooms, monsters, and items. Those will make the enum in the entity_stats table:

CREATE TABLE entity_stats (
	id int NOT NULL AUTO_INCREMENT,
	stat_id int,
	entity_id int,
	value text,
	entity_type ENUM('User','Monster','Item','Room'),
	PRIMARY KEY(id)
);

Thinking about it a little more, I’m pretty sure that I don’t need separate tables for each of the entities that can exist within Working Title – all I need is a single table to keep track of their name, ID, description, and type. So that’s what I’m going to do:

CREATE TABLE entities (
	id int NOT NULL AUTO_INCREMENT,
	name text,
	entity_type ENUM('Monster','Item','Room'),
	description text,
	PRIMARY KEY(id)
);

One of the things that the design document mentions is that “users will move between rooms” – which means that I will need way to track which room a user is currently in. I’m going to use a stat to do this:

INSERT INTO stats(display_name,short_name) VALUES ('Current Room','cur_room');

There are also supposed to be players, monsters, and items inside rooms – so I’ll need a table to keep track of all the entities within a room:

CREATE TABLE room_entities (
	id int NOT NULL AUTO_INCREMENT,
	room int,
	entity_id int,
	entity_type ENUM('Monster','User','Item'),
	PRIMARY KEY(id)	
);

Monsters will be able to drop items, so I’m going to need to add a table to do that. Because all they’re going to be able to drop is items(not other monsters or rooms or anything), I can make it so that the monster_drops table only contains information on what items, and what the percentage chance is for them to drop:

CREATE TABLE monster_drops (
	id int NOT NULL AUTO_INCREMENT,
	monster int,
	item int,
	drop_rate int,
	PRIMARY KEY(id)
);

The next table I need to add is one to track a user’s inventory – so I’ll add the user_items table:

CREATE TABLE user_items (
	id int NOT NULL AUTO_INCREMENT,
	user_id int,
	item int,
	quantity int,
	PRIMARY KEY(id)
);

The design document mentions “____ of holding”'s, which is something I haven’t quite figured out yet. I could just use a stat to keep track of the player’s current inventory limit, or I could come up with a better idea. For the moment, I’m going to leave this piece of functionality out of my database design – I’m not sure how to build it yet.(If you know a good way to do this, send me an e-mail at buildingbrowsergames@gmail.com, or comment on this blog post)

Based on the list of commands players can use, there are a few stats that I can add into the database right now:

INSERT INTO stats(display_name,short_name) VALUES ('Maximum Health','max_hp');
INSERT INTO stats(display_name,short_name) VALUES ('Current Health','cur_hp');
INSERT INTO stats(display_name,short_name) VALUES ('Current Weapon','cur_weapon');
INSERT INTO stats(display_name,short_name) VALUES ('Current Armor','cur_armor');
INSERT INTO stats(display_name,short_name) VALUES ('Current Ring (Left Hand)','cur_ring_left');
INSERT INTO stats(display_name,short_name) VALUES ('Current Ring (Right Hand)','cur_ring_right');
INSERT INTO stats(display_name,short_name) VALUES ('Gold In Bank','bank_gc');
INSERT INTO stats(display_name,short_name) VALUES ('Gold In Hand','hand_gc');
INSERT INTO stats(display_name,short_name) VALUES ('Current Level','cur_lvl');
INSERT INTO stats(display_name,short_name) VALUES ('Current Experience','cur_exp');
INSERT INTO stats(display_name,short_name) VALUES ('Experience to Next Level','next_exp');

That sets me up with some of my starter stats, although it’s definitely not all of them – I’m sure I’ll end up adding more stats as Working Title grows into more of a finished product.

The last table that I’m going to add for now is simply for keeping track of exits off of rooms: room_exits:

CREATE TABLE room_exits (
	id int NOT NULL AUTO_INCREMENT,
	name text,
	from_room int,
	to_room int,
	PRIMARY KEY(id)
);

I’ll be tracking the entity_id of both of the rooms, and using the name value to select which exit. For example, an exit to the North from room 1 to 2 might look like this:

INSERT INTO room_exits(name,from_room,to_room) VALUES ('North',1,2);

With all this finished, there’s only one more system to add – spells. I’m not quite sure how I want to implement spells yet, either – do I want to have them do a set amount of damage, or base it on level, or something else? I’m going to hold off on designing any database tables for my spells system for now – once I have Working Title in a playable state, I’ll work on adding spells. For now though, I’m going to stick with what I have – I’ve got the basics of my database in place, and I can safely start developing now.

With that in mind, we’re going to create another table, to replace those three. Because lots of different things can have stats, I’m going to call the table entity_stats – although if you want to, you can call it whatever you want(but make sure to keep your change in mind when you’re working through this code). Here’s what we’re going to do to create the table:

CREATE TABLE entity_stats (
	id int NOT NULL AUTO_INCREMENT,
	stat_id int,
	entity_id int,
	value text,
	entity_type ENUM('User','Monster','Item'),
	PRIMARY KEY(id)
);

Now that we’ve created this new table, we’re going to need to customize our SQL queries slightly. Previously, we were only using an object’s ID value to retrieve the stats for it – now that we don’t have that separation, we will need to run the query based on two things – the object’s ID, and the object’s type.

Because we’ve been doing re-writing to our stats code, we’re actually in a good position to make this change – we only need to change the query in one file, instead of 3(or more). Our old SQL looked like this:

"SELECT value FROM table WHERE stat_id = (SELECT id FROM stats WHERE display_name = 'foo' OR short_name = 'bar') AND column = 'baz'"

The new SQL is going to look like this:

"SELECT value FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = 'foo' OR short_name = 'bar') AND entity_id = 'baz' AND type = 'bat'"

One of the benefits of doing this is that we’re actually going to be cleaning up our new DRY stats code a little bit more, too – we get to trim it down to only take a ‘type’ argument, instead of the table and column names it needs to retrieve with. Think back to our DRY stats code from earlier:

PHP

1
2
3
4
5
6
7
8
9
10
11
12

function getStatDRY($tableName,$columnName,$statName,$trackingID) {
	createIfNotExistsDRY($tableName,$columnName,$statName,$trackingID);
	$query = sprintf("SELECT value FROM %s WHERE stat_id = (SELECT id FROM stats WHERE display_name = '%s' OR short_name = '%s') AND %s = '%s'",
		mysql_real_escape_string($tableName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($columnName),
		mysql_real_escape_string($trackingID));
	$result = mysql_query($query);
	list($value) = mysql_fetch_row($result);
	return $value;		
}

Perl

1
2
3
4
5
6
7
8
9
10
11

sub getStatDRY {
	my ($tableName,$columnName,$statName,$userID) = @_;
	my $dbh = $dbh;
	createIfNotExistsDRY($tableName,$columnName,$statName,$userID);
	my $sth = $dbh->prepare("SELECT value FROM $tableName WHERE stat_id = (SELECT id FROM stats WHERE display_name = ? OR short_name = ?) AND $columnName = ?");
	$sth->execute($statName,$statName,$userID);
	my $value;
	$sth->bind_columns(\$value);
	$sth->fetch;
	return $value;
}

And here’s what it looks like with the change made:

PHP

1
2
3
4
5
6
7
8
9
10
11

function getStatDRY($type,$statName,$trackingID) {
	createIfNotExistsDRY($type,$statName,$trackingID);
	$query = sprintf("SELECT value FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = '%s' OR short_name = '%s') AND entity_id = '%s' AND entity_type = '%s'",
		mysql_real_escape_string($statName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($trackingID),
		mysql_real_escape_string($type));
	$result = mysql_query($query);
	list($value) = mysql_fetch_row($result);
	return $value;		
}

Perl

1
2
3
4
5
6
7
8
9
10
11

sub getStatDRY {
	my ($type,$statName,$trackingID) = @_;
	my $dbh = $dbh;
	createIfNotExistsDRY($type,$statName,$userID);
	my $sth = $dbh->prepare("SELECT value FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = ? OR short_name = ?) AND entity_id = ? AND entity_type = ?");
	$sth->execute($statName,$statName,$trackingID,$type);
	my $value;
	$sth->bind_columns(\$value);
	$sth->fetch;
	return $value;
}

Once we’ve made those changes, it’s easy to modify all of our code for the new database structure:

PHP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<?php
 
include 'database.php';
 
function getStatDRY($type,$statName,$trackingID) {
	createIfNotExistsDRY($type,$statName,$trackingID);
	$query = sprintf("SELECT value FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = '%s' OR short_name = '%s') AND entity_id = '%s' AND entity_type = '%s'",
		mysql_real_escape_string($statName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($trackingID),
		mysql_real_escape_string($type));
	$result = mysql_query($query);
	list($value) = mysql_fetch_row($result);
	return $value;		
}
 
function setStatDRY($type,$statName,$trackingID,$value) {
	createIfNotExistsDRY($type,$statName,$trackingID);
	$query = sprintf("UPDATE entity_stats SET value = '%s' WHERE stat_id = (SELECT id FROM stats WHERE display_name = '%s' OR short_name = '%s') AND entity_id = '%s' AND entity_type = '%s'",
		mysql_real_escape_string($value),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($trackingID),
		mysql_real_escape_string($type));
	$result = mysql_query($query);
}
 
function createIfNotExistsDRY($type,$statName,$trackingID) {
	$query = sprintf("SELECT count(value) FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = '%s' OR short_name = '%s') AND entity_id = '%s' AND entity_type ='%s'",
		mysql_real_escape_string($statName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($trackingID),
		mysql_real_escape_string($type));
	$result = mysql_query($query);
	list($count) = mysql_fetch_row($result);
	if($count == 0) {
		// the stat doesn't exist; insert it into the database
		$query = sprintf("INSERT INTO entity_stats(stat_id,entity_id,value,entity_type) VALUES ((SELECT id FROM stats WHERE display_name = '%s' OR short_name = '%s'),'%s','%s','%s')",
		mysql_real_escape_string($statName),
		mysql_real_escape_string($statName),
		mysql_real_escape_string($trackingID),
		'0',
		mysql_real_escape_string($type));
		mysql_query($query);
	}	
}
 
?>

Perl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

package statsDRY;
 
use database;
 
sub getStatDRY {
	my ($type,$statName,$trackingID) = @_;
	my $dbh = $dbh;
	createIfNotExistsDRY($type,$statName,$userID);
	my $sth = $dbh->prepare("SELECT value FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = ? OR short_name = ?) AND entity_id = ? AND entity_type = ?");
	$sth->execute($statName,$statName,$trackingID,$type);
	my $value;
	$sth->bind_columns(\$value);
	$sth->fetch;
	return $value;
}
 
sub setStatDRY {
	my ($type,$statName,$trackingID,$statValue) = @_;
	my $dbh = $dbh;
	createIfNotExistsDRY($type,$statName,$userID);
	my $sth = $dbh->prepare("UPDATE entity_stats SET value = ? WHERE stat_id = (SELECT id FROM stats WHERE display_name = ? OR short_name = ?) AND entity_id = ? AND entity_type = ?");
	$sth->execute($statValue,$statName,$statName,$trackingID,$type);
}
 
sub createIfNotExistsDRY {
	my ($type,$statName, $trackingID) = @_;	
	my $dbh = $dbh;
	my $sth = $dbh->prepare("SELECT count(value) FROM entity_stats WHERE stat_id = (SELECT id FROM stats WHERE display_name = ? OR short_name = ?) AND entity_id = ? AND entity_type = ?");
	$sth->execute($statName,$statName,$trackingID,$type);
	my $count;
	$sth->bind_columns(\$count);
	$sth->fetch;
	if($count == 0) {
		# no entry for that stat/user combination - insert one with a value of 0
		$sth = $dbh->prepare("INSERT INTO entity_stats(stat_id,entity_id,value,entity_type) VALUES ((SELECT id FROM stats WHERE display_name = ? OR short_name = ?),?,?,?)");
		$sth->execute($statName,$statName,$userID,0,$type);
	}	
}
 
 
1;

And with that done, our change is made! Now it’s just a matter of modifying the code we created for each stat specifically(only one shown):

PHP

1
2
3
4
5
6
7
8
9
10
11
12

<?php
 
require_once 'stats-dry.php';
 
function getStat($statName,$userID) {
	return getStatDRY('user',$statName,$userID);
}
function setStat($statName,$userID,$value) {
	setStatDRY('user',$statName,$userID,$value);
}
 
?>

Perl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package stats;
use DBI;
 
use statsDRY;
 
sub getStat {
	my ($statName,$userID) = @_;
	return statsDRY::getStatDRY('user',$statName,$userID);
}
 
sub setStat {
	my ($statName,$userID,$statValue) = @_;
	statsDRY::setStatDRY('user',$statName,$userID,$statValue);
}
 
1;

And once all of the changes are done, you’re good! Now all of the stat values will be stored in a single table.

But what about users who have already registered for your game, or monsters and items that you’ve already added?

We definitely don’t want to have to tell every single person playing our game to re-register – so we’re going to write some quick SQL to copy the values over for us, before removing the tables that we no longer need:

INSERT INTO entity_stats(stat_id,entity_id,value,entity_type) (SELECT stat_id,user_id,value,'user' FROM user_stats);
DROP TABLE user_stats;
INSERT INTO entity_stats(stat_id,entity_id,value,entity_type) (SELECT stat_id,monster_id,value,'monster' FROM monster_stats);
DROP TABLE monster_stats;
INSERT INTO entity_stats(stat_id,entity_id,value,entity_type) (SELECT stat_id,item_id,value,'item' FROM item_stats);
DROP TABLE item_stats;

Once we’ve run that SQL, we’ll have deleted our 3 new tables – but not before we moved the data over from them to our new entity_stats table. Once you make the necessary modifications to your stats code and upload it all, take a look at your game – it will still work just like it did before!

This might seem like a weird thing to get excited about, but it’s a pretty big deal – we just changed a significant portion of our database, and didn’t break any of our existing code at all. This is why the DRY approach is so useful to have, and why you should always strive to use DRY in your designs to begin with – because making this change with the database logic spread accross dozens of files would drive even the calmest developer batty.

Designing an inventory system like this takes time – you can’t just throw everything together and hope it works. You need to plan it out first.

One question you need to ask yourself is: what about different item types? If there are weapons, armor, and general items, how will you handle that?

A hard-coded solution would be to create three tables – weapons,armor, and items. But at that point, you have a problem; how will you link specific items to something like monsters? You would need to create three more tables – monster_weapons, monster_armor, and monster_items. And then figuring out what particular item a monster might drop at any given time would be a major headache.

An easier solution to this is to create a single items table, with a ‘type’ column that can be used to track the type – that way, we only need to link monsters up to single items, and we can retrieve all of the monster’s droppables with a single, simple database query. Here’s what a simple items table might look like:

CREATE TABLE items (
	id int NOT NULL AUTO_INCREMENT,
	name text,
	type text,
	PRIMARY KEY(id)
);

At this point, we now have a single table that we can use to track our different items – and the flexbility to categorize them all by type if we so choose. This allows us to do something like this to create three different items(each a different type):

INSERT INTO items(name,type) VALUES ('Wooden Armor','armor');
INSERT INTO items(name,type) VALUES ('Wooden Sword','weapon');
INSERT INTO items(name,type) VALUES ('Red Potion','consumable');

By building our items table in this way, we only need one table to link a monster to the items that they will drop – and we can easily make them drop any type of item we want them to. We can also create an item_stats table, so that all of our items can have stats applied to them:

CREATE TABLE item_stats (
	id int NOT NULL AUTO_INCREMENT,
	item_id int,
	stat_id int,
	value text,
	PRIMARY KEY(id)
);

And this way, we can leverage our stats system to allow our items to have the same stats as our players or our monsters. We can easily add and remove stats for any item we choose – if a potion should have a defence of 4 and a maximum HP of 8, we can do that. The flexibility is there.

While it’s not the perfect system, this inventory system is ‘good enough’ – as long as the only thing you know is that you will need to add and remove item types, and have different items with different stats, this item system will work perfectly for you.

Do you know of a better way to design an inventory system? Shoot me an e-mail at buildingbrowsergames@gmail.com, or leave a message in the comments!

Edit: sepp has pointed out that the item.type column would be a perfect location to use what’s known as an enum. According to the MySQL documentation on enums, an enum is “a string object with a value chosen from a list of allowed values that are enumerated explicitly in the column specification at table creation time.” – which is perfect for what we need. Because we will only have so many item types within our game, using an enum will ensure that we can’t have situations where we make a typo and end up with an item with a type of ‘weapoh’ or anything. Here’s the table creation code, using a basic enum to set up 3 item types:

CREATE TABLE items (
	id int NOT NULL AUTO_INCREMENT,
	name text,
	type ENUM('Weapon','Armor','Usable'),
	PRIMARY KEY(id)
);

At any rate, pretty much every game has stats in it – otherwise, there’s no way of knowing how well you’re doing in comparison to anyone else!

Over the course of designing your game, you might figure out that you need 3 stats – attack, defence, and magic. And so you’ll set up the ‘users’ table in your database something like this:

CREATE TABLE users (
	id int NOT NULL AUTO_INCREMENT,
	username varchar(250),
	password varchar(50),
	attack int,
	defence int,
	magic int,
	PRIMARY KEY(id)
);

Which would be fine. You’d build your game, and the game would work as expected.

But what happens when, later on down the road, you want to add a new stat – like magic defence or something? With the design that you have now, you’ll need to first modify your users table, and then modify any code that interacts with the new stat – in addition to initializing the stat for all the players who already exist but don’t have the stat.

Does that sound like a bit of a pain to you? Because it does to me – and I’m here to show you a better way.

By moving our stats into their own table, we can create a table filled with available stats for players, without needing to worry about modifying any tables later on in our game – if we want to add a stat, we just add it to the table and our code, and we’re done – we could even build something in place to check to see if users have the stat already, and if they don’t it creates the entry for them. That sounds better than having to modify our database by hand, doesn’t it? Here’s how we could set up our initial stats table:

CREATE TABLE stats (
	id int NOT NULL AUTO_INCREMENT,
	display_name text,
	short_name varchar(10),
	PRIMARY KEY(id)
);

And this table will now store all of our stat definitions. If we wanted to add a stat called “Magic Defence” (and abbreviated as “mdef” for our code’s sake), we could run a query like this:

INSERT INTO stats(display_name,short_name) VALUES ('Magic Defence','mdef');

…At which point the new stat would exist in our system – and all we would need to do is modify our code to interact with it.

In order to store the stat values for a player, all we need to do is create another table:

CREATE TABLE user_stats (
	id int NOT NULL AUTO_INCREMENT,
	user_id int,
	stat_id int,
	value text,
	PRIMARY KEY(id)
);

At this point, we’ll have three tables – users, stats, and user_stats. The purpose of user_stats is to link particular users to particular stats – and store their values. user_stats.stat_id is the value of stats.id for a particular stat, and user_stats.user_id is the value from users.id. user_stats.value will store the actual value of our stat.

You might be wondering why the type of user_stats.value is text, as opposed to int or something – it’s so that we can have as flexible a stats system as we need. By storing the value as a text type, we’re able to store text or numbers inside our column – which means that if we wanted to have a stat like “Status” that had possible values of “Awake”,”Asleep”, or “Eating” – we could, in addition to having another stat called “Restedness” that simply contained a value between 1 and 100. By using the text type for our column, we’re able to store whatever we want – although this does mean that you need to be more careful about how you handle the values of your stats within your actual code.

Hopefully by taking a look at the database structure and these explanations, you can see why this system might be a better way to store player stats than by hard-coding them into your users table – although really, any approach will do. But if you’re looking for flexibility down the road, this approach will give you more of that than hard-coding values into your database. Flexibility is always a benefit if you ever plan on tweaking your game.

In many ways, the database is the core of your game – without it, your game is nothing. You could write all the logic you wanted to, but if you didn’t have a database that logic would be worthless(there’d be nothing to use it on!).

There are many ways to design a database, and some are better than others. For this entry, I’ll be walking you through how to design a database that has as little data replication as possible.

Why don’t you want data replication? Because all of the data you’ll be storing in your database adds up. Suppose you have 5 Kb of data that gets replicated needlessly for every single player of your game. Your game moves along just fine, and slowly grows – until it gets picked up by a site like Digg or Boing Boing – at which point you have thousands of registrations in a single day. Suddenly, your playerbase has gone from being manageable(1000) to huge! And this is what will happen when you have data replication:

1000 players x 5 Kb = 5000 Kb (Roughly 5Mb)
100000 players x 5 Kb = 500000 Kb (Roughly 500Mb!)

Sure, 5 Mb of extra data is managable. But is 500?

That’s why you need to design your database properly. The less data you have replicated accross your database, the less problems you’ll encounter later on. Reducing data replication also helps when it comes to updating things – instead of having to update data in multiple locations, you can just update it in one place – and know for certain that wherever the data is accessed, it will be up to date.

With that in mind, let’s start designing a basic table structure for a browsergame.

We’re going to need users. And users will need a username, a password, and a unique ID(so that we can link them to things). For now, that’s all we’ll give our users:

1
2
3
4
5
6

CREATE TABLE users (
	id int NOT NULL AUTO_INCREMENT,
	username varchar(250),
	password varchar(50),
	PRIMARY KEY(id)
);

If you run that pre under mysql, you’ll have a freshly created users table to play with. You might be wondering what the PRIMARY KEY line does – basically, it forces each row to have a unique value in that column. This will help ensure that we don’t ever have any conflicts like trying to create two different users with an id of ‘6′, for example. You can check out the Wikipedia article for more information about primary keys.

So now we have a users table. What else should our game have?

Most games have some sort of inventory that their players have, that they can use to store items in. Let’s set up tables for the items and the user inventories:

1
2
3
4
5
6
7
8
9
10
11
12
13

CREATE TABLE items (
	id int NOT NULL AUTO_INCREMENT,
	name varchar(200),
	description text,
	PRIMARY KEY(id)
);
CREATE TABLE user_inventory (
	id int NOT NULL AUTO_INCREMENT,
	item_id int,
	user_id int,
	quantity int,
	PRIMARY KEY(id)
);

And now we have all the tables in place to keep track of our users, and their respective inventories, with minimal data replication.

Suppose that, in our hypothetical game, the player picks up the Vorpal Sword of Hypothetical Existence. In order to add it to the player’s inventory, all we’d need to do is figure out what ID the Vorpal Sword had, and then add a new row(or update a row if they already had one of it) inside user_inventory.

The real benefit appears when it comes time to update something, however.

Let’s say that after your game’s userbase exploded, someone happened to find a bug: the Vorpal Sword, when used against a certain enemy, was way too powerful. You need to fix that, as fast as you can.

What do you do? Thanks to good database design, you only need to update it in one place! You can go into items, find the Vorpal Sword’s unique ID, and then update whatever attribute is causing the problem. You could even rename it, to the Nerfed Sword of Hypothetical Existence or something.

Because the important data for each item in the database is only stored in one central area, it’s easy to update it. But could you imagine what it would be like if you wanted to change the Vorpal Sword’s name, and it was stored inside user_inventory? For every single user who had one, you would need to change the name.

In the previous scenario, which would you prefer? Having to update rows upon rows of data, or just one? I know I would prefer to only update one, and I hope this has helped to communicate what you stand to gain by designing your database in such a way so that you only ever need to update one row.