Wednesday, February 22, 2012

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.

No comments:

Post a Comment