Archive: Projects

Thoughts on an innovative location based game engine

We have been working on a European project called Magellan for the last 2 years. The aim being to design a new platform to build computer games that take place in real world situations. The platform is being designed to accommodate linked technologies like VR, Augmented reality, iBeacons and indoor location systems. We as Mudlark as one of the user partners have been tasked to come up with a game that makes use of some of the features of the platform. The working title of the game is Tribal. As the game progresses we will release more information. We are still at a stage where frustrations bubble up because of the spread of partners across Europe and the difficulty of communicating coherently with each other on some of the finer points.

The character designs for our game contribution to the Magellan Platform - Tribal

Some character designs for Mudlark’s game contribution to the Magellan Platform – Tribal.

In an attempt to convey some of my thinking about how such a platfrom should work I put my thoughts into a short video. I am sharing it here. Originally It was supposed to be internal memo for the project members. But I thought that it might be useful to share it more widely.

Note – I am not a regular vlogger, so please ignore the fluff on my jumper and the tshirt hanging from a cupboard in the background…ahem.

I include below a transcript of the wording of the video below:

I have been thinking quite extensively about what is an ideal location based game engine with particular reference to playability and the eventual business case.
In order to do this I looked at the fundamentals involved. What does a user want and what does a user need when it comes to playing or making a location based game?

In order to do this we need to get to the essence of games what is universal to all games and absolutely essential to their existence.
Having spent the last 6 months teaching students about game design I became aware of one essential feature of all games that for some reason, had previously passed me by – collision.
This may be obvious and has been stated by far greater minds than my own. But it’s important to state this from the outset.
Objects collide, meet or crash into each other and the players aim is either to make that collision happen or to avoid it. Collision also defines the boundary of play – a wall or a forcefield. Even a sandbox game like Minecraft is limited by the blocks that the user creates boundaries with.
Whether it’s a game of Grand Theft Auto, Pac man or chess, players are engaged in this constant quest to either make a hit occur or avoid one in order to protect their existence in the game arena.
All other events are merely by-products. Outcomes, feedback or stats resulting from collisions

In a conventional video game these collision occur in a virtual space either 2D or 3D where collision detection engines, rigid and soft bodies are constantly aware of a potential intersection. Super fast frame rate listeners waiting for that bullet to hit or that tunnel to end. This space is defined in a fixed ordered universe of code and geometry.
However in a location based game the rules are different. The arena of play involves the real world and the spaces within it. The boundaries are loose and ill defined – there is nothing to stop a player going wherever they choose and redefining the rules of engagement.
When looking for fundamentals in a location based game we need to look at another area of rule based experience in order to define these essentials of play.
We find it simplified best in childhood games played on the street, like ‘tig’ or ‘tag’, ‘hopscotch’, ‘bulldog’ or even ‘kiss chase’. In these worlds the rules are loosely bound around simple constructs. players become “it” and have to chase the others, or they become “out” because they move to a space that has been defined as ‘off limits’. Often the rules change or evolve during play, sometimes the arguments about these rules actually become a part of the play itself.
Games are normally defined by geographical boundaries: the end of a street, the edge of a field or a park, a garden or a room. But often these places are movable the same game can occur in a radically different space, as long as the new boundaries are universally agreed. In a location based game proximity is important: who is near and who is far. In kids games proximity in terms of the ability to see and interact with another physical body is essential – the experience is limited to the sensing capability of the human body. In hide and seek sensing the other players is the name of the game.
In a location based video game augmented by digital sensors and processors. The sensing capability and knowledge of the surroundings can be extended and enhanced by the technology in the users hand or pocket. Real world objects meet digital ones depicted on screen, felt and heard through haptic or audio feedback. Distances can be shrunk by servers and 4G connections, players can operate out of eye contact as map bound avatars and IM messages.
Despite these enhancement there is still an element of ill defined and ad hoc rules dictated by the contours and chaotic fluctuations of real world environments. Not only does this effect the planning of a game but it also effects it’s execution and delivery. Each game can be different to the next – disrupted by a parked car, a network drop out or a rain shower.

I would define the fundamentals of location based gaming as this; Location based games need to be fluid and evolving, they respond to their setting adjusting themselves to the needs of the players.

If I were designing a platform for location based games. I would start with a simple premise.
The person in a real space. Where is the user right now. I would have the editing tool as part of a mobile app. If I were a young person or technically less literate person. I would want to experience building a location based game from the ground up as I go, in situ. To see it evolve in front of my eyes.

