Here's my twist on the whole rubric design process.
My Introduction to Computer Science students are using GameSalad to design games. As I often do, I started the unit by issuing a challenge. For the next four weeks, my students' challenge is simply:
Design a game that doesn't suck.
We then brainstormed a whole list of reasons why games typically suck. The kids' ideas ranged from:
- Bad graphics
- Bad story
- Bad gameplay
- Boring
- Too hard / too easy
We put our ideas up on the board. We labeled them "Elements of Suckability" (yes, that is an adjective.) Once we had a good list, I pushed them to define exactly why something is "bad". For example, bad graphics might be graphics that don't match each other, or that make it hard to differentiate between friend and foe. A bad storyline is one that is either unoriginal, or too predictable (or nonexistent.)
We then just reframed the language in that list to come up with a rubric by which we would ensure that the games we come up with don't have any of these elements. I told them, "I'm not looking for a showstopper, or the next Angry Birds. I'm just looking for a game that doesn't suck. And in order to do that, you will need a game that doesn't do any of these things." Here is what we came up with:
- Clear, distinct graphics
- An original, engaging story
- Gameplay that is neither too hard nor too easy
- A progression dynamic (leveling up)
- A clear objective
- Matching graphics that are original or Creative Commons licensed
- Sound that is appropriate and non-repetitive
The secret of course, is that if you come up with a game that does all of these things, you will have a terrific game! But most of us have played bad games in the past, and it's sometimes easier to back into defining a good game than try to analyze why great games do things so well.