Greinasafn fyrir flokkinn: Phosom

Phosom

Project report done in a Game Design class at ITU.
Other versions of the report can be downloaded from the
Google Drive source document.

 

Phosom is a game, or a toy, based on image similarity, where players receive challenges in the form of a photograph, to which they respond to by either taking a picture or finding a picture from the web, and receive a score based on how visually similar the images are.  Creativity and visual memory are good skills to possess while coming up with an imitation of the given original, that may not have to represent the same motive as the original but rather be visually similar overall.  This kind of play offers the opportunity to perform the popular activities of creating or finding photographs, with a defined goal of similarity and rewards given according to performance within the frame defined by that goal.  Also it leads to thoughts about the originality of visual creations; is the original image the player is to imitate really original, or is it itself an imitation of something else, and can the imitation created by the player be considered as an original for imitation in some other context?

 

Motivation

Today people commonly carry a camera in their pocket at all times, embedded in their smartphone.  Photography in general is a very popular hobby.  Playing digital games on mobile devices is a fast growing form of entertainment that often is interweaved in everyday life, where people pick up a casual game during short and maybe random moments they have during the course of the day.  Combining those elements – readily available cameras, interest in photography and casual gaming – in a software toy-game, is a goal with Phosom.

The game allows players to connect with others, people they know or other random (anonymous) players, and challenge them with photographs and receive challenges back.  How to respond to those challenges offers much creativity when searching your everyday environment for motives that may give a good score when compared to the given challenge.  Play with this toy-game can then be “…viewed as…[a] potentially artistic [enterprise] capable of stimulating and releasing the creative components of the participant … that gives satisfaction to [her] creative imagination, nurtures the emotions, excites the soul, and satisfies the senses.”[1]  Phosom may thus give social value and develop personal skills.  Also it encourages people to explore their environment in a new and exciting manner where they may learn more about their surroundings in the process.

 

Design iterations

The design of Phosom as a toy to play with or even as a game, has gone through a few iterations and here is an account of what I consider to be the highlights of that process.

Initial idea

When taking a nap with my nine months old son last September (2013) the unrequested idea sprung up to create a mobile application that would allow a group of people, all present at the same (possibly large) location and each holding mobile devices running that app, to create an Internet connected game where the group would be divided into two teams in which each member would be assigned an opponent from the other team.  Everyone would be given the task to photograph a motive from their own choosing.  Having taken a picture, a team member sends it to his or her opponent, and then waits for a picture to be delivered from him in the same manner.  Having received a picture, a team member has to create a photograph, with his mobile device camera, that resembles the received picture as closely as possible, either by finding the motive his opponent photographed or by taking a visually similar picture in some creative way.  Each team member’s effort towards image similarity in this way is graded and the total grade earned within each team determines whether it won the game.

Although I was not actively seeking ideas while taking that nap, I did know that a game would have to be implemented as a final project in the Game Design course.  During the first days of the semester, we students were guided into group games like Ninja[2], to mingle, break ice and start us thinking about games.  That probably influenced the game setting described in the previous paragraph.  The required Internet connectivity of the game is also probably influenced by my fondness of the Internet as a technology and how it enables communication.

What about playful communication with photographs?  The act of comparing images within a game is an obvious result of the frequent use of image search engines and an app like Google Goggles[3].  Indeed there already exist mobile photo toys like Instagram and Snapchat, but competing at finding the most similar motive to the one given may be considered as something novel.

Taking that nap probably tuned the brain into an open mode[4] where it could be aflood with ideas[5] sourced from those influences and inspirations.

 

phosomimage01 phosomimage05

 Initial user interface sketches. Name ideas other than Phosom include PhotoKO and Phosimi.

 

Group brainstorming

All team members were enthusiastic about the basic idea of creating play involving photography, visual memory and interpretation.  Everyone also saw from their own angle what could be done with that core game mechanic[6] of playing with image comparison, and so in our discussions about what kinds of gameplay could be conceived based on that foundation, several different ideas were collected, into a Google Drive document and our Trello board.

 

Trello.com was used as an electronic Scrum wall to organise the tasks to do.
Trello.com was used as an electronic Scrum wall to organise the tasks to do.

 

The most discussed gameplay scenarios were one-on-one challenges and turn based group challenges, where players can either get automatically assigned photos, or create their own challenges by taking a picture or uploading one.  Other possible types of gameplay we discussed include a memory drawing game, where a drawing is shown for a limited time and the player is to draw it from memory and take a picture of it; art quiz where the player is shown a well known image and has to track it down on the net to submit as a response; a tourist guide in the form of photos from sites of interest, which players find and photograph to have the next location revealed (which could be offered as a white label product[7]).  Also we discussed the offering of different categories to play within, where challenge pictures could come from the chosen category, and bribery was even considered, where players could in some way bribe the system to get a better result, which lead to some discussion about ethics.