To expand this idea lets imagine a user journey:

Jane walks onto a street with a device and places a digital object somewhere on that street. Perhaps she would make it a pick up and she would go and experience the sensation of walking in a real space and picking up a digital object. Perhaps she would want that collision to have more impact. maybe it would explode or move away from her.

Perhaps she would then want to generate multiples of these pickups all over her local area. So she could take a walk and pick them all up. She wouldn’t want them to be inside buildings as she might not be able to pick them up, so maybe their distribution should be limited to parks and streets.
Perhaps she would want to attach an outcome to that maybe a score or value that increments with some way of representing that.

Perhaps she would want some of these objects to become enemies and allow them to chase her or have negative impact on her health if she gets too close.

Now her friend Dino has joined and he is on the street with his smartphone. Jane wants Dino to be able join the fun so she invites him to the game she has created. They discuss their roles and decide that some of the objects are Dino’s allies so they will not attempt chase him but they will chase Jane. They set a flag raiding marker in 2 locations. Both Dino and Jane need to avoid the agents of the other player and the mines they have laid in order to steal the other persons flag.

They try it out and reconvene to see where they can improve, after some tweaking they invite another friend to play.

Later on they decide that they want to design more elaborate custom graphics that represent their avatars more faithfully. One of them wants to have 3D Augmented Reality to represent the enemies in the game. Jane activates this function so all the players can spot the enemy through the camera. That evening they design new graphics and add them to the game using the desktop editing software. The next day they test it out and tweak parameters further.

They have to end the game abruptly so they save the game in it’s current state to return to it later.

Later on Jane decides that she wants to make a new game that takes place inside her work building so she pay’s for the internal sensor expansion pack and waits for it to be delivered. Once it arrives she sets up the receivers and starts to build a new game object by object, collision by collision.
…and so it goes.

Experience location, collide with objects and evolve the game play in real-time – This is my vision for an innovative location based game platform and engine. One that takes the concept of a sandbox environment and makes the real world a laboratory for sandbox games built straight out of the box.

This links directly to the business case, as the player learns about the value proposition of locative gaming while actually engaged in building it. A niche concept is made more marketable, through direct and instant interaction with the notion of location as a game space.

They can be the architect of their own experiences from inside the locations around them.

At the River

We were approached by a client to make a game which could be played by a group of people in a festival tent.

The idea was that anyone could join in (or drop out of) the game at literally any time. The game should be instantly understandable, suitable for children and fully co-operative. It should feature a group of up to four players travelling down a river and tackling mini-game tasks that promoted a spirit of working together and helping others.

Paddling down the river - note the 4-way split screen
Paddling down the river – note the 4-way split screen

Co-operative game design presents an interesting set of challenges. In most co-operative games, gameplay can be very interlocked and quite ‘formal’ – i.e. there are puzzles and challenges where each player has to do a certain particular thing in order to complete the puzzle (e.g. one player stands on a switch to open a door while the other one runs through it and props it open from the other side). This didn’t fit our game for a number of reasons: we didn’t have the time/resources for this intricate design; it didn’t fit the more simple co-operation that would be required between a group of people (possibly children) that had never met before; and most importantly we had to ensure the game was still playable by someone playing on their own!

Instead we tried to design games where everyone could contribute, but where it was clear who was doing the most work, where players could mess things up and get in each other’s way. In this way a lot of fun can emerge from very simple games. Players shout at each other, boast, encourage, remonstrate and generally have a good time – exactly the sort of thing you’d want at a festival! Examples include pushing crates into place to make a bridge, and patching & pumping up a giant (and very leaky) balloon.

In this mini-game, players push crates together to form a bridge - other players can join at any time
In this mini-game, players push crates together to form a bridge – other players can join at any time

However, the game had a very limited budget and time-scale. Roughly speaking we had about four weeks each for a coder, designer and artist. So we had to make some tough decisions early on: the mini-games would have to be very simple; we would adapt art assets from the Unity Asset Store rather than making everything from scratch; we would use a single PC and 4-way split-screen on a large screen rather than networking four PCs together.

We built the game in Unity. I’d never used this game development environment before last year, and I am still amazed at how much it speeds up and improves the development cycle. I would estimate that using Unity at least doubles the speed of development. The coder can ‘expose’ all the important variables, which means the designer can tweak gameplay and difficulty directly in the editor without any code changes. And if you search the Asset Store you can find some great assets for tens of pounds that would have cost tens of thousands to produce in-house.

