ROBIONS

For this project, we were told to design for a chosen persona. Hence, drawing inspiration from our play experiences with our siblings we created a persona for our user.

We were also given a bunch of smart toys including Lego WeDos to play with during our brainstorming. While building with it, we were reminded of the joy of building robots and cars. This car built using Lego WeDos and coded in Scratch triggered the idea for the project. The idea was to navigate the Lego WeDo 'car' through different levels of a story collecting neccesary parts to solve puzzles.

We decided to make a game that involved fighting robots and monsters, or as we called them ‘Robions’. It had a modular board on which you could drive your custom built Robions and fight other Robions. Initially, the idea was that if you beat your opponent, the Robion would have to follow you around and help you defeat all other opponents.

The board looked something like this with tiles representing robo (industry) and ions (nature).

We built a prototype app experience to go along with it using Figma.

The Robion App interface allows you to input your personal collection of Robions and browse through the other Robions you have encountered. It lets you sync with your friends and record data from old games and compare high scores.

However, the main feature of the app is that it allows you to control your Robion as it moves across the board and to create visually exciting battle sequences as the physical Robions encounter each other.

When we presented this idea to the class, we were met with confusion on the interaction between the physical board and the digital interface. Based on this feedback, we decided to focus less on the digital interface, allowing it to be a simple controler while we further developed and modified the physical game. We looked at the interfaces of Cozmo and Vector for inspiration.

For the second iteration of our project we focussed on the physical aspects and the rules for the game. We built a prototype of the Robions and the board pieces.

We continued from the idea of ‘build your own’ robions and started designing the game around the idea of collecting pieces for your base Robion as the game progresses and competing against other players to build your ideal Robion combining a mix of industrial and biological parts. These pieces are being attached on by velcro in our current prototype but we envision them connecting using magnets in the final.

We got a lot of great feedback by testing our prototype with various people of different ages and from different backgrounds. Based on our observations of people playing and the unexpected obstacles we encountered, we kept modifying the rules.

Some new concepts we added was the idea of being able to flip the tiles in order to capture territory, the concept of points that you need to collect to win and worked on making the rules be more self-enforced by the nature of the parts themselves.

We playtested our prototype with Hannah Liongoren and her 4-year-old daughter Lumen. She told us she liked the physicality of the Robions and encouraged us to focus on the connections. She also gave us great suggestions on the next steps we should take and encouraged us to keep focusing on the physical over the digital. Her feedback was useful but since Lumen was a lot younger than our target audience, there were a lot of things Hannah had to help her with.

We also got feedback from Georgina Melone (VP of innovation at Hasbro). She told us a lot about the current state of the industry and different thing to keep in mind when designing for the future.

Adam Ferrando gave us more insight into game mechanics and how we need to think about rules and enforceability. He encouraged us to keep the game simpler and make the rules easier to explain.

At this point, we realized we needed to do more research on existing games that could help us figure out solutions to problems we were facing like rule enforceability and win conditions. Hence, we researched games like Catan, Monopoly, Monopoly Deal, Uno, Risk, and Cluedo. Doing so gave us some common terminology we could use and also a better understanding of which aspects of these classic games we wanted and didn’t want in our final version.

More research into the categories of games that existed helped us narrow down our focus to games that were combat or area control games as explained in this blog :

https://nonstoptabletop.com/blog/2017/7/30/the-10-types-of-board-games-everyone-should-know-about

For the next week, the three of us split up and came up with three different games based off what we had so far. We all came together to play these games.

For the next week, the three of us split up and came up with three different games based off what we had so far. We all came together to play these games. Sophia focused on the aspect of collecting territory or items, William focussed more on fleshing out the rules and cards and I worked on potential battle mechanics and the integration of rules into the the board.

Here are some pictures of the different versions we created and play tested with each other:

Giving each of us a chance to express where we saw this game going really helped bring a lot more new ideas to the table. We started to see a lot of things that we found engaging and a lot of other things that we started to reconsider wanting in our game. We explored more fully various ideas such as having rules on the board itself, capturing territory, battling other players, collecting resources, having action cards, collecting victory points, setting obstacles, reconfiguring the board, and having events.

After bringing together our various ideas and more playtesting and feedback from our colleagues and friends, we started to see an actual playable board game coming together. Here are some pictures of the various iterations and playtests the final version went through.

Finally, we laser cut and 3d printed prototype parts to get a better idea of what the final version would feel like.

