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.

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.

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!