The game in the Unity editor - note the variables for changing the boat handling on the right-hand side
The game in the Unity editor – note the variables for changing the boat handling on the right-hand side

Kev Cook did the coding – I’ve worked with him a number of times over the years and he is quite simply the best (and fastest!) coder I’ve ever worked with. We have a similar broad-brush approach to game development, which makes it very easy to work together. I think the following email exchange nicely illustrates this approach:

Kev: I’m whipping together the Rhythm game at the moment. It is good that they’re all coming together nicely. I love working like this. Rough blockout of the whole game. Then another pass, getting it very roughly playable. Then revisiting and filling in some more gaps, adding animations, control tweaks, sound etc. Having people play it and offer opinions at each pass.It’s very ‘Top Down’, a bit like an artist would with a painting.

Most coders would tell you this is the wrong way of doing it. You need to break down every task at the start and build up the components. “If it’s planned correctly, then it only takes one pass”. But I’ve been doing it for 24 years and know that’s bullsh*t. So f*** ‘em! Only after each iteration can people get their hands on it and see what will and won’t work, what art and animations will look best and where. Changes can be made mid-process. Game development should be a very flexible process. Unity suits me down to the ground because it allows me to knock up prototypes in no time. Me and Unity sitting in a tree…

Tom: I absolutely agree with every word of your email. This is definitely the way to make games. It’s impossible to design and plan a game completely in advance. You can make an educated guess on what will be fun, and what assets you need and how long it will take. But you need a process of iteration to make things feel right and fun.

I am conscious that when I write designs sometimes it comes over a bit wishy-washy, because I say “we could do this or we could do that” but often it’s just a case of trying something and seeing if it works, and having a plan B ready for if it doesn’t. And the best way to do that is trying a very rough version and tweaking it and then being prepared to abandon it if you need to (which is a pain, but at least you haven’t plowed huge amounts of time, effort and finished art assets into that one perfect version which seemed like a good idea on paper but which is actually no fun to play).

In summary: yeah, f*** ‘em!

Kev: Exactly! How many projects have you worked on that have been planned to death, detailed schedules, task breakdowns, etc. Then months of work by tens of people manage to produce something that just doesn’t work. Sounded ok on paper, but actually, it’s no fun at all.

And amazingly, almost everyone you talk to in development houses will still insist that this is the way to do it.

The thing is: developing a little co-op game this way really is fun in a way that, sadly, big game development so often isn’t. And it looks like we’re not the only ones to think that the days of behemoth all-encompassing game design documents may be numbered.

Floating off over the rainbow at the end of the game
Floating off over the rainbow at the end of the game
Designing Cold Sun

An exploration into a strange future; narrative, weather and consciousness.

Cold Sun is a dual-mode adventure game that is affected by real-time weather. In the game you flip between your Existence which is set in the future, and your Dream world which is a one-touch platform game where you must navigate a magnified environment—generated by the real weather data. Matt describes the state of this research project so far.

Some themes we explored for this stage one prototype included:

· Coils. Mortal coils, electric coils, etc.
· Circles as a general theme. Sun, timers, time running out, the globe.
· Colours and it’s variation in weather patterns.
· Dreaminess. Blurry. Disorientation, spirals.

After poring over images we pulled together using Pinterest (a really useful collaborative moodboarding tool we love to use) we started to generate some of our own visuals.

Spiral experimentations.

Wind denotations.

A cold sun.

We then started to explore how using these visual ideas could work as a title for the game.

A playful option for Cold Sun.

Cold Sun using ‘weather front’ sign.

We arrived at a really atmospheric graphic that we could use for a title screen, some Dream mode disorientating circular gameplay, and more.

Final Cold Sun title screen.

Dream mode gameplay.

Mudlark creates games, from small mobile and desktop games through to real-world experiences based on your heartbeat or games the size of London. Game design and playful thinking are central to Mudlark’s creative processes. Take a look a other games we have made.

Cold Sun – The rain wont stop play

We are just approaching the final phase of research into a game called Cold Sun. This is still very much in the realms of a prototype, however the initial results both from the point of view of the graphics and the game play are very promising.

The initial idea emerged from a drunken conversation with Canadian developer Jesse Blum and Mudlark founding member Rachel Jacobs while working in Brazil in 2012. We were doing some experiments in a farmhouse in the rainforest outside Rio de Janeiro, the isolation was quite profound, we were 3 hours walk from the nearest road.

The Game Intro Screen

