Improving Performance – A Case Study
I believe it is about time that I make a blog post about possible directions to take with my paper. Case studies will naturally form the core of the document, with relevant details on gamification explained either through these studies or perhaps in small notes located in the beginning of the paper. It is surprisingly difficult to find a meaningful problem that could be ‘solved’, or at least made more enjoyable, through gamification. As has been made apparent in my previous blog posts, gamification is a very broad concept that is hard to define because it can be applied to just about anything (though not necessarily meaningfully…). This degree of freedom is a mixed blessing, but at least my assignment itself already limits me to engaging students, not just anyone. Regardless, after mulling over a few ideas, there is one that seems to hold the most promise, for now. I will however, make a blog post detailing other possibilities as well, perhaps subsequently drawing in some valuable feedback.
The idea I have been fleshing out the most is something I observed over the course of my education, which is Computer Science, though it isn’t based on a concept important solely to that field. Performance is important in a large variety of applications, from database implementations to video games. The problem with coding for performance is that it is difficult to teach. Students are taught a variety of ways to check just how performant written code is, whether mathematically through the “big O”, or simply by using profiling tools that check code for bottlenecks. However, these tools do not always give you ways to solve performance issues, as these solutions are very varied. In my experience, learning to code for performance only comes through practice and there is not one rule to follow. Certainly, there is a slew of dos and don’ts that can be followed to perform some early optimization (premature optimization can be a bad thing in a development cycle, though!) but these are often minor. Removing unnecessary loops is also a common way to improve performance, but it isn’t a catch-all solution. I plan to try and design an application that could help in practicing this important issue, hopefully injecting game elements to make it a fun and engaging tool. Simply coding randomly for performance is, for most, not exactly a fun way to spend your time, so incentives must be given and that is where gamification comes in.
The basics of what I propose are quite simple. For fields such as Computer Science, Engineering and even Architecture, a framework is created that allows for the posting, sharing and solving of problems involving performance. What these problems are depends on the field in question. These can be any type of algorithm for computer science, or a study of the maximization of material use for engineers in a certain project. The context is intentionally loose to allow the platform to be easily extensible. To continue with the example of computer science, Dijkstra’s algorithm for the shortest path through a graph could be given, but only in its most elementary, pseudo-code form. Students can then implement it, and necessary data structures, to achieve the actual algorithm. They can then post and share their results, and how well their algorithm performed given a certain graph (or in a general case, certain conditions). Other users can then examine these results and the algorithm and perhaps gain inspiration on how to improve their own. The end result (or so I hope) would be that gamifying this process would encourage students to think about what they are doing and try to find ways to improve their process’ performance in multiple iterations. They post results, only to inspire others and receive feedback from them, subsequently allowing them to go back to what they had originally created and attempt to improve it. This back and forth can continue multiple times, naturally, for greater effect.
So what elements am I currently thinking of adding to gamify the above application? As discussed before, possibilities are endless and a variety of ways exist to try and categorize and define the elements that can help gamify an experience. First of all, using the table I used in my blog post Dynamically Mechanic – The Building Blocks of a Gamified Application, I will try to analyze what dynamics would have the most impact, and what mechanics would satisfy them.
- Reward: Despite being limited in what mechanics can fulfill this desire, rewards can be powerful, if used correctly. As advocated by Sebastian Deterding in his response to Zichermann’s marketing-inspired book “Gamification by Design” (A Quick Buck by Copy and Paste), incentives such as rewards can only go so far and there are plenty of ways to implement these poorly. The rewards cannot be generic, if they are, why would you want them? Why would a student in history want to get a reward in the form of a book on the basics of programming in C++? These elements need to be relevant, if they are, then fulfilling reward can indeed be as influential as one might expect it to be.
- Status/Achievement: The quintessential example when gamification is brought up. These two are most notably instantiated by badges and leaderboards (or high scores). While a classic, it is deceptively simple to create a sense of achievement that will have the user come back for more. Again, they need to be relevant for the users in question, not just anyone. If they are, they will want to show these achievements to their peers, thereby being urged to continue to achieve in the application.
- Competition: In many ways, competition is a mixed bag. While the great majority of individuals can be “influenced” by the other game dynamics, competition is something that people hate or love (so to speak). Therefore, adding this to the application would also mean making certain that it is an optional element or one that serves as an added bonus for the mechanics that also satisfy the other dynamics presented above. If it is made a prominent feature, non-competitive individuals would be less inclinced to use the application.
As an observant reader may have noticed, I have chosen to avoid Self Expression and Altruism. I believe that the former is one of the weakest dynamics, even though it is often claimed to be part of popular platforms such as Facebook and Youtube (as they claim their users are expressing themselves; whether that is true or not is up for debate). Self Expression would be tremendously difficult to implement in the type of system I propose. True, the way a person uses the application will likely mirror what kind of person he or she is, but not to the degree that it would satisfy the dynamic and actually prove beneficial to the gamified application. The second, altruism, while powerful, does not fit into this application for the simple fact that the elements that will be added to the proposed platform cannot be given or shared in a way so meaningful that it would urge users to continue doing so. Without that drive, the application would see most users come and go in short succession.
Now I have the Dynamics I wish to employ and can turn to the main mechanic categories that can fulfill these desires. The discussion below is nothing more than ideas rumbling around in my head for now, and I will leave concrete decisions for another blog post.
- Points: Points can be various things with differing contexts, but they can satisfy all four of my chosen dynamics. However, I do not intend to create a bloated point system in which one reward plays all the fields. An approach I am currently considering is to have points that are garnered through positive feedback on activities, as well as comments that are well-received by other users of the system (much like a thumbs up system), as well as points that are gained through a different method I will tackle when I discuss Challenges.
- Levels: Levels are often labeled a variety of different names, but it usually boils down to a certain title or numeric value displaying the global progress of a person, or their position, within the application. It can satisfy status and achievement, as well as competition. A possible implementation could be to have users gain levels as they collect points from the various activities they perform on the system. The higher rated their solutions, comments and feedback, the higher their level. It can basically be a summary of what they have achieved at a single glance.
- Challenges: Challenges, just like points, cater to all the dynamics I have chosen to include. It is rare that I have seen challenges implemented in a gamified application, because it is usually a difficult element to translate. A possible translation of the game element could be to allow users to issue a challenge to others to have them improve upon their own algorithm, giving them a push to keep going. However, unrealistic challenges would be thumbed down by other users as these undermine the purpose. Naturally, difficult challenges that are successfully completed should draw the attention of other users, who can express this through further distribution of points and the like.
- Virtual Goods: This is perhaps a strange choice, but many games use virtual goods to urge its players to continue investing time, money and effort in them. Naturally, real money would never come into play in an application such as this; one that targets students. But virtual funds could come in the form of the aforementioned points, which can be spent to unlock functionalities and customizable options such as changing the look of the pages that display the results of their solutions.
- Leaderboards: While not in the form of a high score, leaderboards that show overall statistics of a variety of users can also be interesting, even if out of a purely informative viewpoint. Tables showing the most popular problems to be tackled by users, as well as the solutions most referred to by others when users seek inspiration can help root out content that interests a certain individual.
It is clear from the chosen categories that there are plenty of options available and that there is still a lot of work to be done. The next step is to try and find which game elements would be beneficial to the application, which would make it bloated and which would simply have an adverse effect. In my next blog post I will outline a few other case studies that I haven’t worked out nearly as much, but would still like to hear some feedback on. Once I have a more concrete idea of the direction I wish to head in, I will also see if I can apply a few other frameworks for systematically deciding which game elements to add, and why. This can prove instructive and I will see if I have the time to couple those applications with a brief discussion of the papers I located them in.