We are working on a new project. We can’t talk about it but we are sharing some early concepts for you to look at and wonder what it might be.
So finally we near the completion of development for our Tribal game as part of the Magellan game platform.
It has been a long and complex process and many of our initial concepts have been modified in order to adapt to the changing requirements of the platform.
The most challenging part of the development has been trying to build a game on a piece of software that is still in development itself. The shifting sands of software versions, compatibility and feature change has meant that sometimes the process has been a little like trying to paint a landscape from a moving car.
One of the key aspects of our game was that it would be a multi-player game where 3 people could engage in playing our game simultaneously in the real world. This requires real-time connection with the server between 3 players on a 3G networks and this doesn’t come without its own problems. Between ensuring network coverage, server connection and synchronicity of experience, the Tribal development has highlighted some of the limitations inherent in these kinds of games even in a modern metropolitan smart city. This probably why Pokemon Go is still a single player experience because mobile networks still have a high level of uncertainty built in, making real-time interactions with other players challenging for any multiplayer game.
In moving from our earlier version of the game we had reengineer the entire resource system for the game. We have added new metrics in the form of Attack and Defence. These have now impacted on the fighting mechanics – attacking and defending, strength and a teepee system which creates a defensive platform to help protect players from one another. Making sure the metrics were correctly increased and decreased based on different outcomes and balancing it overall so the game stayed fair was tricky at times and required many trips outside in varying weather conditions to tweak the experience for someone playing outside.
However, we reckon we’ve managed to build a compelling game experience. We’ve successfully managed to get 3 people to play. They can now build a tribe, collect resources, stealing and fighting each other for dominance in the game, while avoiding random attack from the wild beasts who prowl the game. They have been able to play through until the last surviving player is declared a winner.
We plan to continue testing during the summer in order to have it available for the public to play in the Autumn. Only the strongest will survive.
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.
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.
Chromaroma was in effect a gamification and a Quantified Self facility for the public transport user, using the Oyster Card sytem. We wanted to explore how else we could develop this thinking and very quickly we alighted upon loyalty schemes. People use their various loyalty cards as easily and seamlessly as they use travelcards. Why not investigate turning a loyalty platform into a game platform?
We’ve started that investigation as a Innovate UK- supported Proof of Market.
We are studying the case for the transparent return of this data back to those who generated it, firstly by demonstrating how users would understand that data and find it useful.
Our motives are:
Idealistic – we really believe that shoppers should get their data back for their own benefit;
Playful – we have several brilliant concepts for gaming shopping;
Commercial – we can show players in this sector a trick they are missing, and work with them to develop a new disruptive model. We want to explore how, by using gaming techniques, they can improve retention with the ‘stickiness’ of the customers’ engagement in the game, and devise challenges specifically aimed at increasing spend, frequency and cross-selling.
For sector expertise, Chris Jacobs is part of the team. His has worked in systems for over 40 years, the last 20 of which have been exclusively in consumer-focused marketing applications. He has been personally involved in the design and implementation of over 90 customer loyalty/CRM schemes and is familiar with most available customer loyalty and CRM solutions.
We’re also working with two preeminent academics in the personal data sphere. Dr Kieron O’Hara and Dr Max Van Kleek are senior research fellows on the SOCIAM Social Machines project at the University of Southampton. They specialise in the interface between society and technology, the use of big data and open data for citizen and consumer empowerment and technologies to enable data subjects to gain benefits from their own personal data.
We are very pleased to be announced as one of the first companies to secure phase-1 grant funding from the SME Instrument of the EC’s new Horizon 2020 scheme, which supports the formation of the business and development plans of innovative SMEs.
Mudlark is among the 155 small and medium-sized enterprises (SMEs) selected from 2,662 proposals from 21 countries. We have won funding to do a business feasibility study for the successor to our travel game Chromaroma, in a proposal entitled Off the Rails.
Chromaroma started as an experiment in ambient gaming – using Transport for London’s iconic Oyster smartcard system to return people’s travel data to them in the form of gameplays.
Since its 2010 launch, Chromaroma has had thousands of players, attracting global interest from transport systems and operators. Mudlark has consequently grown a unique expertise not only in data-driven game design but also in transport policy, behaviour change, sustainable travel and mobility technology.
We are now calling the Off the Rails product “Wend”, reflecting its multi-modal ambitions to give players back useful, playable information across all their transport modes as they wend their ways through the world. Unlike Chromaroma, it will not depend on a ticketing infrastructure, using mobile devices instead of smartcards.