As I believe I’ve already mentioned, I play a number of board games but, before you think “Oh no, not Monopoly!”, these are along the lines of the German-style board games, games that place some emphasis on strategy, don’t depend too heavily on luck, may have collaborative elements (or an entirely collaborative theme), tend not to be straight war games and manage to keep all the players in the game until the end. Notably, German-style board games don’t have to be German! While some of the ones that I enjoy (Settlers of Cataan, Ticket to Ride and Shadows Over Camelot) are European, a number are not (Arkham Horror, Battlestar Galactica and Lords of Waterdeep). A number of these require cooperative and collaborative play to succeed – some have a traitor within.
I have discussed these games with students on a number of occasions as many students have no idea that such games exist. The idea of players working together against a common enemy (Arkham Horror) appeals to a lot of people, especially as it allows you to share success. One of the best things about games that are well-designed to reward player action and keep everyone in the game is that the tension builds to a point a final victory gives everyone fiero – that powerful surge of joy.
Now, while there are many games out there, I decided to go through the full game design process to get my head around the components required to achieve a playable game. I’ve designed some games before and, after a brief time spent playing them, I’ve left most of them back on the shelf. Why? Poor game design, generally. As a writer, I have a tendency to think of stories and to run narrative in my head – in game terms, this is only one possible passage through the game. One of the strengths of computer games such as Deus Ex is the ability to play multiple times and get something new out: to shake up the events and run it in your order, forming a new narrative. (In DE, technically, you were on rails the whole time, the strength of the game is in the illusion of free will.)
Why is it important for me to try and design a good game? Because it requires a sound assessment of what is required, reflection upon how I can model a situation in a game, good design, solid prototyping, testing, feedback, revision, modification, re-testing, thought, evaluation and then more and more refinement. From a methodological point of view, my question to myself is “Can I build a game that is worth playing based on a general sketch of the problem, a few good ideas and then a solid process to allow me to build game features in the way that I would build code features?”
Right now I’m in the requirements gathering phase and this is proving to be very interesting. I’m working on a Zombie game (oh no, not another one) but I want to have a three-stage game where the options available to players, resources and freedom of action, change dramatically during each stage. I want it to be based in London. I want to allow for players to develop their characters as they play through a given game. I want player actions to have a lasting impact in the game, for decisions to matter. I want the game to generate a different board and base scenario set every time, to prevent players learning a default strategy. I want the whole thing to run, as a board game, in the German style. I want the instructions to fit onto 8 A4 pages – with pictures.
(I should note that I’ve been playing games for a long time and made a lot of notes about rules and mechanics that I like, so this has all formed part of my requirements gathering, but I’m not trying to put a new skin on an old game – I’m trying to create something interesting that is also not a blatant rip-off. Also, yes, I know that there are already a lot of zombie games out there. That isn’t the point.)
I’ve been crawling the web for pictures of London, layouts, property values, building types and other things to get London into my head. Because the board has to change every time, and I can’t use computer generation, I need a modular board structure. That, of course, requires that the modules make sense and feel like London, and that the composition of these modules also makes sense. I need the size of the board to make the players work for their victories and not make victory too easy or too hard to attain. (So, I’m building bounds into the modularity and composition that I can tune based on what happens in play testing.)
I knew this but my research nailed it as a requirement: London is about as far away from being a grid layout as you can get, with a river snaking through it. Because of this, and my randomisation and modularity requirements, I had to think about a system that allowed me to put the elements together but that didn’t make London look like New York. Instead, I’ve opted for a tiled layout based on hexagons. They tesselate nicely, you can’t run in straight lines, and you can’t see further than the side of one hex, which reflects the problems of working in London without having to force someone to copy out a section of the London map with all of its terrible twists and turns.
The other thing I really wanted to know was “How fast do zombies move?” and, rather than just look it up, I’ve spent a bit of this afternoon shambling around the house and timing myself to see what the traditional “slow” zombie does. Standard walking and running are easy (I have a good feel for those figures) but then I thought about that stalwart of zombie movies – the legless crawler. So, in the interests of research, I measured off a 10m course and dragged myself across the floor only using my arms. Then I added a fudge factor to account for the smoothness of the floor and, voila, a range of speeds that tell me how long zombies will take to move across my maps.
Why do I need to do this? Because I’ve never done it before. From now on, if someone asks me what the estimated speed of a legless zombie is on a level surface, I can say “Oh, about 0.25m/s” and really stop the conversation at the Vice Chancellor’s cocktail party.
Requirements gathering, around a problem specification, is a vital activity because if it’s done properly then you gain more and more understanding of the problem and, even though initially the questions seem to explode, you can move to a point that you have answered most of the important questions. By the time I’ve finished this stage, I should have refined my problem statement into a form that allows me to write the proper design and then build the first prototype without too many further questions. I should have the base rules down in a form that I can give to somebody and see what they do.
By doing this, I’m practising my own Software Engineering skills in a very different way, which makes me think about them outside of the comfortable framework of a programming language. Students often head off to start writing code because it’s easier to sit and write code that might work, instead of spending the time doing the far more difficulty activities of problem specification, requirements gathering, specification refinement and full design. I don’t get much of a chance to work on commercial software these days, so a zombie game on the weekends is an unusual, if rewarding, way to practice these skills.
Sliding across the floor is murder on the knees, though…
Poor Tim Bell. He must think I’m stalking him. I attended the BOF session for CS Unplugged, which quickly turned into the BOF on ‘Energising your Outreach to Schools” (my words). Once again Lynn Lambert and Tim shared their experiences with CS Unplugged to help us frame what was wrong with our outreach (or the problems that we had) in order to try and fix them.
The main issues were:
- How do we get into the curriculum?
- Bad/old equipment.
- Creating a meaningful activity in a very short time.
- Persistence – how we do we stay in their minds or their environment?
- Priming – how we prepare them for our visit?
- Time – how do we fit it all in and, more importantly, how does the teacher?
- Pick the right time to come in and interact with students, when teachers are happy to have you. Teachers don’t get a reward for dealing with students at elementary level.
- CS BIts and Bytes is a good newsletter
- cs4fn got another mention as a good website
- One amusing quote from a parent, after finding out what we did, was “I had no idea that CS had any application.” To our credit, nobody cried when this was told to the group.
- Involve people in discussing useful, relevant problems and how CS is used to help: suggestions included global warming and genomic sequencing.
Overall, another fun discussion with a lot of actively concerned people trying to make things better. Please leap in for corrections if I missed something important or got something wrong. I’m also happy to edit to add credits if required. 🙂
If you’re at SIGCSE, then you’re probably one of the 1,000,000 people who jammed into the pretty amazing Wednesday session, Demystifying Computing with Magic, with Dan Garcia and David Ginat. Dan and David coped very well with a room that seemed to hold more and more people – in keeping with a magic show, we were all apparently trapped in a magic box.
The key ideas behind this session was that Dan and David would show us five tricks that would teach or introduce important computing notions, such as discrete maths, problem representation, algorithmic patterns and, the catch-all, general notions. Drawing on Silver’s 1997 paper, Fostering Creativity Through Instruction Rich In Mathematical Problem Solving and Problem Posing (It’s better in German, trust me), they focused on the notions of fluence (diverse directions for exploration), flexibility (adaptation to the task at hand – synonymous with cognitive flexibility), originality (unfamiliar utilisation of familiar notation), and awareness (being aware of the possible fixations[?] – to be honest, I didn’t quite get this and am still looking at this concept).
The tricks themselves were all fun and had a strong basis in the classical conceit of the stage magician that everything is as it seems, while being underpinned by a rigorous computational framework that explained the trick but in a way that inspired the Gardernesque a-ha! One trick guaranteed that three people could, without knowing the colour of their own hats, be able to guess their own hat colour, based on observing the two other hats, and it would be guaranteed that at least one person would get it right. There were card tricks – showing the important of encoding and the importance of preparation – modular arithmetic, algorithms, correctness proofs and, amusingly, error handling.
Overall, a great session, as evidenced by the level of participation and the number of people stacked three-high by the door. I had so many people sitting near my feet I began to wonder if I’d started a cult.
The final trick, Fitch Cheney’s Five Card Trick was very well done and my only minor irritation is that we were planning to use it in our Puzzle Based Learning workshop on Saturday – but if it’s going to be done by someone else, then all you can ask is that they do it well and it was performed well and explained very clearly. It even had 8 A-Ha’s! That’s enough to produce 2.66 Norwegian pop bands! If you have a chance to see this session anywhere else, I strongly recommend it.
(A useful website, http://www.cs4fn.org/magic, was mentioned at the end, with lots of resources and explanation for those of you looking to insert a little mathemagic into your teaching.)