What we learned from our first innovation Jam
Every year, we take a couple of days off to visit a design & tech conference. It's exciting: traveling, networking, listening to inspiring talk panels. But every year, we're left with a slight hangover, a stale taste and a small voice that asks uncomfortable questions: "what did I actually learn?" "was it worth the time and money?" "why, oh why did they take pictures at the afterparty?".
So this year, instead of checking into an overpriced hotel, we decided to keep it intimate and low profile. We booked a conference room in a local coworking space, set up our out of office Messages and spent four days working on a free, client unrelated project.
This is how it went down and what we took away from it.
Day 1 – So, what's next?
A thing we agreed on beforehand, was that we wouldn't choose a topic or project before the Jam had started. That might have been a mistake. We spent a lot of time debating and evaluating all the pros and cons of every amazing idea circulating the room. While we did apply the common "design-thinking-post-it-dot-vote-there-you-have-it" approach, nobody was actually happy with the outcome. In the end, we settled on a different Project then the one we voted on:
The next Quiz Duel
Let's create the next Quiz-Duel. A casual, asynchronous mobile game in which you compete with your friends.
After we finally decided what to do with the three days, the better part of the first had already passed. All while the actual challenge still lay ahead of us: how do you go about making a game?
There is a saying that goes something like "it's better to copy a good product, then to invent a shitty one." We made that our mantra for the rest of the day researching games and mechanics we could use for our project.
After we researched a few games with blueprints that could work for us, we went to the store and bought them. A necessary, but time consuming step. After we got back, we barely had enough time to play a couple of rounds before the first day of our jam would find it's end.
In the evening, there was one decision left to make. Which game would serve as the blue print for our project? We decided to go with "abalone" a game where your goal is to push your opponents tokens off a hexagonal board.
On the first day, everybody went home with mixed feelings. What had we gotten ourselves into?
What we learned from Day 1
- Obvious one, but in this case it came as kind of a surprise: before you get together with people, may it be for a hackathon or a meeting, it'll save everyone a lot of time if you make sure you define the goals as clearly as possible.
- Steal where you can, reinvent where you must. There are few things no one has ever done before. If you're tasked with something, chances are somebody at some point had the same problem. You'll be able to learn from their mistakes without making them yourself. Which will make your life a lot easier.
Day 2 - Play, Evaluate, Tweak, Repeat
We started the second day with a cup of coffee and a big jug of realism. If we'd keep moving forward at this speed, there's no way we'd finish our project in two days.
We used up a third of the time already, and so far we had nothing but then the knowledge that we wanted to make a "turn based strategy game based off the principle of abalone". We needed to work on the game design, the visual design, sound, a tutorial and on the digital prototype. So for the start we split up into two groups. A game design and a visual design team.
The Game Design Part
We figured the only way to make a game was to play it. So thats what we did. We took the rules of abalone apart and started tweaking them until the game got in a direction that felt like what we wanted to achieve.
Abalone is a strategy game where you think about your move for a long time. Then, after a lot of contemplating, you move your pieces. Problem is, a single turn might feel like it has very little impact. Games can take up to 50 minutes and tend to lose speed and flow as the board gets emptier. All those parameters aren't exactly ideal for an asynchronous casual game.
We wanted a turn to feel like it had a lot of impact, and we wanted the player to spend some time playing, rather then just moving one piece. So that when you pick up your phone, there was something to do. Therefore we set up rules that would let you take another turn when certain criterias where met, like pushing one of your opponents stones off the board.
Also we wanted people to experience a flow when playing, rather then thinking a lot about every single move. That's why we moved from a hexagonal field with 6 movement directions to a squared field, with 4 directions and immensely decreased the board size and stone count. Ending up with a 5 by 5 grid, and 16 tokens total, thus reducing the effort needed for every decision made.
Those two design decisions took the tension off of every single move, making you move your pieces a lot faster, chaining together moves and completely changing the feel of the game.
Finally, there where moments in the game where you felt like there was no smart move to make. This could drag on for a couple of moves at a time, making you feel like having little to no impact on the outcome of the game. We fixed this by adding the stack mechanic. A passive move where you can combine two of your stones to gain a larger one, increasing a players opportunities, and making him weigh quick wins against long term advantages.
The Visual Design Part
In Terms of visual Design, we were really mesmerized by the shiny, round, physical sensation of the black and white marbles of "abalone". A physicality and feeling we wanted to carry over to the screen.
First thing that came to mind was the skeumorphic design of the original iOS. Shiny, glossy surfaces, shadows and glows, that resemble the real world. The board would need dents for the marbles to lay in, and a physical edge for them to fall off of.
With those parameters defined, we tested different token designs. Do poker chips work better then marbles? Which are easier to read, which give a better feel when stacking?
While poker chips created stacks that where easier to count, they didn't give as much of a sensation when stacking. Also they gave the board a direction in which you had to look at it. Since our prototype was missing the network feature and would be played by two people sitting in front of each other, that meant one player would always look at the board upside down. Which is why in the end we stuck with the marbles.
In the late afternoon the game design parameters where set, and the visual design was at a state where we felt comfortable starting work on the digital prototype. There was still a lot of work to be done, but the second day ended on a way lighter note then the first. Maybe, maybe, we got this.
What we learned from day 2
- Talk is talk but doing is knowing. In the beginning, we would spent a lot of time discussing the possible impact of rule changes without actually implementing them. In the end it became clear that we could spent 15 minutes arguing without gaining any knowledge, or we could play for 2 minutes and know if the rule change was viable or not.
Day 3 - Everything is falling into place
From the very beginning day 3 had a different vibe to it then the other days. Every big decision was made, most of the "if's" and "then's" were tested, and all that was left was executing tasks. The room was a lot quieter and fell into a working rather then a collaborative atmosphere.
We simultaneously worked on polishing the prototype with effects and sounds, creating a little tutorial for our game, and expanding it's brand identity with a custom font, based on the game board. Why would you start designing a custom font before finishing the prototype? Mainly because we thought it would be fun. And let me tell you: that's what jams are all about!
When we tested the prototype in the afternoon, we were amazed by the fact how much the product gained from what most people would declare as "polish" and "gimmicks". Simple effects, like bursting a marble when it leaves the board instead of just vanishing it, didn't simply improve the game. They made it. Effects and Animations are the reason you're naturally able to follow what's happening, when before you had to pay very close attention not to miss anything.
We had to cut a lot of features and awesome ideas we wanted to put into the prototype. But in the end, we had a playable game, on our phones, with sounds, effects, and to be fair one or two bugs. Seeing and playing the product was a lot of fun and, needless to say, made us quite proud.
What we learned from day 3
- A Jam is great for acquiring new skills. Since you're crunching on a product that needs to be finished in a matter of hours, you will lower your requirements for quality and perfection. I cannot stress enough how important this is for learning new skills. The sense of achievement you get from finishing something, anything, no matter how objectively bad the result might be, is incredibly rewarding when starting to learn something. You often deprive yourself of that feeling by setting your goals too high initially. Later you'll too easily be frustrated if they seem impossibly hard to reach. The tight timeboxing of a hackathon gives you the blinkers you desperately need when approaching a new topic.
- Polish, Animations and effects aren't icing on the cake, they make or break a product. Of course this is especially true for games, but even in software you don't simply upgrade the understanding of whats happening with polish, you enable it.
Aftermath
We got together the next day for a little evaluation of our workshop. How did everyone feel the past three days? Was the innovation jam a success? What could we do better next time? Would there even be a next time?
I stated in the beginning that we initially had the idea of a jam as an alternative to visiting a conference. So let me answer those three questions from the start.
"what did I actually learn?"
- The importance of clearly defined goals and milestones
- Stealing where you can, and being original where you must
- The importance of prototyping
- Working with the Unity Particle System
- How to design a two player board game
- The power of polish and animations
"was it worth the time and money?"
To put it simply, yes. If you break it down to hard cash, I'd say that the complete jam, including food, games bought, and the rent for the room, was cheaper then a single conference ticket.
As for time invested: it is hard to measure the value of newly developed skills and the sense of inspiration tingling through the team with an hourly rate. All I can say is, I'm positive that we'll see the results of the time invested, in the output of the projects to come.
"why, oh why did they take pictures at the afterparty?".
We didn't.