Project Status and Future Development Goals
The project’s Github project page can be found at jtakayama.github.io/ics691-setupbooster/.
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.
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.
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 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.
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.
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.