We started riffing on –  what if you woke up alone in a place like this with the rain coming down hard, as it does a lot in this part of Brazil. A lone survivalist, having to piece together what had happened to the world while they were asleep. This is such a classic trope so beloved of games and movies – the loner who wakes to find themselves in a world changed beyond compare. But what was attractive was not only this classic narrative structure but also how weather could play a vital part. Our time in the farmhouse was hampered daily by the pattern of heavy weather, sometimes it was so heavy it seemed to affect peoples dreams. So we wondered if there was a way we could create a game where real weather data was essentially invading the imaginary universe of a game. We also liked the idea of the player being unsure of who they are in the game. Neither male or female, man or beast, they must survive in order to find out the truth of who they are.

What we have come up with is a mobile game that takes real-time weather data from a player’s location and amplifies it in a game universe where climate change has drastically changed everything. Challenging the player to think adaptively, notice weather changes around them in the real world in order to plan their next move in the game.


The text adventure in survival mode

Our research has taken us on many journeys into many approaches as to how you might build a game like this. We have gathered research with a number of partners including Lancaster University, Anglia Ruskin University and Candace Howarth a climate scientist currently working with the Department for the Environment. We have been given insight into stark futures of climate change and have factored some of this thinking into our game world. Topically this information is what is informing recent news reports about the future of the British climate.

Infinite runner in dream mode

We have distilled the research into a game that has 2 modes – dream and survival mode. In survival mode the character has awoken to find themselves on the point of death, they must make decisions in what is essentially a text adventure, to stay alive. Barely able to move and in their confusion and weakened state they pass out frequently at this point the game switches mode to dream mode. In this mode the game becomes an infinite runner where they have to dodge enemies and jump across strange spheres. In both modes aspects of the game play whether it is narrative features or game parameters are influenced by the state of the weather outside the players window.

 

We are releasing the game to a test audience in the next few months, they will test (alongside ratings of levels of fun and engagement) whether they feel a heightened awareness of the real weather as a result of playing the game. Bring on the rain!

Going Off the Rails

So 2014 is here. A time to reflect on some of the research projects we have been doing in the margins of 2013.

In June Mudlark received funding from the TSB Feasibility Study fund to look at tracking user travel behaviour with the view to building game logic around it. This was a bit of parallel research designed to compliment our previous work on Chromaroma by extending the game beyond the constraints of fixed infrastructure in the form of smart cards and RFID terminals in stations and on buses.

We wanted to explore how a user or player could get an enhanced history of their travel in London and beyond by monitoring their movement and transport habits over time.

We were aware of the success of the Moves app and the effortless way it tracks the different modes of travel from walking, cycling, running and transport. It does it with a near miraculous level of accuracy. We wanted to go a step further and see if we could create a more granular level of detail than is provided in the “transport” type of Moves. We believed by developing our own system we could tease out the fine distinction between: train, underground, bus and car.

Working with the School of Electronic Engineering and Computer Science at Queen Mary University we made this happen by utilising and combining sensors and data available on current smartphones – GPS, Accelerometer. We developed an Android App based on a unique algorithm that measures movement patterns and corrects errors in classification through analysis of user movement patterns over small segments of time.


User Interface of Test Android App

Our feasibility test around East London in December with 5 test subjects using Bus, Train, Underground and Cycle, correctly identified transport mode shift of the user with an overall accuracy of 78.5%. This was an amazing outcome for something that was basically only working with the data being generated by the phone from the testers movements.

We also wanted to augment the sensor algorithm with online look-ups of live transport data. To test this aspect we did quick development that used aspects both of the Moves API and the Transport API (a service which provides user routing on the UK’s transport network’s). We took my Moves data generated on my Iphone and then ran queries on the start and end points of journeys with Transport API’s routing service. This produced remarkably accurate predictions of user journey type down to Bus route or train line.
We ran across some issues with it falsely choosing bus instead of train and vice versa. We discovered accuracy was increased by choosing the fastest journey in any list of possible routes between A and B. This would obviously not always be the case. A user may choose slower journeys and so a future addition would include a method to track likely routes based on a user’s past history of travel and how often they may have travelled that route in the past.


Interface showing “Moves” journeys and the journey type predictions

We came to the conclusion that by combining the App with a query of the Transport Api we could reproduce a user’s journey on any transport type in the UK with a high level of accuracy. We hope to explore this more with a future iteration of the app and also integrate some game play in the mix. Watch this space as this develops during 2014.