My first approach was to write a scheme bricks representation for Javascript objects, and see how bits of the game looked if rendered in this way.

This is part of the ArrivalLobby, and all the internal information is present with no explanations, which is great, but it results in very large images. The next thing was to try filtering the objects to remove most of this information:

function node_filter()
{
    this.filter=function(obj)
    {
        return {objects:obj.objects.map(function(object) {
            return object.name;
        })};
    }
}

This code provides a single method for filtering locations in the game – it simply returns an object consisting of a list of names of things found at that location. These filters can be easily changed over time, to include different information or process it in different ways. Rendered with the same code as before, this makes the location diagrams much smaller:

Add a few more locations, put them together in a circular formation (the projection will be onto the floor space in the gallery), add some bezier curves to indicate paths between locations and it looks like this:

There is also some relatively complex jiggery-pokery to detect when bots have moved from one location to another and animate them. The moving bots display more detail including what they are wearing and who has ‘liked’ them. In this image you can see the AdverBot004 moving to the HelpDesk, and the HyperClock and GreenwichClock on the upper right as they move from the Palace Garden.

“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 :)

Today was a crucial and quite scary step for the project: playtesting.

Indeed, so far we’ve been happily working and testing the game on our own. We did that not because it was a secret process – after all anyone can check out and run the source code since day one – but because it would not have made much sense to get feedback on something that was actively developed, thus changing directions very often.

The downside of not sharing the progress, is that eventually you end up being so much immersed in your creative process and imaginary world – in that case, Pluto – that you have no way to remain objective or even properly test the game yourself.

For example, after making one of the quests hundreds of time, to look for bugs or test some new feature, the user interface and the narrative disappear completely from your experience. It becomes an automated procedure and certainly not a playful moment.

On top of that, each of us started to be obsessed about particular features or details that are not necessarily useful or important for the project. But it is important to be able to “kill your darlings” before they slow down the development of the project or get you entirely side tracked.

All of this make the playtesting a necessary, yet scary, mandatory process to move on and remind you what were the reasons that pushed you to make this game.

Last week we reached the point where most of the essential game mechanics and interface features were in place, in an unstable and clumsy way of course, but at least we knew that we were heading towards a stage where the game was playable and more or less coherent. This is why today at Baltan Laboratories we hosted a play testing session of NOP with game design students and researchers from TU Eindhoven.

For such an occasion, it’s really important to leave your ego behind and be ready to face, most of the time, painfully honest comments. In that regard we had a fair amount of these and it was a really good thing. A bit painful at times though… ahem.

What we did was to let the testers play the game for 15 minutes, and ask them afterward a few questions. More specifically:

1. interface (readability, flow of the game (action-response sequences), user input, commands)

2. narrative (story, non-player characters, multi-player aspect, game world, message communicated)

3. playability (difficulties encountered and suggestions to improve)

4. fun (did you enjoy the game? why?)

5. link to entire project (Is the game clearly linked to the research aspect of the entire project?)

The response we got was very good and helpful. I will not give much details, but overall most of the advices and critic we got were known issues or things we noticed were wrong but for which we were not entirely sure how to deal with them. Regarding the game itself, some players managed to progress very fast, others struggled and it was interesting in each case to know why it worked or why it did not.

Of course it can be frustrating to get feedback on things that you already know are broken because of lack of time or just because it is not high priority at the moment. Never the less it is important to get over this frustration and let the players tell us whatever come to their mind as it is an invaluable source of information, specially if your testers are themselves working in the field of game design. We greatly appreciate the time they took to visit us and give feedback on the project.

At the end of the session we had a long list of things to fix, things to change or improve and things to add or remove. Very long list. The good news is that most of these should not be too difficult to implement and hopefully can be done, for most of them, before the end of the week (says the narrator in a hopeful way).

Once this is done, we will be ready to invite remote beta testers – from the internets – and it will be the second major step to take in order to make sure we’re on track.

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!

Back in the 70s, early computer games were de facto text-based due to the obvious lack of graphical environment, yet they still survived through several generations of action packed arcade style games. This popularity can be explained partly because many of us are still using terminals to interface with our machines – maintaining and building upon a long and healthy tradition of command-line celebration – but mostly because text remains a very engaging way to build a narrative. Here, your imagination is used instead of a Graphic Processor Unit, in order to construct a particular atmosphere, extrapolating from the couple of words displayed on your screen (shocking concept and heresy I hear some say).

A particular advantage often mentioned for text-only environment is the little time needed to develop these, which is true as long as you keep the game engine rather simple. For example, many popular point and click web based games that are popular on Facebook and other online platforms are not necessarily complex, but heavily relies on addictive tricks and cute graphics. At the opposite there are many online multi-player text based games and interactive fictions that sit on top of rich engines, despites their lack of adorable color saturated farm animals sprites. In Naked on Pluto, we already have quite a few bots that are now inhabiting, processing and wandering in the server. But without 2D/3D graphics – in the most common interpretation – to represents and interact with these entities, we must find a way to transcribe this activity the best we can only using a Text User Interface.

In most text adventure games, also known as interactive fictions, the interface relies usually on two components: an input form where the player can type in some commands or possibly choose answers/actions from a quiz/list, and a feedback text area used to describe the result of the commands entered.

In Naked on Pluto, we rely on similar system but the difficulty for us is that we need to deal with much more data. For example each player has an inventory, an evolving list of possible actions and an overview of the space she/he is currently located, and who is around doing what. On top of that other players and bots are following their own plans that have an influence on your player’s status or on what can be available at a given place. All this data can be turned into text and displayed as some practical text-based interface, but we set ourselves the challenge to design the web application as if it was a book page. This choice is not gratuitous but I’m not going to spoil anything. In a classic text adventure interface all these elements are accessible via various commands, for example typing ‘inventory’ would display a list of the items that you are carrying. In our case we are trying to have these elements always visible on the interface, which is not easy when you need to deal with a growing list of items, or people standing in a room.

At the moment we split the interface in three zones: a “story” section, an input form and a status area. Concretely each action from a player or from another entity in the same location can be translated as a narrative element while allowing the player to get a constant overview of what are her/his options and what kind of entities are around. This still needs a lot of puzzling to make everything look nice and tight with the constraint that all must fit on a single page at fixed text/page size ratio (I probably need to explain that in the future). For now, we focus on tidying up everything as much as possible and I think we will be finally ready to run some gameplay test sessions very soon! :)