The brief

The context for this experiment was set by a combination of the commercial creative studio, Raucous Caucus, and another game development enterprise, Echo Games. Raucous Caucus in particular work with pubs to bring new entertaining experiences for customers through technology. Pubs and their customers are changing. Pubs and chains are looking for new ways to gain and retain customers and build on both the traditional pub role and extend to new meanings for these social spaces.

Create a pub based activity that complements the traditional place/meet/talk/drink/relax roles of a pub with a game or activity that can give a reason to come, a reason to stay, but that does not become a barrier to face to face interaction, eating and drinking.

A video showing the project development so far

The hackathon

As a group, the MSc Creative Computing group learned some practical and fast ideation techniques and employed them throughout the day.

More detail around these techniques and their use is documented in this separate post.

Ideation stages

• unstructured, uncritical idea generation

• expanding the client brief by generating questions for insight

• problem space analysis with the product ideation framework

• five fast ideas

• use of mood boards to find inspiration, similar solutions, sources to draw upon

• as a group, selecting the two most promising solutions, which were

  • multiple player Pong (catch/frisbee)

  • a sandbox for social VR games

• adopting a design workflow, with two teams working on gameplay and technical, alternating between separate and joint working sessions

  • generate key questions in gameplay and technical streams

  • my team, following the game play side, applied our questions to both possible solutions

• teams were formed by affinity to one or other solution.

These techniques allowed us to

• explore the problem space

• learn/identify specific constrains

• generate ideas uncritically

• narrow down and explore a few of these ideas

• give more critical thought to possibilities and limitations

• devise and ask a set of enlightening questions of the client.

My team, comprising myself, Joe Bridges, Billy Kirk took on the "pub pong" borrowing from the immediacy and inclusion found in frisbee/catch.

After the hackathon

Pong is the original lo-fi video game using a metaphor of simple ball games for a digital game. The idea we had was more like a game of catch or frisbee, but embodied as the passing of some digital puck between players. Pong stuck as a metaphor because of its loose translation of a physical ball game to a simplified digital realm.

We were drawn to the immediacy of catch and frisbee, and the fact that, even though some skill is required, it has a low barrier to entry. It's a very inclusive game where the idea is to challenge yet include everyone, regardless of ability. The difficulty, both for individual "throwing" and "catching", and for the players working as a team towards a goal, can be shifted up for greater jeopardy and reward. I developed this interactive model to look at what the imaginary game space would be like.

An interactive version of this (with the code) can be found here.

Stakeholders and motivations

These are defined more extensively in appendix 1, but summarised as

These can be summarised as follows.

• The pub wants compelling activities to keep people entertained, but not in conflict with established pub successes. Can be tied into drink promotions and seasonal events. must be linked to the space of the pub.

• players want a low skill (initially), low barrier, compelling activity, connects with friends, get a buzz, and the chance to win rewards.

• The studio wants to help the pubs meet their aims, in exchange for sees and subscription to a service.

Game play

We had lots of early ideas for gameplay, both as core concepts for making the game compelling and practical, and ideas to develop the fiendishness and stickiness over time.

These are listed in appendix 2, but can be summarised as follows.

• The core game is based on a simulation of catch/throw, where timing is key, and long runs without a drop wins points.

• The game is based on group cooperation, and encouraging verbal interaction and coordination.

• There should be a low barrier for that anyone to start playing, but there are ways to introduce more skill and intrigue.

• There should be ways to make the game sticky.

• There should be ways to introduce new game elements for the individual and for the team.

• There should be mini games and variety.

Game variations

From the start we were keen to move away from the mobile phone screen if possible. People spend enough time on their phones and encouraging their use among friends in a pub seems like a step away from one of the goals. Inevitably the development and prototyping of game concepts will be based on the phone but we were keen to embrace alternatives in parallel.