We also made a comprehensive rulebook. A major change at this point was that we decided to incorporate an “AI” component that acted as a random event generator that affected the gameplay. A player took the place of the AI. The rules written in Blue are the instructions that the AI follows.

We presented and played our game with the class and other visiting students. There insights and feedback were extremely helpful. We gained a lot of new ideas and perspectives based on their interactions with our game.

Based on the feedback during the crit, we decided to reduce the amount of time it takes to set up the board and to explain the rules. By making territory chunks instead of having individual reconfigurable tiles, we reduced the time to set up the board. This would also help us with having fewer electronic components in the game.

Our next focus was to build an AI component for our game.

Our next focus was to build an AI component for our game. In order to give instructions to the AI or to bridge the gap between the physical game and the digital interface, we started experimenting with RFIDs that could be built into the Robions and Board pieces.

Our guest critic Cas Holman suggested that a way to make the game easier to understand and to make remembering the rules easier, we should focus more on the story aspect of the game, giving the players charectors and missions that are a lot easier to remeber than a list of rules. She also suggested we condensed the rules to something we could keep refering back to on cards instead of having a long rule book.

To do so, we started to write a narative to go along with our initial idea of habilitating land with a narative of industry and nature working together.This was the general storyline:

A scientist(AI) of the future creates sentient creatures known as Robions using both mechanical and biotech advances in a dystopian futurescape. These Robions have interchangeable parts and can have infinite customizability. They were created for the purpose of making the uninhabitable parts of the world habitable again by the use of their special abilities. However, the earth is a danger prone zone where you are fighting against natural events on a daily basis. A massive event happens that leave the Robions scattered and missing their parts. Now, they have to recollect their parts and fullfill their original mission of making the world habitable again. The scientist can contact all the Robions and broadcast (audio?) messages to them. He is trying to figure out the locations of all the missing parts. As and when he manages to track the location of the parts, he tells the Robions where it is located. After that, all Robions try to go collect these parts. Each Robion also continues trying to make the land they are on habitable.( their original purpose ) Every time they go to an habited land, they can charge themselves and are then capable of using their powers till the charge runs out. At random times, large scale disasters occur that effect the whole game play. The Robions may loose parts, territories, ability to move, location of parts, etc The game ends when the entire board has been converted. At this point, the player with the maximum points ( 1 per tile plus 2 per part plus bonuses as applicable ) The Best Robion gets presented with an award for doing the most to help the world and is hailed as a savior.

We struggled with the idea of how to integrate the storyline into the actual game play. We looked at games like Munchkins for inspiration. Some other games we looked at were Fluxx, Unstable Unicorns, Streaking Kittens, You’ve got crabs and Scythe.

This week, we learnt how to build our own Alexa skills. Taking inspiration from that and this Alexa compatible board game known as “When in Rome”, we decided to try having our game be Alexa compatible. This way, we can better integrate our storyline and maybe bluetooth connect the board pieces with Alexa to turn on and off lights.

This was the Alexa Skill we built to test out with our game. While initially, we tried to create the whole game as a single skill, it was actually a lot easier to create indivisual skills for each event.

We worked a lot on how events in our game would work. Each player rolled their dice at the end of their turn and when 2 or more dice had the same value, an event was triggered. This event would continue for a randomly generated number of turns. 3 events could take place simuntaniously. However, these were confusing to players and we went through many different tests and itterations of ways we could make it simpler.

However, when we tested our game with Alexa with our classmates, we actually found that they found the interaction slow and annoying. However, they did like the idea of having sound cues instead of a digital interface.

Hence, we decided to try making an app instead which would have sound effects as cues instead of relying heavily on dialogs. We went back to Figma to prototype it but due to the complexity of the app and our desire to have it act as a random generator of events, we moved it Lightwell.

We also decided to reduce the number of event that could occur at one time to only one. This significantly shifted the game play.

This was the version we used during the playtest at LMS school. We got a lot of great feedback on our game.

We took the feedback we got as well our obsevations through playing with the children at LBS to create further modifications and improvements in our design. However, I feel like we still need a lot more refinement and user testing with older teens to reach a design we can call 'Final'.

However, I learnt a lot from the process of trying to create this game about the challenges of seamlessly integrating the digital and the physical. The project took us down many unexpected paths and pushed us to go outside our comfort zone to create the best experience for our players,

I hope to keep working on and developing this project till we get to a game that not only do our players want to play, but also one that we enjoy playing.