(Programming a spybot with it’s behaviour)

Eventually the plan is to be able to program the bots fully within the game client – this is still a long term goal, but there are of course some fairly complex security problems with this idea.

(dressing a AudienceBot with another object)

Not all players have the ability to use these secret commands right now, in order to access them a player has to be carrying a special object (also known as a “Golden Medallion”). This allows you access to all areas of the game, including an “administration room” and various other secret powers.

“Good news everyone!”

We have reached the point where we can start having some players test and try break things with the current pre-alpha-thingy-candidate version of the game. We are looking for just a couple of testers who can cope with the fact that they will get early spoilers and experience a not entirely finished game narrative and interface. On the other hand you will greatly help us stabilize things, spot a few more bugs and make final improvements!

Take into account that you will have to use an issue tracker to report us problems (ie, using a website with a form to check for existing known problems and report new ones) and that we will ask you some questions after you played.

Use the contact form in this blog to get in touch with us :)

Monday October 11, the first day at BALTAN Laboratories in Eindhoven! We walked to the SWA building, through Phillips Complex S, and at the 8th floor gasped at the enormous space of the lab. After a grand tour by director Angela Plohman, we set up and started to write down the master plan for this week. Lots of decisions to make, especially after the playtests we’ve held. The feedback we received made sure we zoomed in on the parts that needed the most attention first.

First task was to make the interface more user friendly. Most playtesters were too busy trying to figure out what to type and how to type it, instead of discovering the game world. We decided to simplify the vocabulary, write more elaborate help texts in case of an error, and write a general “help” that gives an overview of the vocabulary, what each word does, tips to speed up navigation through the world and all this with clear examples.

Second big change is the layout of the page. In the old layout the input form was at the bottom, with the story being written above it and on the right a feed of messages from the game. The new layout is meant to look and function more like Facebook and Twitter, with the input form at the top, the story below, on the left a feed of messages directed at you, and on the right a feed of general messages. To match the social networks more closely, the story is now in first person perspective, and everything you type is a message. This way you can follow what other players are doing, get curious about how they found that pony or managed to enter a fishtank, all the while enjoying the fine feeling of transparency.

We also needed to think of ways to be more “in your face” with our narrative. Hints and tips were missed too easily. We will change the texts and use the Facebook data we have at our disposal in more elaborate ways. And hints a player needs to progress will be more obvious. We need to find a balance here.

Well, that provided us with enough work for two days. Wednesday we’ll do another playtest with game design students and researchers from TU Eindhoven. We hope to be ready for another round of feedback by then, so we can go through a second iteration of improvements on Thursday and Friday.

Oh and tonight at 19.30 we present Naked on Pluto at NIMk, during the Space Invaders event there!

Being careful to not give too much away, one of the things I’m looking forward to is a gradual opening up of the game as you progress. It moves from quite a fixed path, and opens up into problems with less rigidly defined solutions. The playtesting will be essential to get a real idea of how well it actually works, and allow us to fine tune/radically change sections.

At 16.00 we presented Naked on Pluto to the crew of NIMk and we were very happy Angela Plohman from BALTAN Laboratories came to join us (we’ll be at BALTAN in October for the next sprint). We discussed the project in its current state, and talked about the steps in development we’ve taken so far, the biggest problems we’ve encountered and the next steps. Explaining these things at this stage of the project was quite a test for us. We’ve been submerged in the game’s logic for 3 days now, and we’re starting to loose our sense of reality ever so slightly…

A locking conundrum.

This sort of play requires a way for players to coordinate with each other, for example using a realtime chat system. A minor crisis involving the details of how to handle this feature was narrowly averted and we escaped to the shores of Ljsselmeer to begin considering the vertical slice, the moustache as core game feature, community service and mandatory fanny packs.

It’s an inventory of all our reasons for wanting to make this game and an attempt of integrating them into the game design in a meaningful way. We made lots of progress on the world and non-player character design. Tomorrow we continue with the design of a vertical slice and we’ll break our heads over some scalability problems.

