New map games

A bunch of things are emerging, both in terms of online map games (OMG!) and research that look at what these creations have to offer. Some of the more interesting example from my own navigation is MapAttack from Geoloqi, and the new Google Maps promo game. Both offer some entertainment and fun, although I must say that I quickly stopped thinking about the real places when I played cube, and just treated it as a marble board with obstacles. On the research horizon I recently found one of the first journal papers reporting from the geospatial domain by Alenka Poplin in Hamburg who looks at the potential uses of online serious games for public participation in urban planning.

April fool's quest

April fool's weekend is over and I will admit that I fell for one of the jokes, the Google Maps Quest (see Brett Molina's USA Today report here including links to some funny landmarks). The regular interface was mysteriously appended with a Quest layer when I launched it on Saturday morning. Being a GeoGame evangelist I was obviously overexcited to see this playful addition to Google's services and started to look around for clues on how to play/use it. Some time later I realized my embarrassment but it was a fun joke, see this YouTube video. Although, as readers of this blog will know, I do not usually joke around when it comes to online map games (OMG!)  If you missed it you can still look around in the Quest mode here. We stay tuned for Google's next step into the OMG! world.

Social network charrettes

Brian Berry notes in his ArcNews commentary entitled "Quo Vadimus?" (where are we going), that the millennial generation is among a growing segment of US Internet users who play games on social network, and that the geospatial community has yet to realize the potential of social games for addressing real world issues. He points at an interesting parallel with the 'charrettes' that designers/planners frequently use find participatory solutions to scenarios with conflicting goals and trade-offs. I elaborated on that very theme earlier this year under the title GIS + Games = GeoDesign. It's great to see more people recognize the power of new dynamics afforded by the use of emerging technologies and constant connectivity. Thanks to colleague Yuri Medvedkov for alerting me to the article.

Where Are the Great Location Based Games?

In his column David Daw at PC World Magazine rightfully asks the question "Where Are the Great Location Based Games?". Pointing to the most exciting examples of today such as Shadow Cities he concludes that game producers seem reluctant to leave their traditional game mechanic where place is mostly a backdrop for the action. To make location based games worthwhile, he argues, these games need to make location and place a central or at least important part of the game dynamics. i couldn't agree more. While I don't see our idea of GeoGames/OMG! (and that's short for Online Map Games) to be squarely defined as a location based game, it is certainly allowing (real) places have an important influence on the game. While we can proudly brag that we have our new fully WebGIS-based test architecture in place now (sorry, we'll have to wait a bit to release this to a wider audience) we are also increasingly aware of the difficulties in dealing with a game world fully anchored in reality. Yes, the world is not fair, some places have certain advantages that are hard to get around. Maybe playing these real world games will only generate Mirror Worlds. Wouldn't that be intriguing, and scary?

GeoGame development update by Kiril Vatev

Graduate student Kiril Vatev gives an overview of the development of our new GeoGame prototype:

The Cyberlearning GeoGame project is reaching the Milestone 1 stage of its development -- a fully functional online prototype. Being one short month away from a Milestone 1 demo, I can think of no better time to go behind the scenes of the development of the project and look at the technology that enables this online game.

I head the small development team and have played a large part in designing the framework for the game. Since I do not have a computer science background, the technologies we have picked are easy to learn and accessible without the need for technical training. For this blog entry, I will keep the content general and friendly, with just enough technical attributes included where completely necessary.

To understand the switch from a native computer application to an online application for the game, it is important to note the troublesome areas of native applications. Unless developed completely from scratch and compiled for specific systems, native applications will always require a runtime library -- be it the JRE (Java Runtime Library) or .NET, or any of the other libraries. These libraries make application less accessible for users, raise major compatibility issues, and present various hurdles in installation and distribution for end users. And speaking of distribution, a native application presents administrative issues when being used in a classroom setting. In a lab, each computer will require an install of the application by an authorized system administrator, and each consequential update of the software will require administrator involvement. Aside from the general pain this causes in the process, this results in slower distribution systems and a revert back to older development models based on major-version releases.

Finally, the last problem this project faced with its native application was the lack of integration. The map used in the application was used only as a backdrop of the game -- like a board -- and was not the interactive element of the application. Interaction was done through a grid overlay on the map, effectively making the map itself a decoration on the game board, rather than an active element.

An online application presents an entire paradigm shift from the described problems of native applications. Everything exists in the cloud, and that solves the first two. Since our targeted end-users already do much of their daily tasks online, from email to social networks to academic research, so we can expect them to have a modern Internet browser. In fact, all of you reading this blog entry already have the necessary system requirements to play the game. The online application also boosts the application maintainability. Updating the entire end-user base is as simple as one click from me. Small feature releases, performance improvements, UI changes, hot fixes, and security tweaks can all be released to the public as soon as they are finished, and do not have to sit dormant until an entire major release is completed. Many popular web application, on average, perform 40 minor deployments daily, and we could easily do the same.

