SAM WANDER

http://www.samwander.com 38 posts

Tutorial v0.1

I built an interactive tutorial. The game board itself is a little overwhelming at first, so I wanted to abstract key components from it and step people through the game's rules / ideas in an explorable way.

As per my previous post, it needs a lot more work.

Here's a run through of the current tutorial for posterity:

Playtesting.

I've playtested the new game (AKA "DUAL") three times, at various stages of prototype development.

1 / Paper Prototype

I built an interactive version of the game board in JavaScript, as managing the morphing shapes in paper wasn't really workable. Then I printed the other game components and instructed some other IxD students to play.

The tough thing with a paper prototype is that there are no explorable affordances. You can't pick up a piece and see what you can do with it, or try tapping things. This made the process a little contrived, as I had to explain the game more than I wanted.

Once the rules were grasped the students seemed to really engage with the cerebral challenge of thinking ahead in the sequence, so it felt like a promising start.

2 / In-development Web App

I had 4-5 students from other SVA programs play the game as a fully functioning web app, during a social event. It's fair to say the depth of thinking required for the game and a bustling informal setting aren't always compatible, but I observed that once people engaged focus they found the game really challenging and interesting. At least one person got stuck in, and asked to be informed when the game is released.

The biggest takeaway was that onboarding is critical. It took significant explanation from me before people ever crossed the line from perplexed to excited. I won't be there to hold hands in the real world, so the tutorial / onboarding needs to be excellent.

3 / Complete Web App

Most recently I attended NYU Game Center's Playtest Thursday – a weekly event where anyone can bring along a prototype game for feedback, which is a great resource for the community.

This was to be the first time people with no connection to me or the IxD program would see and play the game, which was a little nerve-racking.

Since the last round of testing I'd built an interactive tutorial, and was hopefully people would pickup the game via the tutorial rather than any support from me.

In total, six people tested the game. People were enthusiastic, but struggled with the aformentioned onboarding – it's nowhere near solid enough yet.

Specific feedback I captured:

  • Asynchronous play would give you time to really think (it's always been my hope to develop such a variation, but technical complexity set me on the 'pass-and-play' path first).

  • Should the game perhaps be a one-player puzzler? This suggestion was tempered by an acknowledgement that the defensive part of play makes it interesting, and this would be lost.

  • Is four steps too much, should it be two or three? This has come up before, and it's a difficult balance to strike – too many steps is too much to think about, too few is not challenging enough and dampens the potential for programmatic thinking.

  • Should there be a handicap for player one, as starting is an advantage? This is definitely an issue. Some potential solutions: limit the sequence steps for the first turn, limit the conditions / actions for the first turn, give black more corners on the initial grid setup, or most challenging – ensure via AI that it's not possible to win on the first turn.

  • You should be able to win with a diagonal, not just row or column. This would be easy to add, and seems to bring a touch more interest to the overall strategy.

  • The tutorial isn't clear enough, and doesn't set you up well for the game. This is in many ways the biggest challenge I have at this stage, as without grasping the game basics people won't want to play (and the enthusiasm I've seen only comes once a basic understanding is in place). I was told it was too wordy, the switch actions were unclear (as only two of four corners are included). But most fundamentally, I had to resort to explaining much of the game – so the whole piece needs rethinking. One suggestion was to let peope do the final step in a mock sequence, so the way all the parts fit together becomes clear. Much to consider for this.

  • The design of the row / column pieces may need to be clearer, as the rectangles look like shapes (but this may be clearer with better onboarding).

  • A final minor point: it would be nice if you could swap sequence items by dragging one over the other.

One Point Nought.

Following valuable feedback on the 'Circles' game I went back to the drawing board, seeking to take the things that were working but build something with more depth, fun and replay value.

One of the biggest flaws with the first game was that once people had grasped the way the conditions and logic worked, and could see what they wanted to do on the board, getting there felt like work. Also, the unpredictable nature of exploding circles made it less compelling to delicately target specific pieces on the board.

Amongst some wilder ideas, I put this rough mockup together:

