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!