Creation and Computation | Experiment 1
By: Catherine Reyto & Arshia Sobhan
Project Description
Road Hawgs is a two-team game which is played by using phones as physical pieces on the game field. Each team tries to pass its own finish line through obstacles on the field, trying to prevent the other team to succeed at the same time. In this game, phone displays are used as multi-dimensional game pieces, giving players access to all the tools they need in one place.
The core concept of this game is a group game-play using phones which are mostly considered as the reason behind the isolation of people in social contexts, even in a regular multi-player computer game where players are staring at their screens without any physical interaction. This game combines the groupness that exists in traditional board games with new possibilities that a mobile phone screen can provide as a game piece.
Project Context
We were both interested in the idea of people using their phones as tactile objects to physically connect with one another, but it took us a few iterations before we landed on the roadblock game.
Group game-play is reminiscent of childhood when structured social activities were routine and commonplace. We had this in mind – the act of people gathered around say, a puzzle or a board game – in considering how we would approach this experiment. We were interested in exploring what the experience of group games feels like: being lost in focus but with occasional bursts of bickering, cheering or laughter, competitive impulses, and most of all a strong sense of ‘togetherness’. We imagined a group leaned in shoulder-to-shoulder, far removed from the isolating tendencies that are typically associated with personal-use digital screens of any sort. We started thinking about the environments that tend to go hand-in-hand with group game-play: living-room floors, basement rec rooms, cottages, and eventually got to the idea of camping. This, in turn, led us to our first iteration of an image-matching concept. The idea involved the whole group ‘assembling’ a tent, (an image of one that is, with all 20 phone screens making up the canvas), working together to build it out piece-by-piece, not far off from the real-life experience of threading the poles hand-over-hand to set up a tent in the woods. And just like real camping, when the work is done and it’s time to kick back and enjoy the view (or at least, the fire), we were thinking of setting up all the laptop screens to mimic the experience by an emitted glow or panoramic image. But we were dissuaded by the technical challenges that the level of orchestration involved. It entailed either networking, which was ruled out, or a level of programming beyond our three weeks with p5.
We were still attached to the collaborative puzzle work of image-matching and spent the next session brainstorming. We were both drawn to visual patterns and the power of code to alter complex graphics into drastically new mosaic designs with just a few taps (or clicks). We really liked the idea of working with Islamic tile patterns, both on account of their captivating beauty but also because like code, the designs are grounded in maths principles. But like Jessie and Kaitlin discussed their scavenger hunt map, we anticipated that the variety of screen sizes would be too disruptive to the visual rhythm.
We also became increasingly aware of an overarching issue beyond screen-size interference. For the class to interact with the screens towards a common goal, we both felt a challenge was needed. Not simply for the sake of competition or upping the ante, but rather to continue with our ideas about group game-play. We wanted to see our classmates working together, sharing frustrations and accomplishments as they competed in large groups.
Figuring out our challenge led us through several iterations of wheel-spinning and creative frustration. We kept falling short of the target with concepts that were visually stimulating but too easily achieved, to the point of risking complacency. We frequently turned to the work of Artist and Designer Purin Panichphant for inspiration, eventually coming across the artwork that led us to the idea of matching Pieces. Panichphant’s Optical Maze Generator allowed us to make that final connection, though at first only in an abstract sense. As soon as we saw the maze and how it worked, it was unanimously agreed that we’d build our idea from it. We tapped around on the screen, rotating the squares of a grid of shape patterns, and began to visualize the idea of positioning parts of vertical and horizontal Pieces.
Designing the Game
A vision came to mind from the old version of the PC game Sim City (Will Wright, 1989). The game involves strategically building a metropolis on an allotted budget in order to grow the population and in turn, increase that budget to continue expansion and growth. One of the greatest satisfactions came from laying down Pieces of road pavement because it signified profit enough to invest in infrastructure.
We cut up several sheets of paper into phone screen-sized portions, then plotted out a system of match points (mid-width, mid-height, and all corners) for each screen. The shapes could be combined in many ways by simply rotating the sheets of paper to match connection points from one road piece to another. The strategic positioning of the road pieces was devised with the building blocks of Tetris (designed by Alexey Pajitnov) in mind: minimal variation (we used four shapes), relying greatly on rotation for combining point-to-point shape connections.
To create a bit of context and make the game more interesting, we threw in a few literal roadblocks, in the form of a river, a train passing and construction/road work. Each ‘blocker’ presented its own challenge: rivers need bridges to cross, as do trains, unless you choose to simply wait for the train to pass (miss a turn), and construction sites limit or alter your route. We added ‘relief’ pieces to the mix: a bridge for crossing the river and train tracks, and a ‘bribe’ to override the construction.
With our pieces laid out, we felt good about having everything we needed to make a game that was simple yet clever enough that we could imagine it actually being played outside the classroom, by kids and adults alike. We just needed to strategize the game rules, and quickly learned that there is nothing simple about that. Game design is a puzzle in itself, or a story with a definitive beginning, middle and end that needs to be a delicate balance of pain and gain points. We wanted to focus on the collective experience of the whole class but keep the element of competition a priority. To solve this, we divided the class into two large teams that would be pit against one another on the same road. The tricky part came in trying to decipher their common goal. Was it to gain more distance (finish line), or more points (flags)? We also had to keep the demo time in mind, which meant having to omit the luxury of a first-round trial run. A complex set of rules could make for a far more interesting game, but we were always aware of having to keep it at a basic level. We also added the factor of luck to the game by having a dice toss to determine the number of moves each team has in a turn.
The title of the game has a double meaning. According to Wikipedia, a road hog is a motorist who drives recklessly or inconsiderately, making it difficult for others to proceed safely or at a normal speed. Since the goal of the game is to be the first team to reach the finish line, the players will be placing pieces haphazardly, their strategy in selection curtailed by the pressure of the group (like the round-robin scenario in table-tennis). Because both teams are ‘building’ the same road, they are detrimentally dependent on one another to win, thus making a play on the term ‘hog’, as into hoard to oneself. That concept was inspired by the billiards game “9 Ball”, which takes a non-linear approach to win the game (rather than a cumulative tally of points).
Final Version of the Game
After discussing different scenarios, we finalized these rules for the game:
- Two teams are differentiated with two colours (team pink and team green)
- The teams build the same road in turns
- The number of moves in each turn is determined by a dice toss
- Each team has its own respective finish line (placed side by side).
- There are some obstacles in the field that prevent teams from going straight
- Each team can use as many blockers as they want to deter the other team
- When a team is blocked, they need to use a relief tool to get past the block
- Teams have to physically use their phones in the game. They rotate them when finding the desired direction of a road piece, and they stack one phone on top of another when using blockers and reliefs (ie. bridge over the river).
Blockers:
- Dynamite: Destroys the last three moves (road pieces)
- River: Blocks the road (“bridge” is needed to pass)
- Train: Blocks the road (“bridge” is needed to pass)
- Construction: limits the directions to continue (“bribe” can be used to pass through in any direction)
Reliefs:
- Bridge: to pass the river and the train
- Bribe: To pass through construction in any desired direction
Using p5 and Technical Challenges
As far as p5 was concerned, in spite of our limited knowledge, we were pretty good at communicating approach strategies. We caught one another if an idea seemed out of scope, and Arsh really stepped up when it came to tackling challenges like adding a swipe mechanism. The swipe was the fundamental feature needed for easy, intuitive game-play, as well as a great solution to simplifying our navigation. We aimed to keep every aspect of the game as minimal as possible because we anticipated the loss of time from explaining game rules in the demo.
After finalizing the tools, we designed a simple navigation system using tap and swipe. Players have three separate tabs: for road pieces, blockers and reliefs, that can be accessed by swiping left and right respectively. In each tab, they can then tap to toggle through subsets (ie. road shapes, blocker types). Although using tap was quite easily achieved using the event “touchStarted” and using variables to loop the toggle, the swipe function was not very straight forward. After some searching and testing, we finally used this example code from Shiffman incorporating hammer.js. It enables swipes in all four directions and worked properly on iOS and Android in all browsers. We only needed to make use of the left and right swipe to give access to blockers and reliefs, with road pieces being the default toolset on the home screen.
The dice toss was also executed in p5 using the shake gesture to mimic the gesture of a real-life dice toss. The only factor that was in need of some tweaking was the shake threshold (setShakeThreshold()). After a bit of ‘road’ testing, we finally settled on a threshold of 40. But for presentation’s sake, yes – Nick had a good point, a real die would have sufficed.
We felt a little restrained by our limited skill-level. There were plenty of cute extras we had to rule out, like small animals scurrying across the road pieces for idle animation. We were both eager to challenge ourselves with p5, but the time restrictions added a precarious element to our codebase. It was and still is apparent that we could do with some refactoring, as doing so would lead to a free playground for adding and experimenting. Because we were sharing the codebase, and some of the code had been pulled from elsewhere (the foundation of the Swipe feature was courtesy of Shiffman), that sometimes led to hesitation about tampering with one another’s code. But we also worked really well at overcoming issues in the code when we were able to sit down together to work through them.
Presentation Reflection
Presenting first meant it was really difficult to gauge how to make the best use of our time. Right off the bat, it was apparent that we had been too detailed in our projector-tutorial of the game rules. In hindsight, we’d have been pretty efficient in leading our classmates straight to the QR codes so there would be ample time for everyone to figure out the game as a hands-on trial run.
It was a painful oversight that we hadn’t thought to load the QR code for the die into one of our own phones before we started the game. We didn’t want to interrupt the flow of the lineups as we were weary about how much time we had left. This led to the call-out of ‘fake’ die rolls, the sort of on-the-spot thinking that happens in a worked-up presentation.
In spite of what became a bit of a chaotic moment, it was really satisfying to see the game successfully play out. We had anticipated that long start where the road needed to grow close enough to the finish line before the real fun of the game kicked in. In our own test-runs of the game, limited to just two phones, we were still able to see that we needed dispersed pain/pressure points in order to overcome that issue. We resolved that being master game-designers might take a few more iterations yet. But in the meantime, we had achieved what we had set out to do. We got to watch our classmates compete and cheer and laugh as they used their phones like blocks from a classic board game.
Code
https://github.com/cat8dog/roadHawgs
References
Shiffman. (n.d.). hammer.js swipe. Retrieved from p5.js Web Editor: https://editor.p5js.org/projects/HyEDRsPel
Hammer.js. (n.d.). Retrieved from Swipe Recognizer: http://hammerjs.github.io/recognizer-swipe/
Pajitnov, A. (1984, June 6). Tetris Analysis. Retrieved from http://cmugameresearchlibrary.pbworks.com/w/page/3984534/Tetris%20Analysis
Phanichphant, P. (n.d.). Experiments with P5.js. Retrieved from http://purin.co/Experiments-with-P5-js
Phanichphant, P. (n.d.). Optical Maze. Retrieved from http://p5js.site44.com/019/index.html
THE MARRIAGE OF DIGITAL AND ANALOG: THE FUTURE OF GAMING? (2016, November 11). Retrieved from https://cmon.com/news/the-marriage-of-digital-and-analog-the-future-of-gaming
Luke Stern, S. W. (2015). Game of Phones. Retrieved from https://boardgamegeek.com/boardgame/179701/game-phones
Wright, Will. (February 2, 1989) SimCity. DOS, Maxis