I’ve been struggling for the last few weeks to try and find a way to make combat ‘fun’ – while it’s a big part of a lot of browsergames, it’s a part that (I think) could use a little bit more polish in most of them. Fighting monster after monster after monster isn’t fun – it’s only a means to an end. I think that even the boring parts of the game should still be fun. With that in mind, I set out to build a combat system that would achieve two things:

1. Be a combat system.
2. Be fun.

After thinking and pondering, I believe that I’ve finally come up with a system that works(and you’ll probably be able to figure out how it works in the screenshot below).

Rawrmy's refreshed combat system

A little bit more time was also spent fleshing out the different areas of the game – and they’re what I will be working on now. I am afraid that my schedule has been getting busier and busier, lately – which means I can’t devote as much time to Rawrmy as I would like to. While I am still hoping to have something releasable by the contest due date, I don’t think it will be quite as strong an entry as I would have liked.

Completed this week:

• Combat system refresh – the combat system is now a little more fun to use, in addition to more challenging for players who have gotten to the higher experience levels.

Still to do:

• Content needs fleshing out – while this combat switch has made Rawrmy ‘feature complete’, it hasn’t made it solid yet. There needs to be a lot of polishing done in regards to content, areas, and the way that in-game items work.

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?