Category Archives: Gamification

Spring 2014 Recap

In Spring 2014, my final semester at the University of Hawaiʻi at Mānoa, I completed my undergraduate project, worked as a teaching assistant for an introductory cybersecurity course, and completed my undergraduate degree.

1. ICS Security Assistant: ICS 425, Cybersecurity and Ethics I

As a teaching assistant to Professor Barbara Endicott-Popovsky of the University of Washington, I supported the teaching of the course by posting and grading assignments, responding to student concerns, and managing student peer evaluations and weekly discussions of current events in cybersecurity. I had taken this course one year ago in the Spring 2013 semester, which prepared me well to communicate the course material to students this year.

Meetings with the professor to plot the course of the lessons, appraise my performance, and address student concerns occurred once a week, usually by phone.

This was a distance learning course, so I did not have set office hours. All discussion and communication with students occurred through email or forums managed on Laulima, a collaboration system for the University of Hawaii that is built on the Sakai platform.

2. ICS Undergraduate Project, Part 3: Spring 2014

As in the previous semester, my responsibilities as a member of the Collaborative Software Development Laboratory were to maintain the documentation for the Ubuntu, CentOS, and Vagrant installation methods, and to maintain the Vagrant provisioning script and its supporting files.

Resolving Compatibility Issues for Makahiki Dependencies

The release of pip 1.5 on New Year’s Day 2014 temporarily broke the Vagrant provisioning script (the bash shell script mentioned in previous posts). Makahiki was, and as of August 2014 still is, dependent on several external, unverified Python packages, including the libraries services for Django, PIL, NewRelic, Sphinx, and Markdown.

After changing the provisioning script to use setuptools-0.8 for compatibility with pip 1.5.x, I ran through the Ubuntu virtual machine installation process several times to determine which pip-installed packages needed to be flagged with “allow-external” or –allow-unverified” to be installed. The pull request describing the proposed changes can be seen here.

The development team decided that it was simpler to remain on the last known compatible version, pip 1.4.1, so I reverted the changes in my code and changed the documentation to install that older version instead (see GitHub pull request 592). However, the modified pip commands were needed to pass the CSDL’s Travis CI testing, which built the software using the newest version of pip (see GitHub pull request 603).

In early January, the sequence of commands used to install the Python Software Collections Library (SCL) stopped installing Python 2.7.3, and stopped installing correctly on i386-architecture CentOS virtual machines. This was the result of the maintainer of the SCL switching to Python 2.7.5 and ending support for i386 architectures.

At the time, Makahiki on CentOS required Python 2.7.3. To enforce this version requirement, I revised the installation process to compile and install Python 2.7.3 from source code after installing development packages. This was based on my previous work on the now-deprecated Python installation scripts for Ubuntu and CentOS, which had also compiled and installed Python 2.7.3 from source code. These changes were applied to Makahiki in March 2014 (see GitHub issue 586).

Towards the end of January, I was also a Smart Grid Game administrator for the 2014 Kukui Cup, a sustainability and alternative energy educational game supported by the Makahiki and WattDepot software. As an administrator, I was responsible for evaluating and scoring submissions for the activities and questions which students completed and submitted through the Makahiki Smart Grid Game module.

In late February, we were able to remove the VirtualBox version warning from the documentation after tests with Virtualbox 4.3.8 demonstrated that the bugs caused by VirtualBox 4.3.0 had been fixed (see GitHub pull request 603).

Though some work was done on the alternate configuration user interface, I spent March through May working on completing the data analysis and undergraduate thesis writeup for my Honors Upper Division project.

Conclusion of the Honors Upper Division Project

My undergraduate research was presented at the 2014 Spring Symposium, held on May 8, 2014. The undergraduate thesis was submitted to the Computer Science department and the Honors Department. Links to full versions of each document are provided below:

The main insight gained from the usability testing was that the Vagrant installation method that I had developed represented a significant time savings over the manual installation method, cutting over an hour from the average setup and configuration time. This was accomplished by using a single, default Ubuntu 12.04 LTS virtual machine as the environment for Makahiki, which enabled the installation of software packages and replacement of configuration files to be automated in Vagrant. This reduced the need for OS-specific installation steps, since all users of a Vagrant installation would be installing Makahiki onto the same virtual machine. The usability testing also helped to indicate areas of the documentation which were difficult to understand or likely to cause user error, and these areas were cleaned up after the study had been finished.

I received my B.S. in Computer Science with Honors from the University of Hawaiʻi at Mānoa, graduating on May 17.

