For the past few weeks, we've been researching the tech we're using for the project. We've also been prototyping little mechanics and small game ideas, while focusing on our core pillars:
1. movement around the physical space; and 2. cooperation between a player in MR and other player/s in the real world.
I haven't been doing art aside from quick storyboard sketches from brainstorming meetings, so this post will be more production- and design-focused!
How did we deal with unfamiliar technology?
Mixed Reality (MR) is unfamiliar technology to us, so we had to research what we were working with first before thinking of a game idea. Otherwise, we would just be making an MR game for the sake of making it in MR, instead of creating something that wouldn't be as good in other medium. So, we agreed that we would set aside 1-2 weeks for just researching the tech, before actually brainstorming.
At some point, our programmers started to have a tough time focusing on how to test the tech, because we didn't have an idea yet. Soon enough, team team fell into a loop of "we don't know enough about the game" and "we don't know enough about the tech." We felt pretty stuck for a while.
We all agreed that we shouldn't keep feeling stuck, so instead of trying to think of fleshed-out game ideas, we decided to test out many tiny game mechanics based on what we already knew about the tech. Our workflow became a series of quick back-and-forths between 'seeing what the tech could do' and 'prototyping mechanics based on the tech.'
Looking back, I feel that we made a good decision to hold back on brainstorming too far. Personally, I had gotten so used to equating 'progress' with 'creating assets for a game and seeing it move' over the past three years, so I was itching to start making things. But I realized that as designers, we need to hold back on production and really plan things out, so that we don't realize our mistakes too late (and end up wasting people's efforts).
From small mechanics to medium ideas
I mentioned that we tested out many tiny game mechanics first, based on the our programmers' first pass tech research.
We knew that:
- the player in MR (who I'm going to refer to as "the MR player" from now on) will be able to see their surroundings and other people; - the MR player can physically walk around the space; - virtual objects can be obscured by real-world objects, thanks to the Zed Mini Camera; - the MR player could draw and do hand gestures, thanks to the Leap Motion; and - we wanted to avoid having a shooting mechanic, since it seems to be the common mechanic among current AR/MR games.
From these, we could already test out a variety of little mechanics. Using a GoPro to simulate a MR headset, we paper prototyped pointing, drawing, searching, hiding, etc.
After prototyping, we narrowed down which mechanics we liked best: searching and hiding. We also liked parts of the other mechanics that involved an "AI" -- mainly because we enjoyed playing with other "people." Through these discoveries, we set our pillars and narrowed our focus little by little.
What about art?
To complement the skillset of the artists of the team, we decided on a cartoony and simple art style. This decision goes well with our tech consideration: our game would need to have low-poly, simply-textured, and optimized assets so that it can run well, with as little lag as possible.
Going forward...
Now that we have a concrete design challenge, our efforts are much more focused. We've noticed this trend too: it's a lot easier to answer "does this idea fulfill our pillars?" instead of measuring the idea's worth by descriptors like 'good' or 'needs improvement.'
For the next few sprints, we will be deciding on a game idea we want to pursue. With our idea finally solidified, I will make mockups and concept sketches of the game that the team can refer to.
Σχόλια