One of the more fascinating elements within the gameplay scenarios we discussed is the possibility of wordless communication between geographically distant players, as they go about their everyday lives and may at random moments spot interesting visual motives to respond to a challenge with, or create a new one[8].  That element of remote challenges is not present in the initial idea, which is basically about a toy (or a tool enabling play), for a group of people present at the same place at the same moment, to play with.  So here the idea was already on its way to evolve into something different.

 

We used a closed Google+ group for team communication.
We used a closed Google+ group for team communication.

 

Prototyping

From that collection of ideas, we settled on a bare minimum of features to implement initially, to get a first hands on feel for how it is playing with the act of coming up with an image that is supposed to be the most similar to another image that is given as a challenge.  This minimum consisted of enabling the player to ask for a challenge, that would be delivered as a random photograph from the Flickr image hosting service and the player would then perform a web search, within the game, to find the most similar picture.

Bare minimum of features to implement initially, marked in red on a flow diagram.
Bare minimum of features to implement initially, marked in red on a flow diagram.

 

As the initial idea is about taking pictures, to create something similar to a given image, the ability to search the web for images instead was only considered as a quick means to have something working, that would then be thrown away at later stages of development when a camera would be accessible from the game running on a mobile device.  Much to our surprise, casual playtesting with people we met in passing, indicated that the option to search the web to find images similar to the one given, was regarded as a pleasing game mechanic in itself, and the game could be based on that alone in a desktop environment, where a mobile camera is not an option[9].  More formal playtesting later on confirmed this, where players liked the option to either search for images on the web or to find a motive from their environment with the camera.

 

Results shown in the first prototype, with an image from a web search as a response to a random challenge photo from Flickr.
Results shown in the first prototype, with an image from a web search as a response to a random challenge photo from Flickr.

 

Even though this initial prototype was well received, with its limited offering of automatic challenges and web searches, we were still eager to try playing with the mechanic of taking pictures with a camera when given a photo to imitate.  When that ability was available in a further iterated prototype, it mostly added a new dimension to the gameplay that had been available until then, rather than changing it completely.  Indeed, it was more interesting to explore the environment for a similar motive and asking someone to pose in this or that way, that should be similar to what the picture being imitated showed.  This allowed for more social interaction within the present environment, than would been had by doing endless web searches, and that local interaction could be a good addition to the remote interaction discussed previously.

 

phosomimage07

Trying out the camera to respond to challenges in Phosom.
Trying out the camera to respond to challenges in Phosom.

 

Technical limitations masked by narrative

What became apparent in the first prototype with web searches and in later versions offering photography interaction, is the inferiority of the applied method of image comparison and the perceived uncertainty of how it works.  Players were confused about how their results were being evaluated and as a result they were not sure what they were looking for[10].  At least this was often the case the first few times a player took a challenge, but then he or she got a better feel for what worked and not.

Was this something to worry about or was this a part of learning how the game works?  This is a question we discussed quite a lot.  It was a concern regarding the playability of the game when players found the results they were given to be unfair.  A player might find the same object as in the given challenge photograph, but still get an aggravatingly low score because the overall tone and brightness of the image she produced was different.  In those cases she would be likely to throw the game away immediately and never play it again.

 

phosomimage08

Two of the worst examples of unfair scores, where the score 589 of 1000, and 632 of 1000, is given.
Two of the worst examples of unfair scores, where the score 589 of 1000, and 632 of 1000, is given.

 

Before we commenced with formal playtests we decided to use those technical limitations to our advantage and conceived a narrative that introduced a fictional character whose opinions would represent the evaluation of similarity.  Any possible peculiarity of the underlying image comparison method could be attributed to this character’s quirkiness.  We were quite happy with this solution, but still, playtesters who had in some cases not taken the time to familiarize themselves with our fictional character and her role in the mechanics of the game, were confused nonetheless.  From playtests we learned that the participants would have appreciated some kind of an introduction on how the images were being evaluated, so they would have a better idea of what they were about to do exactly.

 

We called the fictional character Phosie, that evaluates image similarity within the game.
We called the fictional character Phosie, that evaluates image similarity within the game.  Graphics by Anders Wiedemann.

 

Player passion