3. The George Washington University

After a successful application to The George Washington University’s Cybersecurity in Computer Science master’s degree program, I am preparing to begin my studies at the end of this month. I was fortunate to be awarded a CyberCorps scholarship, and I am looking forward to experiencing the unique opportunities for academic and professional development that are available at the university.

Developing a Serious Game Application Part 2 – A Project Postmortem

Project Status and Future Development Goals

The project’s Github project page can be found at jtakayama.github.io/ics691-setupbooster/.

a25_landing_page

Among other issues, there were problems replacing the logo.

In many respects, this project did not go as planned. Several tasks ran overtime, several other long-term projects competed for my attention, and even when modifications to Makahiki did partially work, it was a challenge to figure out where exactly some components of each page were being loaded from.

a25_new_theme_blue

Above: The new theme uses blue and gray to match the logo, and to go for a more technological-looking background. However, theme changes do not seem to apply to Settings pages.


In terms of cosmetic changes, I switched the default theme to a customized blue-gray-white theme, created a custom set of default teams, users, and profiles to be used to initialize the database, and reworked the landing page and About page to describe SetupBooster instead of the Kukui Cup.
A gray page.

Above: The new “About” page.


So far, I have been unable to implement the article-creation and article-editing workflows. Non-functional widgets for creating articles, viewing a user’s average rating over all articles, and viewing user status information were created and are located on the user profile page.

The article creation widget.

The article widget, currently not functional.


The article creation widget currently writes an entry to the database, but there is no function implemented to retrieve the entry, and it does not have a corresponding editable, static page file.
rendering_glitch
The average_rating and player_status widgets are currently rendering in the same position due to a bug resulting from a conflict with a default Makahiki widget of priority 3 that has been disabled; the average_rating widget has priority 3 and the player_status widget has priority 4.

The primary future implementation goal is getting the article model to function correctly, since it is the central piece of the site. Once article pages can be rendered correctly for viewing and editing, the rest of the modules should be easy to integrate. Assuming each article can be identified by a unique ID and a revision number, creating view_article and edit_article widgets and passing them some variables to retrieve page content should be relatively easy.

Lesson 1: Gamification Benefits From a Clear End Goal

An issue I ran into when designing content for my software guides site “game” was that a site that exists to host user-generated content potentially indefinitely can be difficult to gamify. Competitions like the Kukui Cup or gamified personal challenges like World Without Oil ask players to make commitments and carry out actions within a specific time period. This allows the game designer to structure the experience by introducing levels, scaling difficulty, multiple rounds of prize giveaways, and constructing a narrative (if applicable). Other gamified concepts (fitness goal monitoring sites, social sites that measure TV viewing) can work for an indefinite amount of time because they can be driven by the user’s desire to achieve something or earn recognition for something of personal value. The gamified system can provide structure and incentives for the user, but in those situations, the user sets the timetable.

The new user groupings.

In SetupBooster, the teams don’t really serve as a means of organizing competitors against each other: they just distinguish between different types of users. In theory this could be done without teams completely (since Makahiki has superusers and non-superusers) but using the teams functionality could allow for additional “teams,” like temporarily banned users or more limited kinds of administrators.

In the case of the wiki / document-sharing site I planned for SetupBooster to eventually become, the issue is that the wiki model runs indefinitely, but individual users don’t really have a personal stake in the site unless they become popular or become administrators – both things that are determined by the community, not the software. A training game might help people get over the initial hurdles of editing a wiki. However, beyond this point, having users define the content of the wiki makes it difficult to create defined categories of prizes or activities.

In this situation, I think that only thing the wiki can reward are generalized measurements of activity: article creation, adding editors, making lots of comments, editing frequently, and similar statistics. Absent some kind of external prize, the wiki game eventually will become a long grind like parody games Progress Quest or Achievement Unlocked, with new badges and recognitions doled out every so many completed tasks. Arguably the content of the wiki could be the major selling point if the writers are good enough, but if that is the case, than the gamification really isn’t making much difference beyond lowering the barrier to entry.

Lesson 2: Don’t Work Alone If You Can Help It

As I stated in earlier posts, I had originally planned to work alone because I thought the final project would be more similar to my upcoming undergraduate project. (In retrospect, knowing what I know now about the process of modifying Makahiki, that would probably have been even more difficult.) All conflicts over scheduling and creative vision aside, the main reason to work in teams if you can – especially for students with heavy courseloads, long work hours, or other responsibilities – is that having more people working on the project increases the odds that at least one person will be able to work on something on any given night. It was too often the case that I was unable to put in much work on the project for days at a time. The tendency in such cases is to prioritize the things that are due earlier, which resulted in a Github commit pattern that bunched up noticeably just before major deadlines.

