Resolving game issues in Moodle – lessons learned

For those of you who have been vaguely following the Moodle Dailies project, this is the next installment, leading up to my presentation at the 2011 AU MoodleMoot. For those of you who haven’t been following, read here, here and here.

As I get closer to a completed proof of concept, I thought it was worth outlining some of the design lessons (on the technical side) I’ve learned in trying to wrangle Moodle into something approaching a game-like structure:

  1. You can’t be a game purist. It’s not a real game and it’s never going to be a real game – at the end of the day, it’s an LMS. There are a lot of compromises you’re going to have to make.
  2. Don’t bite off more than you can chew. My initial intention to have 20 levels has had to be drastically scaled back to 5 (at least for now), simply because each level is a much bigger beast to design than initially thought. Moodle is somewhat deceptive because it’s technically quite easy to use, but the conceptual issues involved in game design mean a huge amount of time is sunk into problem-solving and testing (as well as mundane but necessary tasks like Creative Commons attribution).
  3. The scroll of death is not your friend. If you are designing in three-tier levels (a la Angry Birds), bear in mind that no matter how well you manage the end-user UI using conditional activities and clever linking, the back end for you as a designer is going to be a huge, hairy scroll of death. A level could potentially have 10 text-and-graphic labels – only perhaps 3 are visible to the end user, but you will see everything. This is another reason my initial 20 was scaled to 5 – it’s just not feasible to work with the back end on that scale.
  4. A rose by any other name is going to be a pain in the backside. When you are heavily relying on activity completion conditions and the use of labels, naming is paramount. Label names take the first bit of text within – and having 50 labels called ‘Click here to go to’ is not helpful when trying to set conditional activities. The name that each dependent activity will take is very, very important.
  5. Legacy course files is your friend. For run-of-the-mill online courses, this isn’t the case, and for good reason. However, when you are working with game design and constantly reusing graphics (next time you play a game, pay attention to how many graphic elements are reused – Warcraft inns, anyone?), the ‘bucket’ way Moodle deals with files really starts to fall down. If you haven’t got legacy course files, use your public folder in Dropbox or hang stuff off Flickr. You’ll thank me when you can reuse code.

 

And so on. Perhaps the biggest lesson I’ve learned is that designing a game, even in something apparently quite simple like Moodle, takes a lot of long, hard work without much to show for it. As a research project, this has been one of the most time-intensive and least predictable. It lacks a pretty set of data – game design is messy. Interestingly, though, this project has been very effective at both making me think in depth about what I am aiming to design, and about the creative possibilities inherent in what is fundamentally a restrictive learning management environment – something you won’t get from reading papers.

Leave a Reply

Your email address will not be published. Required fields are marked *