The last problem presented above, similar to its causation, can be solved by the technologies selected for the project. The map is a very important part -- if not the most important part -- of a geogame, and in this new version, we wanted to put the map front and center, in its full glory. Since “generic” map services, like Google Maps, Bing Maps, OpenStreetMap, NASA’s JPL map -- and as you can imagine, this list goes on and on -- are more or less zoomable static maps with a very low degree of customizability, and we happen to be geographers that have access to all kinds of data, the most obvious technology decision for this project is ArcGIS 10 Server. Without saying, this software can take the desktop maps we use daily and host them online as web services. However, what it also provides is a web interface for standard GIS geoprocessing capabilities, as well as a JavaScript API that allows full interaction and manipulation of all of the map’s data layers from within any web page or application. Not only is this a great solution for this project, but it is fitting for any application involving online GIS.

However, a robust map is not the only thing that a game needs. The next step is having a game engine. Typical game engines handle multi-user interaction and enforce game rules; in the background, they also render an interface, handle networking, threading, and memory management, and manipulate the game data. Unsurprisingly, this is also the definition of any web server, and therefore, we had plenty of options. And best of all, most web server platforms already handle all of the background tasks. That was easy.

Next, we knew we wanted something that would make our lives a lot easier when developing the game -- even without manually handling networking and memory management, this is still a big task. Quickly, we identified the need for an MVC architecture. MVC stands for model-view-controller. In simplest terms, this architecture breaks down a large application into small and intuitive parts, and provides the necessary framework to put those parts together into one application without the developer’s involvement. Models are where data management is handled, and these tend to be the easiest parts, as there is usually very little code written -- most MVC frameworks use visual models and generate the code for you. Views are what the user sees -- the user interface -- but with a twist. MVC frameworks can create “smart” views which dynamically adapt to the specific user while they are still on the server, and the user is served an optimized version of that user interface. These can be as easy or as complicated as you need them to be. Views are also convenient in that they allow any client-side technology to be used, which means that our application will play nice with Internet sensations like HTML5 and jQuery. Finally, controllers are the brains of the application. These sections handle the game logic and enforce the rules, but there will be more on this later.

Since we already needed to run a Windows Server for the application GIS, the obvious choice for our development platform was ASP.NET, which conveniently enough comes with a great MVC architecture. ASP.NET uses C# as its server-side language, which is easy to learn and provides a friendly environment even for a beginner.

For the final blow of this knock-out decision to develop the GeoGame as an online application, we had to provide a native-application level experience inside a browser: two-step process involving full user-interaction with all game and page elements and a single, asynchronous action page. The former, as alluded to before, is addressed by the use of the modern web technologies of HTML5 and jQuery -- both are technologies that sound much harder to learn and use than they really are. The latter part would prove to be: asynchronous web applications are easy to create using AJAX, but effectively handling AJAX calls on the server side is a different ball game entirely.

Enter REST. REST stands for Representational State Transfer, which is really a fancy way of saying “generic single-service endpoints which passively wait for generic standardized instructions.” That is a mouthful, so let me explain:

Consider a lemonade stand. Among its numerous attributes, a lemonade stand is simple, does one specific, focused thing, only takes a few ingredients, it’s independent from things outside the stand, and mostly sits idle waiting for customers. This is much the same way in which a RESTful application works. To enforce game rules and actions, you can write many small pieces -- the stands -- which require a user to provide a specific thing -- money -- and return a specific, predefined thing -- lemonade. In a web application, these actions can be anything, from a request for a specific piece of data, to a parcel click action, to a purchase within the game. This is not only user-friendly, but it is developer friendly, as it breaks up a large and daunting application into very manageable small pieces. Best of all, REST is both built into ArcGIS 10 Server, and is natively supported in ASP.NET MVC. Remember the controllers I mentioned earlier? They are back. The controllers house all of these REST endpoints, and MVC already has very easy tools to map simple and intuitive URLs to each REST endpoint -- don’t worry, these are handles in bulk, and you do not need to map each endpoint by hand.

I hope that this has given you an enticing first look at the new and improved GeoGame, and I am very excited to showcase the prototype when all of the final touches are in place.

GeoGames for research on land use change in Cyprus (Guest blogger: David Massey)

This is David Massey, a MA student of Ola Ahlqvist here at Ohio State, guest blogging about my upcoming presentation at the AAG conference later this month.   

This past summer I was in the eastern Mediterranean on the island of Cyprus working fulfilling my GIS duties on the Athienou Archaeological Project, but also doing field work for my MA thesis which involves using games to simulate data and examine land use change. 

Researchers have long examined the causes of land use and land cover change through the use of Cellular Automata (CA), Agent-Based Models (ABM), or Multi-Agent Simulations (MAS).   In particular, MAS are useful because the agents in a simulation can resemble the actual interactions and decision making processes of people in stakeholder positions.   Most notably, CIRAD researchers have conducted several participatory modeling projects that incorporate stakeholders into all stages of model development in order to understand complex environments in the form of a game (e.g. see Bousquet et al.2007; Castella et al. 2007). 