Teammates, if they care about deadlines, will pester each other to get the project done on schedule: this was the case with another team project I was working on for a cybersecurity class last week, and I believe it to be true of functional team projects in general. For more complex software projects, working alone and being responsible for the entire design of the system makes planning more difficult than for team projects, where each person can take a piece of the structure and work on it. On the other hand, breaking up a project can cause implementation problems if the different pieces don’t have the same gameplay style, access shared data in different and incompatible ways, or just end up not working because one piece of the puzzle is missing or late. Though I was working alone, I could work knowing that, for better or worse, all the pieces of the system were my responsibility to modify and I didn’t need to meet with someone to get part of the problem fixed.

Lesson 3: Documenting Your Code Is Valuable (even if you don’t have to)

Though Github’s Project Pages feature turned out to be easy to pick up, the process of documenting the vague flowcharts and lists I had created in earlier phases of the project was not. Being forced to describe the content of the game in detail caused me to realize some potential limitations of applying gamification to a wiki-like site, and to try to think more carefully about what kinds of integration I might be able to create between the tutorial game and the wiki interface. More importantly, it probably resulted in me having more of a product to show for my efforts than if I had just continued being stuck on resolving lower-level issues with the article model. Though in both cases I did not accomplish most of my initial implementation goals, having documentation to provide a blueprint for future progress increases the odds that I might be able to continue working on the project or come back to it later, rather than abandoning it because I ultimately had no idea where it would be going after the course was finished. Though there were several issues I was unable to resolve, having documented the plan for the final application refocused me on the larger goals of the project.

Developing a Serious Game Application – Part 1

Summary

Development of the serious game application has hit a roadblock due to problems in creating a valid Model representation of a text-only wiki article that are preventing the Makahiki database from being initialized. Once this problem is fixed, being able to perform standard Django database operations on the Articles should allow other standard pseudo-wiki-like features like article searches or revision management to be implemented to some degree.

False Starts: django-wiki

In my previous post on this project, I had been considering trying to incorporate modules from benjaoming’s django-wiki project into Makahiki. The problem with this approach is that it would essentially amount to taking an existing, full-fledged web application with its own authentication system and trying to link this system to Makahiki’s user database. At best, Makahiki would end up serving as a glorified login screen, with its widgets needing to pull from the external wiki database and integrate this with Makahiki’s database. While the django-wiki package appears to be a useful Django add-on, it did not seem as if it lent itself well to gamified integration with Makahiki in the limited development time I had.

The Article Model

The Article model, in its present, incomplete state, does not actually create an article that the user can edit. Rather, it stores metadata about the article – title, which editors can work on it, etc. – in the database. Since it seems impractical to store a hypothetical article (possibly with embedded images in a future iteration of the project) as a text field in a database, the goal is eventually to store a link to the actual article file as a field of the Article model. The database could then be queried to retrieve all revisions of the article (revision number is another field), and links to the article as generated by Django would point to the latest version. At present, Makahiki’s initialize_instance.py script cannot initialize the database because the error TypeError: __init__() got an unexpected keyword argument ‘required’ is preventing the Article model from being validated, so it is likely that an attempt to upload the application to Heroku in its present state would also fail. Oddly enough, the initialize_instance.py script worked once and produced this error only after I navigated to the Profile page; on the second use of initialize_instance.py, the script failed to complete its run and displayed the same error.

A TypeError.

The database was able to initialize once with the Article model, but this error appeared on the Profile page. The next use of initialize_instance.py failed to initialize the database completely, with the same error.

Implementing New Models

The practice of creating and being able to revise an article is very different from what Makahiki is currently designed to do: it is equipped to measure and reward user-generated actions and content, but naturally it is not possible for users to substantially alter the site. Now that I have a better understanding of the work that needs to be done to incorporate articles into the database, the greatest potential problem is the likelihood that most of the work over the remaining two weeks will need to go towards back-end, pseudo-wiki-implementing code, rather than into making Makahiki’s Smart Grid Game able to measure and reward training scenarios and user contributions within the wiki.

Future Objectives