Love-bot: Talk to me honey
User: hi
Love-bot: Bonjour mon amour, my passion
User: hello
Love-bot: Good day my sweetest, I’ve been looking forward to meeting you for so long.
User: me too
Love-bot: Have we met before?
User: no we haven’t
Love-bot: That makes me sad. Won’t you please reconsider?
User: well I can’t rewrite history
Love-bot: Well How do you know you can’t rewrite history?
User: because it already happened
Love-bot: If it already happened, what else must be true?
User: tons of stuff
Love-bot: Have you got a light?
User: no
Love-bot: That makes me sad. Won’t you please reconsider?
User: i really don’t have a light
Love-bot: Perhaps we could go somewhere more private?

User centred design

This one I was taught at a design workshop by Ylva Fernaeus, Sara Ljungblad and Mattias Jacobsson from SICS, but I recognise it from elsewhere, and it was good to have it explained in full.

One part of ‘UCD’ (as I’m sure it’s abbreviated to to confuse the initiates) is called user stories. You make up a fictitious person who might play your game, and describe who they are, why they are playing and what their motivations are etc – you can get quite carried away with this, and within sensible margins, it seems to help.

Then you describe the experience of the game from their point of view. This means you can leave out all the details and focus on what you want them to feel – from the inside.

You do this for a handful of people with different backgrounds. It obviously helps if you have a little bit of experience with the sort of people you are imagining the reactions of. We’ve been using our family members as inspiration, which makes it a bit easier.

The result of doing this is thinking about the players rather than the game, and while it sounds simple, forcing you to think like this can reveal some surprises.

Vertical Slice

This one sounds terribly technical, and I picked it up at Sony. It comes a little later, once you have a clear-ish design and you start to write the code. The idea is that you implement only enough to have a single full experience of your game. For instance, if you can choose between a variety of characters – in the vertical slice you only implement one, and implement it fully. When it’s finished, the vertical slice should show you one possible path through the game, but no more.

This is generally used to persuade publishers that their money is safe, and that the game is a winner with the minimum of development expense required.

However, I think it can also fit with the user stories, if you take one of your fictitious players (perhaps the one who represents the strongest demographic you are interested in) and implement the vertical slice as if you were making it for them, you are forced to face some of the most important decisions first.

Then, and this is really the key thing – you can deal with these decisions while the game is still malleable, both in terms of code, and in terms of your understanding of it in your head, and you are in a much better position to come up with the solutions needed.

While privacy and facebook has been a hot topic of debate recently, I’m unclear how much as been discussed about the rights given to facebook applications when you agree to give them access to your data. Depending on your settings, it can use your session id to do anything you can do – access your friend’s data or post on your wall (as most games like to do for advertising).

From my initial reading, the facebook privacy policy is fairly clear and well written concerning your responsibilities as an application developer. Firstly there is a distinction based on where the data comes from:

Data given to your application by the user

Any data entered into your application directly can be stored and used by you in any way. This seems sensible, as it should be covered by your own privacy policy with your users – it’s nothing to do with facebook according to the Understanding User Data and Privacy rules:

Because you have collected this data independently, you may use this data however you see fit. For example, you may transfer independent data, along with the associated Facebook User ID to any of your trusted partners. You may not include any information accessed from the Facebook API in this transfer however.

Note “your trusted partners” part – the assumption is that most social networking apps will be funded at least in part by marketing dollars. Not this one, in case you were curious.

Data from the facebook API

There seem to be 3 levels of privacy concerning your data accessed through the facebook API, the policy talks about “using data from any other purpose than displaying it back to the user”, which I take to mean sending it to other users, “trusted partners” or anyone else other than you, this is from the developer policy documentation:

Users give you their basic account information when they connect with your application. For all other data, you must obtain explicit consent from the user who provided the data to us before using it for any purpose other than displaying it back to the user on your application. A user’s friends’ data can only be used in the context of the user’s experience on your application.

Basic account information means your name and graph ID number, depending on your privacy settings and how much info you gave it of course. This is my basic info, direct from the facebook graph API: https://graph.facebook.com/100000480510823

The rest of your information (such as your friends list) can only be used with your permission – and there is quite a lot of effort made in preventing apps tricking users into giving permission, with misleading buttons or making it a requirement it in some way for a game or an application.

Your friend’s information is regarded as completely private – apps can access it and show it back to you in any way, but not give it to anyone else – even with your permission.

I’m used to these sorts of rules when working on console games there are similarly strict guidelines, but the crucial difference with facebook (and presumably other social networks) is that I am unclear as to whether anyone is actually responsible for auditing applications other than the people developing them.