This attempted to build on the first game by introducing some further vectors. Instead of targeting circles by position or size, players would target by position, shape or opacity. Instead of growing or shrinking circles, players would transform shapes or change their opacity. The goal would be to capture shapes by increasing their opacity to 100, but the catch was that you could play defensively and decrease the opacity of your opponent's pieces. Furthermore, you would build sequences of four steps for each turn allowing more sophisticated strategy.

It had the kernel of a new direction, but was a little convoluted.

This morphed into a next mockup:

This lost the opacity vector, and simplified the shape vector to being about transforming between circles and squares in in two-parts.

Next came four-part shapes:

This was starting to get interesting. Players would seek to "capture" shapes by completing circles or squares in their respective colors. The sequencing opened up interesting possibilities, where the state of shapes would change between steps allowing players to do smart things.

I liked this because it felt like it aligned with the kind of programmatic thinking I want to encourage and introduce people to. Much of programming involves holding a piece of a system in your mind, then thinking a few steps ahead about how it's going to change – and what consequences that may have. For example, a programmer made need to anticipate the value of variable X at the end of 10 iterations of a 'for loop'.

I then decided that a goal to create shapes of either type (i.e circle of square) for each player was a little confusing, perhaps one player could chase complete circles, and one squares?

Going back to black and white basics, I mocked this up:

Now player one would try to capture white circles, player two black squares. The sequence element was in place. Actions would also include rotation (which wasn't possible with the two-part shapes). It began to feel like a good level of complexity to be challenging and strategically interesting, and I was hopefully it continued to express by goal of conveying programmatic thinking.

But would it be fun?

It was time to test. The next post will cover this.

Nought Point One.

Over the last couple of weeks I worked intently on putting together a first prototype, and getting it into people's hands for testing.

Concepting.

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).

Making.

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.

By the middle of Spring Break I had a game – you can see it here. And here's the main code.

Testing.

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.

Class feedback.

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?

Route.

Without constraints I could happily have spent the next three months (or years) reading and researching yet more on computer history, technology culture, programming, education, games... but it's time to shift gears.

_

Honing in.

I'm focusing on the educational aspect of my problem space, seeking to target adults who don't see themselves as technically-inclined. Many of us are (in some form) victims of an institutionalized divide between science and humanities– the 'Two Cultures'. My audience may suffer a deeply reinforced pattern of thinking in which math and science are perceived as alien or impenetrable. That represents a huge obstacle for my intended work, but also one to be sensitive to and mindful of in any idea or execution.

Psychologist Piaget has a concept of 'assimilation' in his education theory, in which he proposes educators 'use familiar examples to facilitate learning more complex ideas'. This reasonable premise led me to explore ways I could start out in a familiar space, and gently introduce computational concepts.

It's worth noting here that my aim isn't to introduce users to a programming language. In my examination of what a greater computational literacy might constitute, it became clear to me that an understanding of how computers work and what one can or cannot instruct a computer to do should come before anything else. Despite the greatest of intentions, this oftens feels missed from many recent 'learn to code' initiatives.

As outlined in this excellent article (and in far greater depth in Changing Minds by Andrea diSessa) we transitioned from a pre-literate society in which an elite of scribes held a privileged position to the widespread common literacy we enjoy today. But we are still at 'scribe stage' with computational literacy – in which an elite hold a privileged position, and others remain dependant.

My focus on adults is for a simple reason: while we're finally making progress with bringing programming into schools, technology culture is moving so fast that a number of lost generations (including my own) risk falling behind.

My mission statement:

Encourage and inspire a cultural shift towards two-way computational literacy, creating a more inclusive and participatory technology culture.

The familiar starting point will be a casual mobile game. I watch people playing these games on my daily commute in fascination. Many puzzle games involve light (and sometimes heavier) mental exercise. They gently push players along and up a learning curve. Successful games enable players to get lost in a 'flow' state. All these qualities seem ideal for what I wish to achieve.

My indicative direction is as follows:

Positioned as ‘pick up and play’ game rather than an educational app, the product will introduce a narrow range of programming concepts. For each turn, the player will need to construct some basic logic. Through this activity, methods of ‘instructing’ a computer to do things are exposed. Play should follow a learning curve, demand strategic thinking, but remain lightweight and fun. The takeaway, if successful, will be a small but inspiring insight into programmatic thinking.

I've developed a game concept and plan to test a paper prototype version this week.

Early design work coming in the next post...