Apart from getting the highest score when comparing your image with another, what is your goal while playing with this toy-game?  This question lead to discussion about the possible metagaming[11] players could be involved in while interacting with the basic play offered by Phosom.  Given the positive feedback we received from the prototypes, where playtesters said that they would like to play this kind of a game, there seemed to be little doubt regarding the potential of the idea for a playable game.  But the question remained about how engaging the game could be, what would keep players coming back to it?

With that in mind, we thought about possible in-game values that players would compete to win the most of.  Typical representations of such values are coins or points, but I was most fond of using photo prints to represent those values, that players would collect to be able to take pictures.  Those prints I liked to call pholoroids, which players could win by coming up with an image that is more similar to a challenge than their competitors could produce.  To be able to take a picture, a player would have to possess a pholoroid, and each day he would be given a handful of them for a good start, that could lead him to win a whole pile of pholoroids, which could then enable him to send a picture as a challenge to a group of other players, where, in a sense, he would be putting them all at stake, possibly winning pholoroids from all the players in that group after all rounds had been taken, or possibly losing them all to another player within that group that performed better – in a high risk, high reward scenario.

 

Further development

After reflecting on the previously discussed design process and the collection of ideas, I have become to believe that all this is overly complex, adding layers of narrative and virtual game values, while the values gained directly from the core mechanic could be interesting enough and how the game works could be self-explanatory without words.  It could be more interesting to steer the development towards a minimalist game design, where “…self-imposed, deliberate constraints on both the design process and game are an important component to exploring new types of game and play” and “…these point to choosing a few powerful, evocative elements, and then exploring the design space they constitute” where “the goal is not just to strip away the unnecessary parts but to highlight and perfect the necessary elements”[12].

 

phosomimage09

 

~ vs ~

phosomimage04
Flow sketch of two possible ways to start the game, by first choosing what or whom to play with, then followed by a rather complex set of options. This can be simplified to the single option of taking a photograph that imitates another, but still there could be a rich set of goals to explore in that minimalist game design that would allow for a deep gameplay.

 

Collection of core game values as a metagame

Instead of virtual in-game values in the form of pholoroids, players could see to how many photos they have the most similar imitation, and they could decide whether this count of similarities is something they care about and if they want to compare it with what others playing the game have gained.  All images put into the game would be open to imitation by any player.

At one point in time you could have the most similar imitation of one photo, and thus in some sense own it, but then later on, someone else could do a better imitation of that photo and in the same sense win it from you.  Notifications could be delivered about those events, that might ignite competitive fires in a player who may decide to try and do a better imitation of that photo, to win it back, or he may decide to look at what other photos that competing player “owns” and try to win some of them from him.  And so on, back and forth.

As a player, you could care about collecting increasing numbers of best imitations, comparing your gain with that of all other players within the game, rising and falling through the ranks, or you could care more about narrowing the view of whom to compare with, seeing how your performance stacks up against that of in-game friends, who could be defined manually, by adding them in a “traditional” manner, or they could manifest organically as they decide to compete against you and vice versa.  Spontaneous social connections could be forming as everyone can compete against anyone, possibly imitating a photograph that was created to imitate another photograph, in an endless recursive spiral, forming a snowball of imitations that rolled out of the very first photograph initially added to the game; in a postmodern world[13] of endless imitation to explore, where players create the games they like with the mechanics offered by this photo toy-game.  Here we would have metagaming directly based on the core game loop and the values it creates[14].

The interface would be minimalistic, initially only showing the basic element around which the play turns; a photo, one at a time.  The photos could be navigated in a sequential order of popularity or by some other metric, such as location.  The photos with the most imitations would be considered the most popular – imitations as likes.  In the same way, players who have gotten the most imitations of their pictures would be considered the most popular.  Would the game then be about collecting the highest count of the best imitations, or to become the most imitated photographer?  Players decide, since “being playful is an activity of people, not of rules”[15].

No introduction would be provided, just that basic element covering the whole screen, and possibly not obvious interactions for the player to discover, as he taps, touches and swipes[16].  This type of interface is inspired by recent mobile apps such as Snapchat[17],Vine[18], Mindie[19] and Rando[20].  The player will see images with given scores, attached to the images they are imitating, and see the ability to take a picture.  Within that context a player should soon realise what she is looking for when taking a picture; the attached images with the highest score should make it instantly visible what works within the game.

Graphic design can make a game or a toy look beautiful, but it can be argued that it is not the reason why anyone likes to play with it, but rather the affordance[21] of play it offers, and maybe that should then be the most, or the only visible element.  That is at least one way to approach the design, that suits well a graphically challenged developer and seems now to be fashionable as the example apps mentioned here show.

