What Went Right

A few decisions that I made early on helped to get Rawrmy “on it’s feet”, for all that there were some setbacks during development. One of those decisions was to use Django, a popular Python web framework, to develop all of Rawrmy’s functionality. Django is geared towards rapid development in the same way that Rails is; both frameworks lend themselves very well to getting something out the door as quickly as possible – which was one of the goals for this contest due to the compressed time frame. Straight out of the box, Django gives you a pre-wired authentication system and admin backend – both of which were immensely valuable during initial development.

Another decision that helped ease the development process was a bit of a harder one to enforce: every feature implemented was droppable. What that means is, for any feature I was developing, I’d set a timer. If it took me longer than an hour or two, the feature got dropped – although I marked it as “come back to later”. Doing this allowed me to trim the fat out of Rawrmy, and focus only on the pieces that would get it to being a finished game the fastest.

What Went Wrong

Time was a massive factor that prevented me from completing Rawrmy. In hindsight, I probably should have taken some time off from my day job, or diverted time from some of my other projects – Rawrmy is unfinished because I was unable to devote as much time as I would have liked to to developing it.

Some things took too long. While I mentioned earlier that every feature was droppable, it was only after I had sunk a few precious hours into a specific(and still broken) feature that I realized I would need to enact this rule. If I had realized how much time I was sinking into non-valuable features at the time as opposed to afterwards, I probably would have had a lot more time to spend on getting the game working(and less time spent chasing down random bugs).

Lack of direction was a problem with Rawrmy. I have to admit that when I first decided I should enter the contest, I didn’t have any idea what I would build a game based on – and I believe this was one of my biggest problems. John Munsch had clearly been planning out his idea for ‘Big Villain’ for quite some time, and was therefore only waiting to do the development on his game. Multiple other entrants were also in the same position; the fact that they had already planned out most of their game gave them a massive advantage, because they could get started developing while I was still attempting to come up with a concept for Rawrmy.

When I initially entered the contest, I also had a team member who would be creating all of the written content for the game. However, after a week or so, my partner disappeared – and I still have yet to hear from him. This was another setback; the initial idea for Rawrmy was heavily text-based, and while I’m sure that I could have written the content myself, it would have distracted me from getting the game running and polished.

What I Learned

When you’re entering a contest with a short timeframe, you need to have a firm idea of what you’re going to build – it doesn’t neccessarily have to be large, but you need to have that idea and stick to it. Changing gears in the middle of a project will kill it – Rawrmy lost a good week or so’s worth of development time when my partner disappeared.

When you enter a contest like this, you need to be prepared to make the commitment. You need to be willing to commit development, monetary, and any other resources neccessary to get your game done – and while I was able to half-commit on most of those things, it’s not enough. The next time I enter a browsergame contest, I’ll make sure that I’ve got my other projects cleared out of the way for the duration, and can therefore focus only on the contest – instead of getting distracted by other things.

All told, I had a positive experience entering the contest – even if I had to drop out at the end. I learned a lot about my own development practices, and what I can do to improve in the future – which is enough of a win for me.

If you’re interested in seeing what Rawrmy was like, you can check it out at rawrmy.com.

While the time allotted for the contest was more than adequate, too many distractions came up that prevented me from spending enough time on Rawrmy to make it a serious contender for the contest at all. While I am still hoping to polish and deploy Rawrmy for the 11th, it will no longer be as a serious contender in the contest; merely as a prototype.

In addition to deploying Rawrmy on thursday, I will also be posting a post-mortem of the development process – detailing what worked, what didn’t, and what I would have changed.

With that in mind, I have been working to build something like a quests system into Rawrmy – essentially, there is a large over-arching storyline with the player is part of(sort of like Kingdom of Loathing, although nowhere near as developered). Unfortunately, it turns out that designing a flexible quests system is a lot of work – and as a result, while there are quests in place, I have had to build them in a much more rigid form than I would have liked to. Essentially, I have created an enum of the different steps in the story, and I am storing which step of the story the player is on in my User Profile model:

