Makahiki Administration and Gamification: Will It Blend?

As a student preparing for an Honors Upper Division undergraduate project, my eventual goal is to create an application or add-on that is integrated with Makahiki and simplifies the process of designing a competition. Initially, it seemed like a good idea to work on a limited demonstration version of this as part of my serious games project. However, the main limitation of a serious games project to teach people how to use an application is that it can offer only badges and the promise of better productivity, as the “reward” comes from learning how to use the application’s features.

Though addons like Microsoft’s Ribbon Hero (2010) and Visual Studio Achievements (2012) do exist, their main method of gamification is awarding badges and points for the completion of arbitrary tasks. In the case of Visual Studio Achievements, the user receives little guidance on how to use Visual Studio to complete the achievements, and many, like “Job Security,” are clearly intended as jokes. Many of the achievements seem unconnected to each other apart from dealing with the same tools, and recognize only that you’ve done some task a certain number of times. In this, they resemble their Xbox Live achievement predecessors. (Ars Technica reviewed it as a “text adventure game” here.) Learning new features piecemeal can be useful, but it does not seem as if this approach leads the user to develop knowledge of how to put together an example project in Microsoft Azure, Visual Basic, or any of the other tools and languages it offers achievements for. Thus the user learns how to do many things but is left to his or her own devices to figure out how it all fits together.

Some serious, some not.

Above: On the one hand, some enterprise projects probably meet these requirements anyway. On the other hand, I would like to see a specially constructed joke project that completes every achievement at once. Screenshot from the download site.

A more useful model for me to follow is the CodeSchool GitHub tutorial. This has very minimal gamification (there’s really only a progress bar and a CodeSchool badge), but at the end of it, the user has a functioning GitHub repository and has been shown how all of the Git terminal commands fit together to create and maintain that remote repository. Since a programming or application tutorial can’t really offer anything more meaningful than badges, achievements and points as a reward, I believe that its “hook” should be the promise of getting a simple application or "Hello World" project working.

The CodeSchool GitHub tutorial.

Above: CodeSchool’s GitHub tutorial has a progress bar and social media integration (not shown), but not much else that is "gamified."

My goal for this project is to create an “overlay” for Makahiki’s administrator interface that is similar to the points bar that appears at the top of the page during normal gameplay. This bar would track completed tasks (listed as “achievements” or badges), contain instructions for one or more possible tasks yet to be completed in a collapsible <div> or a popup window, and contain an option to reset the database to its original settings and start over. Once I figure out how to save player configuration settings to separate Makahiki database tables and restore settings from them, it would allow multiple users to try to put together a configuration (though I do not think a single Heroku instance could handle multiple people trying to configure it at the same time). Assuming that configuration settings are stored somewhere in the Makahiki database, it should be possible to create additional tables that contain pointers to different users’ configuration settings and load them when an administrative user logs in to the demonstration instance.

A simple mockup.

Above: A mockup of the “setup game” interface. It is intended to resemble the “Quests” menu that appears during Kukui Cup competition to help out the player.

A major problem with gamifying the configuration of a server application and attempting to host it on Heroku is that each Heroku project can only run one instance of the server at a time, and extended use of multiple Heroku applications is likely to exceed the monthly free 750-hour limit. Client-side applications like Visual Studio do not have this problem. So though the Makahiki gamified demonstration server could in theory maintain multiple configurations and switch between them, only one user would be able to work on the server at a time without causing potential conflicts. However, this problem would not exist for a locally run demonstration server, which only a single user would use at any given time anyway.

Of course, the Makahiki configuration unit has not started yet. I should know much more about the difficulties of installing and configuring Makahiki from scratch by next week. This will help me figure out what goals are manageable within the span of the project deadlines. In the short term, I would settle for implementing a button to reset the server from within the administration interface, and getting the overlay toolbar to display properly. Tracking the login credentials and configuration progress of multiple users will come later, depending on how feasible it turns out to be.