One such possibility was to create an audio-only version of the catch metaphor. We had a few ideas for how players could be identified by distinctive sounds (perhaps animal sounds or sound effects). Ball trajectory could be represented by sound on a device held by the target player, with pitch or some of the variation of sound representing distance, and the need to undertake the "catch" and "throw" activity. The pass to another player should be by selecting their identifying sound.

Another possible variation would be a self contained device with a series of lights and buttons that could be employed.

Available technologies and available skills

Given the time available we needed to stick within known skills and technologies available to the team. Billy and Joe have Unity experience. They suggested that it has extensive multi-player real-time interfacing and will look into the possibilities

Dave did not know Unity at all, but has experience with Javascript for real-time peer to peer solution and graphic front-end, and will be able to create rapid mock-ups

Exploring the limits and constraints for a solution

We made a paper prototype for thinking about the physical and game play challenges and how to stay true to the original concept.

A few flaws and problems immediately emerged. Without being able to see the ball in flight, how would players know they were the next chosen catcher, and how far away the ball was? Given that players’ relative positions in the real world may be impossible to know digitally, and in any case people could move during game play, the use of simulated physics for the ball behaviour would simply not work.

We would need to find creative ways to indicate awareness of being the ball’s target, proximity and speed in flight and create a simulated catch/throw action, being able to select a new target decisively but not reliant on an absolute physical position.

Although mobile devices were chosen as the prototyping target platform, we weer keen to explore self-contained, robust game hardware that might not have a screen.

Some practical limitations

• This is not a physical game of catch.

• The devices do not know where each other are.

• P

ubs have unreliable wifi coverage so we should not expect this. This suggest the need for a peer-to-peer solution, with no back-end. Any infrastructure, equipment needed by the pub should be minimal, and non-specialist.

• The pub is potentially a hostile environment for precious equipment, so if people are using their own phones, they need to be used in a moderate fashion without large physical gestures.

• We need to protecting against antisocial behaviour within and around the game

• The pub wants this experience to be locked into the location of the pub. They want some control, visibility over who is playing it, with whom, but with very low burden on staff. Some way for them to recognise, validate and redeem winning scores/achievements

Play testing

We took our paper prototype to volunteer play testers (Phoebe carpenter and Harvey Bett) and ran through the concepts and paper prototype with them.

We learned the following from this.

• Even in its simplest form (rolling a ball across a table and keeping a rally going), the real life game of catch inspires joy, promotes focus on a joint task, and has some physical/coordination skill (however basic).

• As soon as you translate this to a device (or in this case a paper mockup) you lose that immediacy, and you need to work hard to bring that back.

• The idea of cooperation to maintain a rally, and tasks such as everyone gets a touch tour it into a game.

• Challenges, such as golden touch and poison touch, did generate some intrigue.

• Short rounds work, with a game being built out of a sequence of these and achievements.

The idea of the sound-only version of the game was also tested as a concept. The concept was tested with eyes closed and a pet toy ball with a bell was rolled between players. Success was very high, and again it seems to inspire engagement and joy. The key learning from this was that

a sound-based version of digital catch could work if we could devise an interface.

Prototype UI

I developed a mobile phone format, web based interface to test some possibilities for a screen based UI. This prototype was not touch enabled, but allowed the testing of a very simple interface to simulate the stages and action of catch.

Stages of a simulated catch/throw action

1. anticipation

2. awareness of incoming ball

3. judging the catch, with the risk of a fumble or a drop

4. selecting a target player to throw to, against a time limit

5. successful pass

I devised a state machine to model the sequence for a user’s actions and the sate of the UI, and from this modelled a mock up UI.

Rough state machine for prototype UI

Stills from prototype UI.

1. Waiting - the puck is not in my possession or heading to me

2. Early warning that I a in play and puck is incoming

3. trajectory of puck, with clear "catch-zone" indicators

4. Selector to pick player I will pass to, with rotary countdown

5. time’s nearly up.

6. puck in transit selected player