class STORY:
	STARTING,FRIDGE,TOASTER,OVEN,BATHROOM = range(5)

	story_step       = models.IntegerField(max_length=25,default=STORY.STARTING)

Checking which step of the story the player is on is then done by our view:

if profile.story_step == STORY.STARTING:
	profile.story_step += 1
	profile.save()
	return area_template(request,'couch','starting.html')

While this works, it’s not quite what I like – but the deadline for the contest is looming, and I will not have time to rewrite how the quests system works.

At any rate, progress is slowly being made – while I have had to strip out a lot of the features I would have liked to have, I should at least have the beginnings of the game playable by the deadline.

One of the things that I struggled with this week was the limitations of Django’s queryset API – while it’s both powerful and flexible, there are a few things that it cannot do. This problem reared it’s head when I was working on the crafting system.

When a player goes to craft an item, they are presented with a multi-select that will display all of the craftable items in their inventory. They then select which items they would like to craft with, and we retrieve anything that they can make out of them.

The problem, here, is that ‘ingredients’ on our craftables is a ManyToManyField – and I wanted to retrieve an exact match. For example, if a player had tried to craft with ‘flour’ and ‘yeast’, any craftable with ‘flour’ or ‘yeast’ and not ’sugar’ would be returned. Retrieving the ‘flour’ and ‘yeast’ craftables was easy, using an __in query:

	craftables = Craftables.objects.filter(ingredients__in=form.cleaned_data['ingredients])

However, making sure that the ’sugar’ craftables were not retrieved was slightly more difficult(and took me a while to figure out). Essentially, the process involves first creating a list of ingredients that are not in the group of selected ingredients, and then excluding any craftable with ingredients in that list(after we filtered). The new code looked something like this:

	bad_ids = [ingredient.id for ingredient in form.cleaned_data['ingredients']]
	craftable = Craftable.objects.filter(ingredients__in=form.cleaned_data['ingredients']).exclude(ingredients__in=Item.objects.exclude(id__in=bad_ids))

Unfortunately, that only seemed to work in some cases – and as a result, I’ve been debugging and rebugging the same piece of code for most of the week.

This slowdown is unfortunate – but I think that, moving forward, the crafting system is going to get replaced with a simpler two dropdown system and learnable recipes.

Completed this week:

• Laid the groundwork for crafting and the escort system.

Still to do:

• Fix the bugs in crafting item retrieval – they’re a gamebreaker right now.

The typical inventory system is fairly simple: you have the player who owns the item, the item itself, and (perhaps) the quantity of the item.

One of the nicer features of Django that building the inventory system has introduced me to is reverse relations; they make it very easy for me to add new items to the user’s inventory. I am storing their inventory in my UserProfile model, and using a ManyToManyField for keeping track of the user’s items(with an intermediary ‘through’ model for keeping track of the quantity of the item), and that means that I can add items to the player’s inventory with a single line of code:

profile.inventoryitem_set.create(item=item,owner=profile)

With item being the item I want to add, and owner being the profile I am adding the item for.

One question that came up while building my inventory system was “Should items be stackable?” – because it makes sense for things like weapons not to stack, but things like usables to stack. In the end, I decided to add a stackable BooleanField to all of my items, and then just check it in my InventoryItem’s save() method, like so:

def save(self,*args,**kwargs):
	if self.item.stackable and kwargs.get('force_insert',False):
		self = InventoryItem.objects.get_or_create(item=self.item,owner=self.owner)[0]
		self.quantity += 1
		kwargs['force_insert'] = False
	super(InventoryItem, self).save(*args,**kwargs)

Is this the best way to do it? Probably not. But it lets me have items that do stack and items that don’t stack fairly easily, in addition to being able to add items to the player’s inventory without having to write a lot of boilerplate code.

Overall, progress is being made – while I’m not sure I will be able to finish as much as I would have liked to by the time that the contest is over (December 11th), I’m fairly confident that I will have a codebase completed that I am happy to work on far into the future.

Completed this week:

• Basic combat system – needs some tweaking but currently workable
• Inventory management – add items, remove items

Still to do:

• Create more content and quests – while there are plans in place for upwards of 5 areas at the start of the game, there have only been quests for 2 of them designed so far.
• Write better storyline content – right now it just says things like “the storyteller tells you to go over there. So you decide to do that.”
• Lots of polishing and re-working – while most of the internals of the game work and are playable right now, they don’t feel “just right” yet.

I have decided to build Rawrmy with Django – which is an MVC framework like Ruby on Rails(except in Python instead of Ruby).

Django has a vast number of freely available libraries for common functions, in addition to coming with some handy features bundled – like an auto-generating admin interface, and authentication systems that are pre-built for you(and will work for 90% of the things you’d need it for).

With that said, all of Rawrmy’s initial systems are built – login, registration, and profiles – mostly by taking advantage of the excellent django-registration library.

One of the stumbling blocks that I’ve encountered while working on Rawrmy is flexibility – while I’d like to make my systems as flexible as possible for the sake of future content, I am rapidly finding that there is a certain point where you need to trade flexibility for just writing the code. This is becoming most evident with the area exploration system – areas are currently a model in my database, and their code looks like this:

class Area(models.Model):
	title = models.CharField(max_length=500)
	slug = models.SlugField(blank=True)
	monsters = models.ManyToManyField('Monster',null=True,blank=True)
 
	def save(self,*args,**kwargs):
		if not self.slug:
			self.slug = slugify(self.title)
		super(Area,self).save(*args,**kwargs)
 
	def __unicode__(self):
		return self.title

Originally, my URLS looked like this:

url(r'explore/(?P<area_slug>.+)/$',views.explore,name='explore-area'),

I had planned to retrieve the area the user was exploring based on the slug, and then use that to figure out what happened when they explored that area. However, I quickly came up against issues with the flexibility of this approach – while it makes it easy to add more areas and allow users to explore them, it makes it very difficult for me as the developer to add custom behavior to an area. If I want to add custom logic to the Forest area but not the Mountain area, how am I supposed to do that using the current configuration?

With that in mind, my urlpatterns have changed, and I now hard-code the area slug, and map it to a specific view:

url(r'explore/forest/$',views.explore_forest,name='explore-forest'),

This way is a little less flexible in terms of being able to deploy new areas instantly, but it allows me to write any custom logic I need – which is what I was looking for.

Completed this week:

• User management – login, logout, register
• Escort management – choose escort
• Class Choice – choose class

Still to do:

• Exploring – needs a lot of fleshing out
• Storyline – needs to be better (writer disappeared)
• Hook – what makes this game fun?

As you’ve probably guessed by now, work on Working Title has sort of fallen by the wayside. Life got busy, and I couldn’t devote as much time to the project as I would have liked to for a while. Having said that, Working Title has been shelved for now – when I’m a little less busy, I will probably come back to it – but for now, it is shelved.

One thing not all of you know, however, is that I will be entering the PBBG contest as well. The game that I will be working on has been tentatively called ‘Rawrmy’(although we’re working on a better name). It will be a mostly-singleplayer RPG, with a heavy focus on a quest-based storyline.

There isn’t really much more to say about it right now – but check back every monday for posts on Rawrmy’s progress!

I always like to prototype my projects before I start them – I start with the template, and then start building quick mockups of functionality I plan to have. Usually, the code that I used to build my prototype can be cleaned up and used to build whatever I’m building anyways, so I’m still writing code towards my goal – with the benefit of having something to show for it a little faster.

With that in mind, I set out to build a simple tester page that shows off some of the Javascript that will be behind Working Title’s ‘play’ page – while it doesn’t do any posting back, it demonstrates what the functionality is supposed to look and feel like(albeit a little faster than it would be in the actual game). Here’s the Working Title test page, which will let you see how I’m planning on having the game behave.

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.

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.