Rawrmy Starts

This week was spent getting started on Rawrmy – building the initial systems, and planning out how the game will play out.

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)
	def __unicode__(self):
		return self.title

Originally, my URLS looked like this:


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:


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?

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: , , , , ,

Monday, October 27th, 2008 diaryofabrowsergame
blog comments powered by Disqus


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.


Got Something to Say?

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