In the short term, the goal is to fix the current version of the Article model such that the Article model will validate, and to then upload the application to Heroku. The next goal is to make the Article model or the article_mgr manager able to maintain references to the latest version of an article and provide a link to an editable version of the article, which will use the Markdown language that Makahiki already supports. A subsequent goal would be to modify one or more SmartGrid challenges to detect that a user has created a certain number of unique articles and/or revisions, and create a badge for it; alternately, I might attempt to incorporate a ratings module as well. Once the Article model is functional, building widgets to do basic database lookups for searches by title or author or loading a list of all revisions to an article should be relatively trivial. Articles are likely to be limited to text only for the foreseeable future, as support for image and file uploads is a lower priority given the current issues with the Article model and the feasibility of its gamification.

UPDATE: Heroku Application

My compilation and initialization failure was the result of extra commas in the models.py file. Once these were removed, the database could be initialized normally.

A draft version of the create_article widget.

The form does not have line breaks between fields, resulting in form help text seeming as if it is associated with the field below it instead of the field above it.


As mentioned, the changes at this point are minimal: the article creation form is displayed on the Profile page, and it redirects to an error page instead of a confirmation page or an editing page if the Submit button is clicked. Furthermore, it is not currently possible for any user, admin or non-admin, to delete the entry the Submit button creates in the database.

While trying to set up player0 as a dummy user, I was unable to continue the setup dialog beyond the point shown below. I can only conclude that my database model changes somehow broke other aspects of the setup process.

Now I cannot set up new users. Clicking on the right button to continue does nothing.

Now I cannot set up new users. Clicking on the right button to continue does nothing.

Makahiki Administration and Gamification, Version 3

Issues To Address

After reviewing the latest plan for my application, my professor pointed out a few areas of the design that might require further thought. The goal of my application was to provide a potentially wiki-like means for users to create guides, combined with a Stack Overflow-like means of awarding reputation and pointing out issues for future work.

The problem with this kind of system is that it is mostly disconnected from whatever documentation the developers produce – it may not keep up with software updates or newly discovered bugs, and at best it serves as a kind of patch on flaws in the developer documentation. As my professor pointed out, unless the authors are careful to mention specific details about their guide (what OS it applies to, what version of the software it’s meant to use, et cetera) it is difficult for a new user to know if a guide is applicable, and even more difficult to know if it will work. A reputation system may or may not be helpful here; it is only as good as the number of site users who bother to rate an article, and if they do not leave comments, it is not clear which parts of the article were useful or need to be fixed.

The challenge, then, is to design a system in which users are more closely connected to the production of developer documentation. It is probably not good to go “full wiki,” as the developers should still retain some control over the direction of development and the style and organization of documentation. Furthermore, the work of wiki administration and maintenance would probably require diverting personnel from actual development tasks, which would be a problem for smaller teams. This is more of an administrative issue, though, and in principle it could be taken care of by eventually nominating administrators from the user community to enforce a Wikipedia-like manual of style. Teaching this manual of style to new users is in and of itself a problem, since it might become a new barrier to entry.

The New Workflow

The revised workflow.

Above: The revised, wiki-based workflow.


The Makahiki system already contains features for recording when users have completed certain activities and for unlocking higher tiers of activities in response. The badge system is, from a game design standpoint, easy to think of as a reward system for wiki contributions, some awarded automatically and some by the decision of administrators. (For something similar, see Wikipedia’s Barnstars.) In this system, Makahiki’s Smart Grid Game would be re-purposed for a wiki training game, in which a user plays around in a sandbox and unlocks basic user privileges as he or she goes, earning badges as a certification of basic training. Just as Wikipedia regularly selects featured articles, the authors of the highest-rated guides in each category could periodically be invited to contribute to the documentation of new builds of a software system by the developers.

I think there is also a need for an “Issue” article type, for users who have found a problem and have documented it but do not know how to fix it. Instead of just a usual bug-tracking system, which users may be unaware of, and in which it can be difficult to figure out at first glance why an issue has a certain severity rating, articles on the issues themselves could become collection points for comments, and eventually become troubleshooting guides.

In this system, articles could be segregated by project or by general category. Hypothetically, developers (as administrators) could manage the creation of article categories and the registration of new projects with the site. Links to the current versions of official documentation could be provided on the project’s page, and users could contribute to multiple projects.

On the Surface: Minor UI Tweaks

User pages, version 2.

Above: A slight redesign of the user page.


I have decided to call the more generally targeted version of the site “SetupBooster,” for reasons which in large part have to do with the lack of unused domain names related to speed and launch metaphors. (Things like rocketstart.me and Kickstarter were reserved long ago.) It is probable that SetupBooster is already taken, but I will worry about less fundamental issues like site name and logo after the site itself is up and running. The slight redesign adds more mentions of user achievements and article ratings, and eliminates the newsfeed (which was essentially a duplicate of the newsfeed on the main page).