Should the development of Phosom proceed in the spirit described here, I would then be taking it closer to that of a non-game mobile app, ignoring the elements that define games[22], or at least leaving their implementation up to the players, within the facilities provided.  This may be a natural progression, as it aligns well with my background as a traditional software and mobile app developer, with little gaming experience (I did finish Prince of Persia and all episodes of Commander Keen back in the days of DOS[23]!  -and I was the proud owner of an Atari 2600 Video Computer System[24]).  That background of skimpy gaming experience can indeed be considered as an asset[25] and that is a perspective I will try to embrace.

 

Technology

Phosom is a service dependent on a backend, implemented in Java, running on Google App Engine which offers an API using Google Cloud Endpoints.  The interface is implemented in HTML5 / JavaScript / CSS using the jQuery Mobile framework, for both the web and smartphone versions.  The mobile app versions are compiled with Apache Cordova, the open source engine behind PhoneGap, using the tooling support of NetBeans.  Images are stored and uploaded directly to Google Cloud Storage and their similarity is computed by a servlet, running on an Google Compute Engine instance, that currently uses the OpenIMAJ toolkit.

Image comparison methods

When first contemplating the feasibility of the idea of creating a game based on image similarity analysis, I searched for readily available libraries to handle the function of image comparison and settled on two libraries to try out:  LIRE[26] and OpenIMAJ[27].  Preliminary tests with those libraries indicated that some kind of play could be facilitated with the image comparison features they offer, computing distance vectors between images based on their histograms.

The fact that both those libraries are implemented in Java lead to Google App Engine for Java[28] being chosen as an environment for the backend.  With the development process under way it became apparent that those libraries could not be used within the Java Runtime Environment provided by App Engine, due to its sandbox restrictions[29].  The possibility of comparing the images on the (mobile device) client was explored, using JavaScript and the HTML5 canvas element[30], but the browser’s Same-origin policy[31] made that difficult when communicating between App Engine and Cloud Storage on different domains.

As a quick solution, a simple servlet using the OpenIMAJ library was created and run in the lightweight Winestone servlet container on a nano compute instance at GreenQloud[32].  The resources of that inexpensive instance are very low and so the image comparison took a long time to run.  After receiving a $2000 starter pack for the Google Cloud Platform[33], the image analysis servlet was moved to a more powerful and expensive Compute Engine instance, with a better response time as a result.  This starter pack, with its six month expiration time, is one motivation to continue the development of Phosom and see where it goes.

Patterns

Programming the backend I used a traditional object oriented approach, with object relationships in hierarchies, probably due to my software development background.  With that approach, the relatively simple model behind the game quickly became confusing and now I have learned that the Entity component system (ECS) design pattern is often regarded as a better fit when programming computer games[34].

For the future development of Phosom outlined above I would like to refactor the underlying data model, from being centered around a game entity to being focused on a photo entity instead, and in that process a move to ECS could be in order.  In that same process I would like to consider using hammer.js[35] instead of the jQuery Mobile UI framework currently in use, for the simplified, minimalistic user interactions I have in mind.

Source control

The client code is hosted in source control at:  https://github.com/bthj/Phosom-client

Code for the image analysis servlet is in source control at: https://github.com/bthj/phosom-image-analysis

The backend server code is at:  https://github.com/bthj/Phosom-server

 

Conclusion

Given the widespread use of mobile devices and interest in photography, across all demographics, an opportunity to play with a combination of those may be welcomed.  Phosom would not be the first opportunity to play with photography on mobile devices, but could provide a novel angle to approach that play from.  Also it can ignite philosophical thoughts about originality and authenticity, while players use their visual memory to scout their surroundings for reminiscent images.

 

The desktop prototype of Phosom can be played at:  http://phosom.nemur.net/

and the mobile prototype for Android can be downloaded at:  http://phosom.nemur.net/PhosomClient-debug.apk

 

 

IT University of Copenhagen
Game Design course – instructor:  Miguel Sicart
autumn 2013
Björn Þór Jónsson (bjrr@itu.dk)


[1] Klaus V. Meier:  An Affair of Flutes: An Appreciation of Play, p. 8 & 10.

[3] “Google Goggles is a downloadable image recognition application…”  http://en.wikipedia.org/wiki/Google_Goggles

[4] “…the open mode, is relaxed… expansive… less purposeful mode… in which we’re probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful.” – John Cleese on Creativity:  https://vimeo.com/89936101 , transcript: https://github.com/tjluoma/John-Cleese-on-Creativity/blob/master/Transcript.markdown

[5] When my brain decides it’s time for great ideas – The Oatmeal:  http://theoatmeal.com/pl/brain/ideas

