Marking Evil Squash

This is a much better logo than my version. Thanks Jamie

I’ve spent the last three and a bit days in the lab marking first year student work. And it has been great fun. There were four of us down there watching students go through 15 minute presentations of their Evil Squash implementations. For those of you who haven’t heard of it, Evil Squash is a board game for up to 4 players. It is a kind of cross between Snakes & Ladders and Ludo. We invented it just for the practical session and we are going to invent another one next year.

Our first year students had to create a program that implemented the game, getting all the arrows on the board to work, along with the “Squash” behaviour that is triggered when one player lands on top of another. We provided a “special” dice sequence which allowed us to test all the game actions and we watched each program run through this. Then we took a look at the code, gave marks for style and any extras (some students added AI players who could take on their human counterparts), checked on user documentation and test reports and finally gave out a mark.

We always do a game development for the first year course, but this is the first time we’ve used a brand new game of our own devising. It has worked rather well. Everyone got into the spirit of the development and we have seen some very impressive implementations of the game, including a few Windows Phone versions in Silverlight and XNA. Expect to find Evil Squash in the Windows Phone marketplace soon.

Once nice side-effect of using an original game was that there was no code out there for people try and use. When people get into trouble with a development there is sometimes a tendency to leap onto a search engine and look for code that solves the problem. This is never a good thing to do. A lot of code out there is buggy and hard to understand and often takes you further away from where you want to be. During the marking we ask for bits of the code to be explained to us, and I found that for the ones I marked everybody knew how their code worked. Even those unlucky souls who hit bugs during the presentation were able to say “Aha! I know what is wrong and how to fix it” and point to the code block that was causing the problem. 

We saw some great work, and gave some great marks out. I’m really looking forward to what they turn out next semester.