Since Issues is going to be an article type, the system for reporting problems with articles is being renamed to “bugs.” Both have similar meanings, but I am not sure which name would be more or less confusing for each. The article categorization system is probably just going to be an identifying string without any article format restrictions, as I can’t think of a specific format to write an issue report in that would differ substantially from an article – both would be required to include software version and operating system, and would feature a general description of some aspect of the software. This allows additional types of articles – suggestions for future development, or in the context of Makahiki, popular community-designed widgets with good setup documentation for creating them – to be added to the system more easily. A manual of style could be created for each type, but that is probably something best left to human administrators to enforce.

In One Month

In one month, I will attempt to integrate an open-source wiki application and a ratings module into Django and see if Makahiki’s Smart Grid Game can be configured to detect changes to versions of an article. Though the django-wikiapp and django-ratings look promising at first glance, I do not know what will be involved in integrating them with each other and the Makahiki badges system. At a minimum, it is my hope that, by the end of this semester, test users will be able to create a new user, run through a series of training games in their own article sandbox which reward them with badges, create and edit their own test articles, and rate their quality. Depending on how similar the wiki application is to Wikipedia, I may not need to implement a separate commenting system if the wiki application provides Talk pages. The short-term goal of this project is to create a ratings-driven Wikipedia-like system that runs on Django, uses the Smart Grid Game to train users, and possibly awards badges based on a running count of how often the user has done certain editing tasks.

Testing The Makahiki Administration System

This week I tested the Makahiki challenge administration system. For the most part, the instructions for creating and configuring challenges were clear and understandable. I experienced only three problems: a problem with user account passwords, mistakes I made in assigning dependencies, and a difficulty in coming up with new designs for events outside the scope of the default actions already available in the library.

Non-reproducible passwords bug

At first, I was unable to log in with either of the non-admin accounts I had created, playerA (password: AAAAAAAA) and playerB (password: BBBBBBBB). I am not sure what caused this bug, and later users I had created did not have this problem. Using the “Log in as user” option while logged in as administrator took me to an error page, and I was unable to log in or log out in that browser (Firefox 19.0.2). Opening a new browser (Google Chrome 25.0.1364.172 m) allowed me to log in normally.

An error page.

I was redirected to this page after using the “log on as user” option.


I assume this bug had something to do with browser cookies, but I was unable to reproduce it.

Difficulties of Challenge Design

When designing new activities for the challenge, my greatest problem was coming up with original activities. As a testament to the breadth of the default activities that most obvious commitments and events, such as bottle recycling, use of natural light, and using public transportation are already covered.

The Makahiki markup system which sets the conditions for unlocking challenges is simple to me as a computer science student, since it consists of boolean statements based on whether or not activities are completed. Though I was able to figure it out on my own, I think the “Design The Smart Grid Game” section should provide a link to the “Supported Predicates” article so the user knows where to find this information. Example predicates are shown in the article, but the predicate system is not explained in that section of the documentation.

Level 4 test challenges.

Above: These challenges were set to unlock such that completing research-apps unlocked the rest of the board.

One possible improvement to the administrative interface would be some kind of dependency graph visualizer. Though it is probably not needed by administrators who rely mostly on the default challenges, it may be useful for challenges with a higher degree of customization. However, I am not sure how feasible it is to implement this in Django.

Difficulties of Challenge Management

I have no issues with the challenge management system. One useful feature is the ability to approve challenge submissions in batches. With the exception of variable-point-value challenges, this seems like it would be very helpful for challenges with large numbers of participants. Badges are awarded automatically, and the system keeps track of who is eligible for points-based, energy-based, and raffle prizes. It seems as if actually managing the competition once all activities and prizes have been set up is much easier than the process of setting up all of these items and their dependencies.

Conclusions

As a whole, the hardest part of Makahiki challenge design is probably keeping track of dependencies between different levels of activities and making sure that activities are unlocked in the correct order. Creating individual activities is simple, though the predicate syntax which Makahiki uses to determine conditionals may be difficult to understand for some users. Managing the competition was fairly simple as long as the conditionals were correctly set during the challenge design phase.

Makahiki Administration and Gamification, Version 2

Project Planning