[6] “Game mechanics are methods invoked by agents, designed for interaction with the game state.”  – Miguel Sicart: Defining Game Mechanics.  http://gamestudies.org/0802/articles/sicart

[7] “A white-label product…is…produced by one company…that other companies…rebrand to make it appear as if they made it.”  – http://en.wikipedia.org/wiki/White-label_product

[8] “In multiplayer games, other players are typically the primary source of conflict.”  “We like to see how we compare to others, whether it is in terms of skill, intelligence, strength, or just dumb luck.”  – Tracy Fullerton: Game design workshop, 2nd ed., p. 77 & 313.

[9] The playability of the desktop prototype was compared to that of GeoGuessr:http://geoguessr.com/

[10] “What does the player need to know?:  Where am I?  What are the challenges?  What can I do/what am I doing?  Am I winning or losing?  What can I do next/where can I go next?  – Miguel Sicart: “User Interface and Player Experience”, lecture slide in Game Design-E2013, ITU, Copenhagen, October 21:  http://itu.dk/people/miguel/Design_Lectures/UI.pdf#page=30

[11] “Metagaming is a broad term usually used to define any strategy, action or method used in a game which transcends a prescribed ruleset, uses external factors to affect the game, or goes beyond the supposed limits or environment set by the game.  Another definition refers to the game universe outside of the game itself.”  – http://en.wikipedia.org/wiki/Metagaming

[12] Andy Nealen et al.: Towards Minimalist Game Design, p. 1 & 2.

[13] „Authenticity is invaluable; originality is non-existent. And don’t bother concealing your thievery – celebrate it if you feel like it. In any case, always remember what Jean-Luc Godard said: “It’s not where you take things from – it’s where you take them to.”“ -Jim Jarmusch  http://www.goodreads.com/quotes/131591-nothing-is-original-steal-from-anywhere-that-resonates-with-inspiration

[14] “The metagame, essentially, refers to what everyone else is playing.” -Jeff Cunningham:  What is the Metagame?  https://www.wizards.com/magic/magazine/Article.aspx?x=mtgcom/academy/19

[15] Linda A. Hughes:  Beyond the Rules of the Game:  Why Are Rooie Rules Nice?  Annual Meetings of The Association for the Anthropological Study of Play (TAASP), Fort Worth, Texas, April, 1981, p. 189.

[16] “What challenges are developers and designers facing creating apps for touch devices after 30 years of ‘mouse and buttons’.”  Teaching Touch – Josh Clark:  http://www.youtube.com/watch?v=US_bznxIQPo

[17] “Snapchat is a photo messaging application.” – http://en.wikipedia.org/wiki/Snapchat

[18] “Vine enables its users to create and post short video clips.”  –http://en.wikipedia.org/wiki/Vine_(software)

[19] “Mindie is a new way to share life through music video…” – http://www.mindie.co/

[20] “Rando is an experimental photo exchange platform for people who like photography.”  http://rando.ustwo.se/

[21] “Affordances provide strong clues to the operations of things” – Donald A. Norman: The design of everyday things.

[22] “…we…identify seven elements in games:  1. Purpose or raison d’être  2. Procedures for action.  3.  Rules governing action.  4. Number of required players.  5. Roles of participant.  6. Participant interaction patterns.  7. Results or pay-off.”  – E. M. Avedon:  The Structural Elements of Games.

[23] “DOS, short for Disk Operating System…dominated the IBM PC compatible market between 1981 and 1995…”  http://en.wikipedia.org/wiki/DOS

[25] ““Students who know every game often have preconceptions about what games are … I have to find ways to make them see that games are an aesthetic form that hasn’t been exhausted. …[it] is sometimes more difficult than starting from scratch with someone who’s maybe a casual gamer or just curious“ – Faye”  – José P. Zagal, Amy Bruckman: Novices, Gamers, and Scholars: Exploring the Challenges of Teaching About Games.  http://gamestudies.org/0802/articles/zagal_bruckman

[27] Open Intelligent Multimedia Analysis toolkit for Java:  http://www.openimaj.org

[30] A basic image comparison algorithm using average hashes, implemented in JavaScript, was considered:  https://github.com/bitlyfied/js-image-similarity

[33] Google Cloud Platform Starter Pack:  https://cloud.google.com/developers/starterpack/

[34] When designing a game, an object-oriented approach may lead to “deep unnatural object hierarchies with lots of overridden methods” – “Anatomy of a knockout”  http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/

[35] Hammer.js – A javascript library for multi-touch gestures:  http://eightmedia.github.io/hammer.js/