Building Browsergames

Diary of a Browsergame: Planning out the templates

Now that I’ve set up my database, it’s time to settle on a templating system, and decide on how I want my templates to work.

Working Title only has a few pages that will need to be displayed - according to Design 1.0, there are a total of 7 - Home, Design Document, Register, Login, Logout, Codex, and Play. This will make developing the templates very easy, as there are only a few that I need to build.

I’m going to use HTML::Template for my templating system, just like we have been in our Perl-based browsergame tutorial. However, my templating setup will be slightly different; I am planning on nesting two templates within each other. I’ll have a simple outer template which defines some of the global styles for all of the pages, and then another inner template that is populated with the information unique to the page(this is an example of applying DRY to my templates).

To that end, I’ve whipped up a quick outer template for Working Title, that will(for the moment) do what I need it to. There isn’t much to it, but you can take a look at it here.

Is it a rough template? Yes. Will it change before Working title is done? Probably. But it’s enough to get me up and running, and free up my time to work on developing the rest of the game, instead of just working on the template.

Diary of a Browsergame: Setting up the database

One of the first things I do for any new project of mine is design the database - so that’s what’s going to happen to Working Title today. This design will probably change slowly over the course of development - it’s just a good starting point for now.

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.

Diary of a Browsergame: Design 1.0

It’s been a while since I’ve mentioned Working Title - life seems to always get busy right when you start something. But I’ve slowly managed to compile Working Title’s design document to a state that I can comfortably call ‘1.0′.

Is it complete? Not really. Does it at least have the bare minimum for what I want to have in version 1.0? Yes. What that means is that I can skip forward to implementation - using that design document, I’ve got the basics of the game sketched out, and everything that I’ll need to build.

Working Title’s design document is a little bit fluid right now - while it’s version 1.0, there may or may not be a couple of minor features added, or a little bit more descriptive content. If anything else does get added, you’ll be able to see it by visiting http://buildingbrowsergames.com/workingtitle/design/list.html, where I’ll be listing all of Working Title’s design documents, named according to their version(right now, there’s only version 1.0 in there).

With that being said, development on Working Title can now begin - so hopefully soon I’ll have a little more to show off. Because Working Title is going to be a stab at making a real game and not simply a tutorial, I won’t be releasing all of the code for it - just little bits and pieces that I personally find interesting. Any code from Working Title that is released is released into the public domain, and you are free to use it - but I won’t be holding your hand and walking you through it, chances are. You’ll be on your own.

So go check out the design document, and take a peek at what Working Title is going to be!

Diary of a Browsergame: The Codex

Work is well under way on writing up the Design Document for Working Title, version 1.0. And while there have been a lot of neat ideas and a few not-so-neat ideas, I’m happy to say that I think it’s coming along - albeit slowly.

One of the first implementation choices that I’ve made(I haven’t written any code yet!) is to build Working Title using the Object-Oriented paradigm. That means that each of my players, monsters, and items will be an object, and completely self-contained.

One of the nice things about building all of my objects using the Object Oriented approach is that I can use inheritance to take care of some of the dirty work for me. One function that I will be implementing will exist on each object, and be known simply as toHTML() - all it will do is convert the object into some nice HTML output.

That HTML output is important, because it’s what will be getting used for a feature that I think is pretty neat: The Codex.

Working Title will have an area called “The Codex” that contains readable data on each entity within the game(except players). In order to output the HTML to display a specific entity, I’ll just load that entity and then call toHTML() on it to get at what I need to display to the user.

The Codex idea also brings me to a cool tooltip library I discovered a short time ago, called BoxOver. I’m planning on using it within the actual game itself, so that I can have tooltips everywhere with a minimal amount of extra cruft added to my code - at only 12KB uncompressed, the JavaScript file for BoxOver is nice and lean. And I’m sure I’ll compress it more before it actually gets deployed.

That’s just two of the implementation details for Working Title - there are a few more I’ve got up my sleeve that will either show up on this blog, or within the design document - but either way, you’ll get to see them when they show up.

Diary of a Browsergame: Working Title

I’ve been tossing around an idea for a browsergame lately, that I don’t think has been done before. It’s basically a MUD, with the exception that it’s inside of your browser and doesn’t involve any extra downloads(or telnet).

The game is based around exploring - you, as a user, are exploring an area. I’m not entirely sure what the area will be yet - whether it’s a dungeon, or a forest, or a town. But I do know that I want to have items, spells, buffs, monsters, and shopkeepers.

I’ve been sketching out a lot of the ideas for this game - building the design document that I mentioned earlier. Once that’s finished, I’m going to start building the game.

When it comes to languages, I’ve decided that I will be using Perl. I’ll be using the CGI module for web interactivity, and DBI for database access. I’m also going to use HTML::Template for my templating needs.

Over the course of development, I’ll keep writing these “Diary of a Browsergame” posts - to try and give you an insight into the process that I personally follow when building something, along with letting you take a look at some code samples and what the finished project turns out like. If you’re thinking of building your own game, why not use my approach as an example to help you get started?

Remember, however, that my personal approach might not be the best approach for you in particular. It’s important that you find the approach that works best for you, and use that - instead of blindly following someone else’s. So if there’s anything I do that doesn’t make sense to you or you think to yourself “it would be better this way” - do it that way for your game! Your approach doesn’t really matter, as long as you’ve got something to show for it.

Anyways, that’s the plan thus far. So far, all I’ve done is choose a language - the next thing on the list is finishing up the design document, and designing the database.