Preparing our database for multiple area support

While we’ve been building our game, we’ve been slowly adding features – piece by piece. As these features have been added, our game has sort of grown organically – but some of these features are(at least at the moment) a little half-baked.

Today, we will be altering our database by adding a few of the prerequisites for our combat system to be a little fuller – instead of players visiting the forest to encounter enemies, they will be able to visit any number of areas that we can define in the database. We will start by adding an areas table to our database, that we can use to keep track of information related to each area the player can visit:

CREATE TABLE areas(
	id int NOT NULL AUTO_INCREMENT,
	name varchar(100),
	PRIMARY KEY(id)
);

In theory, this table is all that we need to add to enable multi-area support(after changing our combat code, of course) – but we will also add a table called area_monsters that will allow us to control which monsters can be encountered in which area:

CREATE TABLE area_monsters(
	id int NOT NULL AUTO_INCREMENT,
	area int,
	monster int,
	PRIMARY KEY(id)
);

With this table created, we will be able to insert rows for monster + area combinations – allowing us to control which types of monsters the player will encounter in each area.

If you’re aware of our current database structure, you might be wondering: why didn’t we just add another stat to each of our monsters, called something like “Area Monster Is In”? The reason for that is simple: with these new tables, we will be able to retrieve which monsters are in an area using a single SQL query, that would look something like this:

SELECT monster FROM area_monsters WHERE area = <area_id>

If we were to use our stats system for this, we would need to do something much more complex – first determining which stat we should be retrieving, and then retrieving the relevant rows for every entry in the database – at which point we would need to work through our rows and determine which values we actually needed to use. Therefore, adding our area_monsters table will allow us to keep track of which monsters are in which areas a little easier.

With that being said, all of our initial preparations are finished – our next step(which will come later) is to add the code to actually interact with the tables that we have added to our database.

Wish there was more?

I'm considering writing an ebook - click here.

.

Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Monday, January 12th, 2009 code
blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames