You are either a really dumb tech out to prove your boss wrong, or you’re just a really dumb tech who’s about to be fired. Maybe if you can do some damage and not get caught or killed you’ll show your boss what’s what. Which you are on your way to do. That is if you can remember how to close all those stupid programs and get the heck out of dodge before the thing in the room gets you…
Test your keyboard command skills in this fun and short gamebook adventure featuring keyboard controls!
My contribution: Everything! I.E. Sole game developer (with the exception of the theme that molded this game which was provided to me by Jose Zagal)
Tools used: Unity (created the game cover image),
C#, git, brains, Quest, Chrome 😉
Platform: web browser
Genre Inspirations: Text adventures, gamebooks, fighting fantasies
Controls: Read and click! (You can do it!)
I hope you manipulate your way to a happy ending…
What Inspired Me
I was tasked with making a game featuring a keyboard. After several failed experiments I realized the game I wanted to make wasn’t so much about showing a keyboard in the game, but having the avatar use a keyboard in the game. A game book was the perfect solution!
A few weeks back my boss suggested I make a game about trying to exit from Vim properly. The idea intrigued me so I filed it away. When I was tasked to make a game featuring a keyboard this idea came back to me.
What I Did
I struggled a bit with making this game. I kept playing with 3D objects in Unity, but never really made a game. I thought about making different games, but I knew that I really wanted to make a game based off the Vim idea. It wasn’t until I realized that I didn’t need to the player a keyboard in order to feature it that I finally came across the right game engine: Quest. Even then I ended up choosing the wrong game type (text adventure), but it was because I felt that a gamebook was too simple.
I had envisioned a game with open-ended input. But when I realized that that was really just making an infinite multiple choice, I realized that simplifying the choices didn’t break the idea of the game: to tell a story. And that was best suited in the gamebook type.
After that the game came together rather quickly. I have always enjoyed writing (if you couldn’t tell by my blog), and was even a professional writer and editor for a while. It was nice to get back to something I enjoy in a creative way and be making a game at the same time.
As far as narrative goes I was really aiming for the player to step into the shoes of a dumb character.
What I Learned
“…It’s important to use a game engine that is designed to support the type of game you are aiming to make.”
I think the biggest thing I learned is don’t shove a game idea into a specific game engine/platform. That was what was holding me up the most. My game simply didn’t fit into Unity nor a text adventure. Which the first felt strange to me as I’ve never made a game before that I felt wouldn’t work in Unity. Now that’s not to say that I couldn’t have made the game in Unity, but I think it’s important to use a game engine that is designed to support the type of game you are aiming to make. Once I found the correct engine the game came together quickly and I got to play with what I really wanted to make!
“To feature something in a game you don’t have to actually see it!”
To feature something in a game you don’t have to actually see it! This stretched me mind! I got stuck on the idea of showing a keyboard in my game, but when I finally stepped back and let the avatar be the one to see and use the keyboard that’s when I hit gold.
“There’s a difference between a bad player and a dumb character.”
There’s a difference between a bad player and a dumb character. I think the hardest part of designing and writing this game was the balance between the player playing a dumb character (what I was aiming for) and the player feeling dumb (not what I wanted). I think in a couple spots this could have been improved. For instance I could have allowed the player to select the correct choice, but the avatar still messes it up. Or instead of giving correct answers each time I could have given just part of the answer, letting the player pick the part that is right, and allowing the character to mess it up. This was a fun challenge, and since the game is entirely text based the game design had to come out in the narrative after the choices were made. That’s also where the narrator comes in.
I wanted the narrator to break the fourth wall, so to speak, to add humor, but also to show the player that they are different from the character they are controlling. I felt very quickly into making this gamebook that I was writing a story similar to the game The Stanley Parrable. That was the feel I was going for in this experiment.
Ideas for future development
I like keeping this game in the text version. So I would fill it up with more narrative. The quest engine also allows for adding audio and images, even videos. I think it would be neat to add those in as well. I think the biggest design detail though would be to keep that distance between the player and the avatar while still allowing the player inside the character’s shoes.
If I made it graphical (which I would do after filling in more of the narrative to test out more ideas in an easier to develop and iterate environment), I would have physical things that the player could do (like pound on the keyboard), visual payoffs (like cool effects when answering correctly), and adding some eerie music, and of course some creepy critters…