Recoiling from the the startling news of yesterday’s vote here in the UK , I find myself looking at the post, as I was scheduled to write it, in a different light. We are well into the third year of the Magellan project. Mudlark is a member of a thirteen- partner European research consortium that covers nine countries.
Together we are developing and testing a multimodal authoring and gaming environment for location-based adventures (Magellan). Mudlark is one of five “end-user” partners who have each proposed a game for this new authoring tool – our task is to design and build the game with the tool as it is developed , trying it out with different groups before a beta launch in the final year.
We’ve posted about our game – Tribal – already and in the summer Matt will put up the latest news about some key new design work to fit with developments in the authoring tool.
The project is mainly funded by the European Commission. This makes the project very far-sighted – the scope is highly ambitious and the authoring platform could be formidable once Diginext, the French partners building the core of it, have finished all their tasks. The EC’s reporting procedures and Byzantine portal also make administering and reporting it very heavy work.
But does that last bit make us happy about this so-called Brexit vote?? No, not at all. The opportunity to work with so many interesting people across the continent far outstrips the annoyances of the Eurocracy. So we are feeling pretty embarrassed, not least because there are two other UK members of the consortium, so this country is well-represented in the consortium in terms of how many partners it has provided. I was talking about it only yesterday at the Venturefest event in Birmingham.
We are also fearful about what this may do for innovative digital businesses like Mudlark, whose whole vision is about connecting up the digital and physical worlds , and connecting and activating players and people across borders and countries.
Yes, not quite the post I set out to write about Tribal. The EU has gone tribal in all the wrong ways.
Mudlark’s New Year begins with something from the previous one: we are launching the videos from Playful 2014. The first three are available on our Vimeo channel today and we will feed you the rest over the next week or so.
Looking at the event through these particular lenses, we’re quietly pleased that the Playful tradition came through so well in the hands of its latest curatorial team. The theming – Hidden – opened up new avenues and framed some wacky thoughts.
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.
I promised I’d come back after Playful and write some more about the Hidden card game, giving more details about how the game worked.
Every attendee received two random cards in their snazzy delegate’s envelope – for the rest of the day, during time between speakers, they challenged each other with those cards (and any others they managed to “acquire” during the game). In all, there were over 600 cards in circulation, composed of 22 different game cards in 3 levels of rarity and 16 Agent cards. The weaker cards just let you do things like look at another player’s cards or steal one at random. The more powerful cards allowed you, for example, to possibly steal all of another player’s cards, but also required you to hand that card over (giving your victim a chance to get back in the game).
The aim of the game was to get as many Agent cards as possible and not get blown up at the end (if a player had managed to get hold of a Body Armour card, they were immune to the fatal effects of Tick, Tick, Tick…). In the event of a tie (which there was) Agent cards were drawn at random to determine which Agent was the winner (the magnificent prize being a copy of One Night Ultimate Werewolf). I did not reveal the goal of the game (or the potential hazards of certain cards) in advance – this was partly so that people could have fun discovering the different cards and effects as they played the game, and partly to stop people from simply hiding Agent cards when they came across them.
I think at least forty cards must have passed through my hands as I wandered around during the breaks (including three different agents!). It was very gratifying to see that hundreds of people were playing the game and having fun. Many were playing casually – the odd card exchanged here and there – but some players were really going for it. There were some fierce stone, scissors, paper battles caused by the High Stakes card, and I saw a classic move where someone used Planted Evidence to give someone else a couple of cards, and then returned a few minutes later with Big Target to steal all of them now that player was vulnerable. I was even a victim of Planted Evidence myself as I walked up to the stage to announce the final result! Someone grabbed my arm, showed me the card, and used it to offload a Tick, Tick, Tick… onto me.
P.S. It should be noted that the actual winner would have been Mudlark’s very own Emma Broadhurst (the only person to end the game with more than one Agent), but Charles purposely sabotaged her by sitting next to her at the end with his Tick, Tick, Tick… card. I’m not sure she’ll ever forgive him…
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.
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.
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.
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.