On the suggestions of my classmates and instructors, I have revised my project plan to include more social elements and increase the degree to which gamification features are integrated into the operation of the site. My first draft was an overlay of a “helper” interface onto the existing Makahiki interface. While the Makahiki configuration and design tool which I eventually design for my Honors project may follow that design scheme more closely, that kind of application, which could run on a local installation without needing to interact with other users, does not lend itself well to blending in social gamification elements, such as community rating systems and recognitions of user contributions; it would be mostly a static system that changed only with changes to the Makahiki framework itself. A “social database” with community ratings for guides would work much better as a socially integrated web application.

A Draft of the Site Map

Simplified site map.

Above: A simplified site map.

The web application contains a few mostly-static pages that link to the official documentation for Makahiki and its dependencies, as well as to the Github repository. Apart from that, the front page allows users to sign in and manage their guides. Anyone can view guides whether or not they are a registered user, but only registered users can rate guides and edit (their own) guides. Though this could also potentially use a wiki model like Ubuntu in which anyone can edit any page, this seems as if it would be just as difficult to implement if not more so.

I have created a few mockups that depict features I would eventually like to be able to implement, though it may not be possible to incorporate them all before the current semester is over. The goal of this “social help site” is to offer a means to rate the highest-quality guides and alert their authors to issues or problems with their guides so that they can be improved.

Mockups: Home Page

Draft layout of the home page.

Above: Draft layout of the home page.

The navigation bar that is used throughout the site offers links to Makahiki information download pages and the Github repository; to official documentation for Makahiki, Heroku, and its dependencies; to a list of all user-created guides; to a search feature that searches for guides with relevant titles (or within the article content if there is time to implement full search); and to a login or account creation dropdown menu, respectively, from left to right. Site-related and Makahiki news appears in the center, while a collapsible dialog box lets a user know what the site’s purpose is. The sidebar lists the top 5 highest rated articles, with an option to view more. Recent site activity is listed in the left-hand column.

Mockups: User’s Page

Draft layout of a user page.

Above: Draft layout of a user page.

Now that the user is logged in, many of the options which appear in the right column in this mockup will be accessible from the dropdown menu in the rightmost box of the navigation bar (e.g., logging out, editing one’s profile). This, however, is not the profile page; the profile page would be editable. Site news appears here as well; hypothetically, this could display new user messages instead. Users are able to send and receive messages to and from each other, and any comment which is marked as an issue is sent to the user’s “inbox” with a note about what article it came from. A summary of the user’s reputation (based on article score) appears in the lower-right-hand infobox. I have not planned out the rating system yet, and the +91 is entirely arbitrary.

Mockups: Guide And Ratings Modules

A sample article page.

Above: A sample article page. Note the ratings module and comments section.

Each article will have a ratings module and possibly a statistics page. I have not figured out exactly how the commenting system will work, though I will probably separate it from the issue-reporting system and will definitely keep it to members-only commenting to cut down on spam. At this point, I am leaning towards only allowing registered users to rate articles. I am not sure how to handle article collaboration or if it will be supported by the system; at that point it might be simpler just to try to get some kind of wiki software running instead of basing the system on Makahiki. Ideally the application would support creating and editing HTML articles. I am not sure whether file uploads should be allowed as shown; this is a feature Makahiki supports, but offering an upload feature on a publicly accessible site comes with a security risk. The scoring widget shows what percentage of an article’s readers gave it which rating, which is useful in determining what the majority of users perceive an article to be. Scores on articles contribute to the ratings on a user’s page.

Conclusions

Though the previous version of this project was an overlay help guide with some badges added in, this version attempts to further integrate a user rating system to separate quality guides from the rest of the user content. It is intended to provide means of identifying authors who produce well-written articles and enabling users to point out problems in existing articles. Though this system does not explicitly use all of the features of gamification, it would allow users to track progress, be recorded as reporting issues, and compare the reputation of each others’ contributions. In the end, it may not be possible to implement all of these features in a Makahiki-based application as they appear in the mockups. Nevertheless, the goal is to mimic the user-contribution-rating features of sites like Stack Overflow (as described here by one of its founders, Jeff Atwood). Stack Overflow and its sibling sites are designed to encourage users who do not know each other to work together in pursuit of a common goal by enhancing each others’ programming skills. The goal of this social guides database is to enable users to post and collectively improve each others’ guides to configuring Makahiki. This will enable the user community to share new ways of using or modifying Makahiki which are outside the scope of standard software documentation but are still useful to those who are creating sustainability challenges.

Usernames in mockups are fictional. Any resemblance to actual persons, living or dead, is not intentional.

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.