Registration Form

When users first look at your game, something has to entice them – and the experience between that initial enticement and actually playing the game is what makes them sign up and play your game, instead of leaving for some other game/site.

A big part of the initial experience here is the registration form – and for most users, registering for your game is one of the last steps before they actually start playing your game – which means it’s one area where you should not be losing any prospective players.

However, no one wants to fill out a survey just so that they can try out a game – they’re registering for a game, not applying for a mortgage! Asking users for more information than is absolutely necessary in order to sign up for your game is a pointless way to increase the barrier of entry for your game, in addition to turning away anyone who feels that they should not have to give you any of their identifying information to sign up to play your game.

A lot of browsergame developers that I have talked to defend this data harvesting as being invaluable for advertisers – because by having more detailed demographic information on your users, you can attract advertiers who are looking to advertise to the demographic that is visiting your site. However, this is a shortsighted stance to take: if your users feel uneasy or frustrated by the amount of information that you require from them, it is easy enough for them to leave. And if they leave, you won’t have any demographic for advertisers – or players.

At the end of the day, I didn’t sign up for the game – and if you’re building a game that requires more information than username, password, e-mail – I won’t sign up for yours, either.

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.