Games have been used by researchers in many disciplines, but as demonstrated by the Green Revolution Geo-Game, it is increasingly possible use design games with GIS to incorporate real-world geographic locations and to play out hypothetical scenarios.  Several conferences are now devoted entirely to games, including the Games + Learning + Society conference, and the smaller ThatCamp Games “un-conference”.  

Having individuals play a game to simulate data very similar to using Agent Base Modeling or Monte Carlo simulations, but in my opinion, more accurate because the key stakeholders are making decisions and acting, not necessarily based on rational or logical algorithms, but on how they would react in real life.

My research focuses on agriculture in Athienou, a village located in the UN Buffer Zone in Cyprus.  As a result of the 1974 Turkish invasion, Athienou lost nearly all of its farmland and the local farmers were forced to develop new farming strategies.  Today, Athienou is dominated by dairy, chicken, and cereal farms but land ownership issues due to the invasion remain at hotly contested issue, as seen in recent highprofile court cases.

I followed the Companion Modeling (ComMod) approach developed by CIRAD researchers for this case study.  This methodology involves a cyclical progression of field work, modeling, and simulation with the stakeholders.   Accordingly, first, I established the “rules” for farming in this region though background research and from conducting interviews with Greek-Cypriot farmers from Athienou.  Following examples from other ComMod research, I developed these rules into a role playing game (RPG), a tool which also represents the conceptual model of the agricultural system.  

My research question involved simulating a scenario in which the Turkish Occupied land to the north of Athienou becomes available for farming again.  This question was used in two ways.  

I had the Greek-Cypriot farmers who helped establish the rules, also play the RPG to see how they would develop the land.  Then I had undergraduate students play the RPG to see how they would develop the land.   This created two outcomes based on different types of knowledge about the agricultural system.  In this study, I used “expert” and “non-expert” to refer to specific types of knowledge about a system.  Here, the Greek-Cypriot farmers are the “experts” because they provide the (insider) native perspective of farming in Athienou.  The undergraduate students are “non-experts” because they bring their own outsider non-native observations and understandings farming in Athienou.

So, the purpose of the simulation was to first, determine how the Greek-Cypriot farmers would indeed develop their land, and second, in surveying the gaming strategies and results from both the “expert” and “non-expert” outcomes, examine ways to potentially crowd-source information.

I’ll be presenting on Sunday the 26^th at 10:00am in JenniferMiller’s session ‘Using Spatially Explicit Simulated Data for Modeling and Geovisualization’.

To see more about what I research, check out my academia.edu page!

GIS + Games = GeoDesign

Rambles playing board. Source: Library of Congress
http://lcweb2.loc.gov/service/pnp/pga/03200/03272v.jpg

With the GeoDesign 2012 meeting underway I find it timely to bring in some reflections on how GeoGames = GIS + Games can bring some solutions to the GeoDesign table. Much of this is drawn from a longer article in the journal Cartography and Geographic Information Science.

According to Ahmed Abukhater of ESRI and Doug Walker of Placeways (2010) The GeoDesign framework includes at least four elements; Sketching of potential plans and designs, Spatial models that can simulate impacts of proposed designs, Rapid feedback on the effects of any proposed/sketched design, and Iteration through several alternative designs. A combination of GIS, cartographic, and design software could probably deliver this functionality but it would be a hard task to integrate all three.

Some game software, on the other hand, already integrate all four of the GeoDesign elements. The game-map editors with typed libraries of objects support the sketching and spatial modeling of elements, constructed maps can immediately be tested by players and provide rapid feedback on any suggested edits, and alternative worlds can easily be saved and tested separately to allow for iteration through alternative designs. In addition to this, many game platforms also support massive multi-player support that can open for broad public participatory approaches.

Cartography has not elaborated that much on maps and map-making of entirely imaginary worlds, despite some early recognition of a more design-oriented cartography in the analytical cartography literature during the 80s and 90s (see e.g. Moellering 1980; Nyerges 1991). But despite the emergence of Geovisualization, digital landscape modeling for scenario-building was mostly found in the landscape architecture and environmental planning fields. Also, cartographers and landscape architects have somehow approached design from an expert-oriented perspective, rarely putting people in the middle of the process, nor tapping fully into the energy and creativity of an engaged public. VGI has been a radical shift in this direction but existing geospatial platforms still seems to be lacking in ability to leverage that power.

In contrast, the online gaming communities are in many ways founded on a people-centered approach, with wikis for sharing experiences and tips, social knowledge construction as a central process, and open platforms for user contributions to code and design ideas. These social and technological infrastructures that support online gaming could very well be tapped into by GeoDesigners by switching out the virtual game worlds for real worlds using existing spatial data. Some of the concerns around VGI not being authoritative also becomes moot when we consider it for future visions. Who is to judge what is the right vision for the future? We all have a stake, and forming that vision together globally will be very powerful.