Gamified course: how to deal with the massive amount of grading needed without using specific software?

Question

I've been trying to give gamification a go for a while, but I'm struggling on how exactly to implement it.

I teach an introduction to programming course, and as I'm part of a team including a couple other teachers and we have too many students, our course is usually divided in two parts: one teacher explains the concepts and then I help students solve problems and exercises. That is 2 classes a week. When the semester is about to end, we have an exam (actually, 3, as the students have 3 chances to pass the exam). No additional activities, no projects, etc., as we usually have about 50 students to grade each semester.

I'm already trying a flipped classroom approach by providing videos they can watch at home before they come and try to solve exercises during my class, but still would like to add some gamification. However, I'm struggling on how to propose this to the rest of the teaching staff.

I've read a couple of books on gamification, watched videos and read about other teacher's experiences online, and I pretty much have an idea of what I'd like to do, and one of those things is replace grades with "experience points" and levels. The more XP points you get, the more levels you gain. Students that reach a certain level will pass the course.

The problem is: how are XP points awarded? In most cases I've read about, every activity is awarded XP, be it exercises the students solve, youtube videos they have to watch, projects they make, quizzes, etc. The thing is: how do you grade (or award XP) all of that? If every activity has to be reviewed by the teacher it would add a huge burden on the staff. Also, when students do their regular exercises, as they are so many, it would be impossible to give them individual feedback on each exercise, so those would not earn them any XP.

Maybe some online quizzes could help, but with programming there's a limitation there, it's not as simple as throwing multiple choice questions (at some point they will need to be coding). I know there are a couple sites that offer programming challenges with automated tests, but then there's the thing of knowing which student actually attempted to solve them, and which ones succeeded (I should add that I really need to keep my gamification proposal at $0 budget, as I know there is no way the administration will pay for software licenses or any equipment other than what we already have).

I thought of a scenario where the teacher would be some kind of "game master" and the students are trying to level up their characters by defeating "monsters" (exercises) and maybe working in guilds (peer reviewing their work). I pretty much even have a story created and some other details I'd like to add. But I can't do any of that unless we increase a good deal our work time so we get to grade students on many more activities other than just the 3 exams we already have.

So how does everyone else deal with this amount of grading?

Answer 1

I'm a former gaming engineer (many years ago), now college CS lecturer. Personally, I resist attempts at "gamification" of courses -- in short, it seems to me like a corruption of the gaming concept, and something that weakens both sides of the enterprise.

It sounds like you're struggling to get your arms around a desired major overhaul of the course. I think that many "reform" proponents would suggest that you take smaller steps, trying out some small single component in a course, assessing how well that works, and then iterating. Also consider: Will future courses use this gamification approach? Or should you be preparing your introductory students for the expectations of "normal" college courses with which they will be interacting in the future?

My top suggestion, as a first step, would be to work in some programming assignments which the instructors do manually grade throughout the semester. Feel free to make the assignments fairly simple and standard; directly from the book is fine. Have programs that take obvious input and output some kind of deterministic result -- write a simple batch file to compile and help test the functionality. Run them through an automated plagiarism checker (Stanford Moss). Also read the code and give feedback/points for proper style. I do this for ~8 assignments per semester, ~25 students per section. If you have double the students, then maybe halve the number of assignments.

Personally I think that you've got to commit to some kind of personal assessment of actual code for a proper programming course. Students that don't get that and wind up in my programming 2 course very much struggle at that level. Yes, this is more work than just one or two exams alone. But if students can't write code, then you should probably fail them, and if you want to think of those grades as your academic "gamification", then maybe that will help you out.

Answer 2

This doesn't really depend on gamifying the course, but it would work there as with any flipped classroom situation. I'll assume here that you will drop most "lecturing" and students will "cover the material" when not face to face using some combination of printed and other materials, including, perhaps, interactive materials. Students are, without limit, allowed to work together when exploring course materials and will even have access to some exercises that they might use to help them know when the "get it".

The face time in the course will be taken almost entirely with activities that produce some "product", a program or an essay or a proof of a theorem - anything. These products are what is graded and you can use a wide range of techniques to do so, from formal marking to just counting up successfully completed small tasks or having a program pass a test.

Note that you can reduce the grading by a factor of two by having students always work in pairs. Pairs share a grade on their paired tasks. Pairs rotate frequently and do peer assessments to help solve the free rider problem. Peer assessment must, however, be made non threatening. A simple peer assessment form asks for (a) your own primary contribution to the work and (b) your partner's primary contribution. It doesn't ask for a "quality assessment" but for a contribution. Of course, you sometimes get "none" for an answer, which gives you a bit of evidence that will accumulate over many interactions.

Sometimes you form the pairs, possibly randomly and possibly by design, and sometimes you let them choose partners. Of course, you need to teach students how to both be engaged in a paired situation so that no one is really allowed to be a spectator. Two minds on every task.

Pairing has other, more important, benefits than just reducing grading effort, however. It has been shown that students will, when allowed, and especially when paired, answer one another's questions. It isn't often the case that you have a strong student who dominates a weak one (switching helps avoid this) but that one will have a key insight before the other and can share it. In a lab where everyone works alone, it has been observed that many students raise their hand for help and simply wait, passively, until it arrives. Unless there are a lot of lab assistants, it may take a long time for that help to come. In paired situations this rarely occurs, so instructor time is better used and will be focused on more important issues.

You can manage the data produced simply by having each pair, for an individual interaction produce an index card with both names and the name of the task. They can produce individual cards for the peer and self assessment. You can mark outcomes on the cards and can also use them to make notations when you interact with an individual pair. These are collected and collated at the end of the exercise.

If the course meets for a total of 45 hours over the term, you could have up to 90 such bits of information for each student, assuming you swap pairs every half hour.

More than two working together is less efficient and often leaves someone out, but four people who work together, but always pairing can be made to work on larger projects.

For a complete discussion of pair programming specifically see the book Pair Programming Illuminated.