The Eye of The Beholder
An RPG game using a DIY controller that emphasizes using hand gestures to involve the player in interactive dialogue and engaging combat.
See our Itch.io page!
My Role
A leader in this project from start to finish, my role in the small team changed over time. First, I wrote the story to serve as the backbone of the game. Then, I wrote and implemented the branching dialogue tree. We constantly pushed prototypes on combat mechanics for which I would conduct playtesting interviews to gain insight for the devs moving forward. Finally, I produced most of the visual art.
Product
The game is based off of an open source software called Beholder. The makers of Beholder sponsored my team to create a game that might attract more developers to use their computer vision software. Beholder uses your webcam to detect the position, rotation, and other attributes of markers that look similar to QR codes. We used these markers as wearable controllers for the player as they cast spells and choose what to say without ever touching their computer (only by using hand gestures).
Process
We knew from the get-go we would have to trim our ideal game down to meet our time constraints. We focused on the most essential parts first, adding placeholders in our code to come back to after we finished the MVP. As soon as we had something that someone could play, we put it in their hands, and I took copious notes.
An important piece of game design that is often overlooked is sound design. While I had our bases covered with SFX, we needed music (which is one thing I cannot do). I hired just the right person for the job. Utilizing my network, I tracked down a composer/musician whose style was just what we were looking for. Listen to this sound sample!
I publicized our game through channels like Reddit, GameDevs, Itch, and more places in order to gain a following. We wanted to promote the Beholder software so that other developers would want to use it for their own projects. Making our game and our code accessible for developers at any skill level was very important. This involved making well designed documentation as well as video tutorials.
Key Takeaways
We submitted our game to a competition called Indiecade, for indie game devs like ourselves. Our game did not rank and I have a few ideas why. First of all, at these game conventions, people are more used to something you can pick up on the fly for immediate entertainment. Our game was more campaign based with lots of spells and strategies that might take someone longer to get into and understand. So, the key takeaway is that our game was not catered to the dynamics of this competition. This is not necessarily a bad thing, but if we want to win next time, we should make a game more catered to who we want to impress by studying them thoroughly.
We also ran out of time on our polishing with combat and dialogue animations. Towards the beginning of the project, I was relaxed about objectives because it was not always clear what they would look like a week down the road. Now, I think that’s a poor excuse for getting too caught up in the quality of a feature when we should be staying lean and on track to iterate from the beginning. For example, had I carried out more robust tests on the dialogue system before the project really went underway, I would have known that my existing plan was not going to work. Maybe I could have found the solution sooner.
Hunter Allen-Bonney | Product Manager
