Preparing our items system

If you’ve been keeping track of our design document from earlier at all, you may have noticed that we are starting to come close to finishing our game. There are still a few features left to refine and tweak, and a few more left to implement – but we’re getting closer. Today, we’ll be laying the groundwork for our items and inventory system – and on monday, we’ll dig into actually implementing it.

Because we want to be able to perform whatever actions we want on a player, we’re going to need a way to flag our items – to say “this is a healing potion”, “this item teleports the user”, and so on. To that end, we’ll add another stat to our stats table:

INSERT INTO stats(display_name,short_name) VALUES ('Item Use Token','token');

We will be using the value of the ‘token’ stat on our items to determine what exactly we should be doing with our items when we use them.

We will also need to add another table to our database – to keep track of the items in the player’s inventory. We’ll create user_items like so:

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

And with that finished, we’re all set! All we’ve got to do is write the code, now – which we’ll do on monday. See you then!

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.

Tags: , ,

Friday, October 10th, 2008 buildingbrowsergames, medieval
  • Devin

    Hi Luke, I'm really enjoying this tutorial! However, I have a question about the "user_items" table here. It seems like this is the same table as the "user_inventory" mentioned on the "Designing your game's database" page. Are they the same? Thanks .

  • It looks like they might be! I guess that's a typo.

  • spatlabor

    It worries me a bit that the user_items table can become very big especially if the user can poses lots of different items (skills, ships, planets, etc).
    I wondered what you think about an approach that does the following. If you consider a fleet that are composed of multiple types of ships you create a table fleet with a tinytext field that stores [ship_type:nb:ship_type:nb:ship_type:nb: etc]. The same could be done for players skills [skill_type:value:skill_type:value:etc].
    Of course this would mean more processing but would decrease the number of entries in the database significantly.

    My question could be: what is the most cpu efficient? Big database with lot of search/insertion or more php parsing?
    Thanks

  • The best way to do this would actually be to create unique tables(and
    columns) for all of your different inventories; the reason that we did it
    differently in the tutorial was so that we could quickly expand on our items
    and add new item types as we needed to.

  • i still dont understand why did you do such a "special" item case... the tables would go easier with item(id , name , atk, def , etc...) | invetory wich gets items id from items database and battle wich also gets items id... and the system would be the same you change something in items table and it would change every where...

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

Beathound

Got Something to Say?

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