Over the last couple of weeks I worked intently on putting together a first prototype, and getting it into people's hands for testing.
The concept was simple – a classic black vs white 'defeat the opponent' game in (loosely) the vain of Go, Checkers, Chess or Othello. The twist was that you would never directly move the game pieces by hand, they would be manipulated through some basic programming logic. My hope was that combining this control method with competitive strategizing would help deliver and reinforce a grasp of the following programming concepts: conditional statements, boolean operators and some basic positioning and scale ideas.
Pieces could be removed from the board in two manners: scaling down to 0, or scaling up enough to cause a collision, in which case all colliding pieces burst.
Much of the strategy rests on two principles – you can't target by color, so your conditional selections are likely to include your own pieces. You scale both, but aim to lose less of your own. Additionally, there is always a tension between scaling up and scaling down. Sometimes scaling up is defensive, other times it's an offensive tactic (in pursuit of causing a collision and consequent burst).
I worked through a few bold, colorful designs. Early on I received feedback that making the game pieces look tangible, but then not allowing direct manipulation (i.e tapping and moving the pieces) could cause frustration. I stripped the game pieces back to minimal ring shapes.
Over the course of 4-5 days I built a fully functioning prototype with EaselJS. This was my first encounter with the library, which is designed for HTML5 Canvas games – seemingly ideal. I made as many features as possible flexible. For example, it's simple to change the size of the grid and number of pieces.
While the ideal for a two player game of this nature would be asynchronous play, for now it's 'pass and play' – meaning both players share the same screen, and simply take turns.
I opted to leave the buttons and input features with no design polish at all, and I postponed looking at any animations (for which I'm sure the accompanying TweenJS library will be useful). These things didn't seem important to the MVP.
I played the game multiple times, and gathered plenty of valuable feedback. When I conceived the game I'd imagined the goal to be removing your own pieces first, but it quickly became clear that removing the opponents pieces felt better (and more in the vain of traditional games, of course!). This was a trivial change, with no other impact on strategy.
Next was a lot confusion with the AND / OR logical operators. This wasn't unexpected, and in many ways is an objective for the game – making something unfamiliar familiar. The prototype doesn't have an onboarding process, making it hard to judge the scale of the issue. But it's clear that not understanding the programming principles leads to frustrating gameplay – something to be acutely aware of whichever direction the concept goes in.
There was smaller feedback on the uncertainty created by highlighting selected rings in green. Once highlighted, the original color isn't visible, so you're not sure how many of your own pieces vs your opponent's you're targeting. This can easily be addressed in design. People also wanted to see whose turn it was, and a count of the remaining pieces. Both things I'd intented to include, but left out of the prototype.
Lastly, and most significantly: once people had grasped the logical approach to conditionally selecting pieces (i.e building the logic of their turn) it became laborious and repetitive. I noticed that people started leaning on the logic they had grasped, rarely trying to get more ambitious with longer statements (e.g using three-part conditions with two operators). Regardless, this feels like a fundamental problem – and it cuts to the heart of what I'm trying to achieve. What is the balance between learning and playing? Once people have learned the concepts I'm hoping to convey, should it just be a fun game, or should they be moving on to something more challenging? The tension between education and entertainment is delicate, and critical.
I was left feeling that the game needed considerably more to it – both strategically in the game mechanics and educationally in the programming principles included.
Back to the drawing board.
In class we presented the status of our projects, and received jars full of feedback. Some of the key questions people think I should be asking (and I agree) are as follows:
What makes it sticky?
What level of literacy are you trying to achieve?
How does the user go from the game to a higher learning?
What would be the motivation for people to learn computational competency?
Will you need lots of new different games for each group of programming concepts?
How do you measure effectiveness?