7. A drop ( either fail to catch or fail to pass within time limit.

An interactive version of this can be found here, where you can also view the code. This web-based prototype uses mouse interaction, as touch was presenting problems on some devices.

From this we learned that:

• a simple metaphor for the five stages of a catch/throw can be effected through simple interface (that could easily be touch enabled);

• this could be tuned for skill/difficulty level, and for fewer, more players; and

• it needs limited guidance on how to use it.

Alternative UI - audio based.

Revisiting the idea for an audio only interface, I developed a prototype UI to test some of the ideas for this. although this still uses a visual interface for developing the idea, it can be seen that some simple ideas for an audio UI combined with a one-button input could potentially work for the same 5 stages of a simulated catch/throw.

An interactive and audible version of this can be found here, where you can also view the code.

What we learned from this.

• That a fairly simple audio interface, plus a single button, could embody a metaphor for the catch/throw stages

Technology

Aside from the decision whether to use players’ mobile phones or to have some dedicated game hardware, there is a more pressing technology consideration.

The lack of a reliable wifi network infrastructure means there is no way to have a functional back-end for the game, either on some on-premise device, or cloud based. Yet the game requires real-time coordination of game state between devices, fast enough to simulate the passage of a ball through the air.

Some peer-to-peer solution is needed at two levels.

1. there needs to be some peer-to-peer, infrastructure-free network mechanism, and

2. the implementation of player front-end must contain all the state management and coordination between devices itself, with no back end.

Without this restriction, based on a javascript, web based implementation, I would suggest a node.JS back end, and empty socket.io for real-time message passing between the devices, with state managed on the back end. The Node server could sit on a cloud hosted facility and could provide security and leave/join mechanics giving the pub a console interface to manage games and participation in those games.

None of the hackspace team have direct experience of solutions for problem 1. A little research provided the following potential alternatives

• Web based peer to peer solutions

• Bluetooth network

• Audio peer to peer network

Findings for each of these are documented in appendix 3

5G mobile networks will eventually offer an ideal solution for this, but they are a long way from general deployment. Location based games with local, edge delivered content, and temporary local/event specific networks within the network are all key application areas for the technology.

For problem 2, we can, for prototyping purposes, simulate a true infrastructure-free network over wireless web connections, and focus on the logic for real-time messages and state management.

A working interactive model of multiple players and the virtual game space, modelled using only peer-to-peer, client-side code. A working version, with code, can be found here.

I created a model of multiple devices in a peer arrangement within a single javascript visualisation. Although in this model, the whole system with multiple clients is implemented in a single software module, each device is represented in code as a single, independent object oriented agent, running on its own, and relying on peer message passing as the only coordination between these virtual clients.

In summary, the software for any client device is capable of being a master or a slave. A device can start a new game (and be a master), or join an existing one (and be a slave). The master collects messages of current state, from all other devices and then shares the arbitrated state back to all devices, so there is only one version of the true state.

Each device has simplified catch/throw action (if the ball is on my screen and I click on the screen, I pass it to the next device)

When no ball is in play, the master randomly nominates a player to throw the ball.

The simulated shows the individual device screen along the bottom, and a simulated game space above.

Elements needing further practical consideration

• Tying the game to the pub as a physical location

• How does the pub initiate, or control access to the game, visibility of completed games?

• How does the game get authorised, started, and how others join (how do you stop others from joining, unbidden)?

• How does the game end, and how do we cash in our points?

• Game timing, drinking, buying, incentives

• Accessibility: we want fewest possible exclusions and barriers to play

Critical Reflection

The prototype and development

The game concept seems pretty sound, and a potential good fit for the intended space and audience, although it would need testing as a working prototype to assess this properly.

There are plenty of directions for exploration and development in order to extend the idea, and keep it interesting, some of which have been mentioned in this document. The team must resist the temptation to incorporate anything beyond the core concept in the prototype to avoid scope creep. The minimum viable product for prototype is the basic catch-throw mechanic and some simple games built around that.

The possibilities for using Unity to develop the game was never fully explored. Multiplayer, real-time, peer to peer capabilities would be essential, and these were not fully researched.

Of the two sides of the peer-to-peer requirement, the first, a network technology that did not rely on wireless internet access, remained unresolved. Bluetooth, web-specific solutions, and audio networking all came up short of viable for the specific need. further research wold be needed.

The second problem of server-less real-time coordination was effectively solved through modelling an asynchronous collection of independent virtual clients and developing a very simple messaging and coordination protocol.

Although javascript for prototyping the front end and as a proxy for the backend was used as a temporary workaround while the Unity investigations took place, it could in fact, could be an appropriate app-free way to deploy a small, real-time game like this.It did emerge during investigations that an off-network peer to peer game could have popular uses in other environments beside the pub.

Team and design process

The rapid ideation and development on the hack day was very effective for drawing out a viable solution in a short time, and allowing us to form a team around that as a project.

It was disappointing that a prototype that could be demonstrated on mobile phones, even with caveats, was not achieved. There was enough capability among the team, and no shortage of ideas, but there was alack of coordination and commitment to well planned actions. In such a short development time, this meant some good theoretical design and actual implementation did not meet up. Commitments between team members were implied rather than explicit.

The following measure were absent.

• Agreement of project vision and scope, and commitment by all team members.

• An outline work breakdown and plan, agreed to by all.

• Next steps, assigned, and committed to.

• Regular communication, and accountability for own actions.

Individual contribution

I feel that I should have taken a more explicit leadership role within the team at the start. But being among a new group of peers I did not want to be presumptuous.

While I am happy with the technical and creative contributions I made, the project structure to fit them into was absent, and so their potential was untested and unrealised. The work I did helped me think about the expectation of always having an internet connection, and some of the creative alternatives that emerge when you do not rely on this.

Lesson learned: give a chance for others to demonstrate leadership intent, but be prepared to step up rather than to leave a vacuum.

What would we do next?

I would be tempted to continue with javascript for building a prototype of the interface and peer to peer mechanics, sitting on top of a simulated peer to peer network (say bluetooth) that was actually running on a TCP/IP wireless network.

This gives us rapid development and testing cycles.

I would want get as quickly as possible to a mock up of the join, play and finish mechanics, with two or three different game patterns that could be tested with some play testers.

We would learn enough from this to be able to make a refined prototype and an informed presentation to the studio and/or potential customers.

---

Appendices and links

Appendix 1: The Stakeholders and their "Why…?"

Who cares about this problem and any solution and why?

The pub (whether independent or chain)

Want to give customers a reason to come, and then to stay: something linked to the location and which does not obscure the things that the pub already does well. The activity should keep the pub at the centre.

It should complements normal pub socialising (though it could be grown to inter-team competition)

There is a potential to create a commercial opportunity through promotions, competitions. Team prizes are spend-to-win, win-to-spend related. The activity should create and intriguing buzz around the team, provokes curiosity among observers.

The duration of the activity allow for drinking, encourage interaction, and have natural breaks for drink buying.

A sequence of games to encourage a lengthy session, over many small games.

The experience could be extended, with action replays, leaderboard, player of the week, weekly competitions? This could be an opportunity to tie in data-harvesting, if that’s the way the pubs want to go. This should be an informed choice for all parties and should respect GDPR and privacy rights.

The players and team choosing to play

The activity is a bonding opportunity that requires little skill, is inclusive, and offers a low-barrier to having a go. There should be a chance to win beer points, or discounts. The more you play, more you can win. This should be appealing to everyone from, non-gamers, socially shy to competitive alpha’s. It should be easy enough to have a go a get rewarded from the off, but ramping up fiendishness and curiosity to keep it interesting.

People would play individually for the craic, joy and the kudos, and as a team for points, prizes, discounts.

The activity encourages cooperation and IRL (in real life) collaboration, so it is only partly about the device, and just as much about person to person interactions (like a card game).

There can be competitiveness between team players but not so that it creates the possibility of exclusion or allowing the less skilled/able to slip out of game play.

There should be a short term buzz from taking part, with rewards for sustained effort: more play for more reward.

Development Studio

Devise a game solution for a pub that gives them their intended increase in foot fall and spend, and leaves them happy to pay a recurring license fee based on time period/usage for the games.

Appendix 2: Game Play Ideas

An exploration of game considerations and desirable features

• capture the immediacy and satisfactions of playing catch/frisbee

• Make it a group co-operative and bonding experience

• very simple to get people playing, even for those with limited skills, introduce harder mechanics gradually

• encourage, depend upon person to person coordination outside of devices to increase the immediacy

• encourage cooperation, teamwork to accumulate points

• subvert cooperation in some rounds and have competitive rounds, or one player being an assassin.

• Extending the experience - playback videos, comedy commentary (Jackbox style) leaderboards, leagues.

• User experience, motivation, reward, jeopardy, scores, powers, handicaps

• Fairness and protection from subversion, interference, bullying

• games for one person, two people, small groups/tables, large groups, intergroup competitions

• We just need intent to seek out someone to pass to. This could be a colour identifier, a simulation of position (but this is tricky).

• However user catch/throw/pass should feel intuitive, and be sensitive to an idea of a safe catch and a good throw, within a time limit, and a clear possibility of fumbling or dropping.

• There should be some proximity/trajectory countdown for the player, to ready them for an incoming ball, both as an early indicator, and to judge the timing of a catch.

• rely upon basic skills, but introduce chance, jeopardy, power-ups and bonuses for sustained accuracy.

• team cooperation to solve situations 9for example ensuring that everyone gets a touch within so many throws to avoid a penalty

• golden touch - a player is randomly assigned a power-up status, where a successful catch by them earns double points and they must coordinate other players verbally to keep returning the ball to them before the power up expires

• poison touch - a player is randomly assigned a poison status where a catch by them will incur penalties. This could be come contagious where over time, neighbours also get infected, reducing the number of players in play.

• streaks and rewards for sustained play, repeat play.

• Mini games/quiz to introduce variety, unlocked with a rally of game play. After a few successful rounds an on-screen game that requires verbal coordination between players to solve, for example each player gets a letter of an anagram, which one nominated player has to solve quickly.

• Mini games for individuals but where other players help (as in Crystal Maze)

• Why would someone play again? Have some progression, reward or incentive to play regularly, and a way to keep the game evolving.

Appendix 3: Technology

Technology possibilities for peer to peer networking without the internet

• Web based peer to peer solutions

• Bluetooth network

• Audio peer to peer network

Web based peer to peer networks

WebRTC is a possible peer to peer solution. This does rely on an established wireless LAN, but can neighbouring devices establish a simple Wifi TCP/IP LAN? Does not seem to work as it is missing a discovery mechanism.

Sharedrop.io as an example of local peer sharing over web, but this uses public web to initially identify you and your local neighbours, then acts on local traffic.

Bluetooth

Web bluetooth is poorly supported so far, and limited for devices, modes, so that’s a no-go

• Only BLE, no classic Bluetooth

• Only Central, no Peripheral

• One device at a time, no scanning (yet)

This is too limiting to be of practical use.

Full bluetooth protocols and roles are available for native applications, but I do not have the skills for this.

The user experience for joining with a bluetooth device is less slick than, joining a wireless network. This will be even harder with a peer to peer environment unless there are some middleware product that make this easier. I suspect there are security considerations as well.

Joe believes that some form of bluetooth based multiplayer mode exists for Unity and will investigate.

Audio based networking

There have been developments in peer to peer networks running over audio (in both audible and non audible ranges)

Google Nearby (now dropped by Google)

Near Bee extension to beacon star - gives proximity API to apps, but this is an industrial solution, not suitable for use in this situation.

Chirp provides an audio range peer to peer network. It is available as a library to web through web assembly. Functionality can be demonstrated in a sandbox setup. The pub environment is likely to be highly challenging for human-range audio. These environment can already be noisy, and competing simultaneous games might interfere with each other.