How I Built a Full Game Prototype Without Writing a Line of Code

by Jay Rooney

For the longest time, I thought game development wasn’t for me. Not because I didn’t think I’d enjoy it, but because I wasn’t a coder.

For most of my life, the word “developer” was synonymous with “coder” in my mind. It was only very recently that I realized that term was so much broader.

Suddenly, I could write for a game, and I’d be just as much of a game developer as a programmer or game designer. So I signed up for Jili 77 & Scatter Game Academy, and started learning the art and science of game development.

My team was recently in the prototyping phase, which meant I had to build a fully functional game prototype.

Wait, what?

Prototyping for Noobs

If you’re not familiar with game development, it’s easy think of a game prototype as a tech demo. At least, that’s what I thought. But as it turns out, that’s just one type of prototype: a digital prototype. There are two more: paper prototypes, and word prototypes.

Word prototypes are what they sound like—a written description of the game. These can be straightforwardly descriptive, or utilize a branching narrative (much like a Choose Your Own Adventure book) to simulate the gameplay loop. Word prototypes are the easiest to make, but generate the least useful data.

Think about it: a picture’s worth a thousand words, right? So imagine 30 pictures per second, for five minutes. There’s no comparison. Still, word prototypes will do in a pinch.

Still, if you lack time or coding skills but still need to make the right impression (and get better feedback), paper prototypes are where it’s at.

Paper prototypes are limited only by your imagination (although, depending on your needs, drawing skills would help immensely). Often, paper prototypes are exactly what they soundalike: analog reproductions of your project’s gameplay loop on paper or cardboard.

These can be as simple as a sequence of illustrated screens, or as elaborate as a full cardboard 3D mockup with moveable elements. And despite the name, they don’t have to live on paper. You can create a digital paper prototype, if you’re so inclined.

In my cohort, I saw some very creative paper prototypes, including one made on Figma—a whiteboarding app popular with graphic designers, but not one you’d usually think of for game prototyping.

But wait—I’m a writer. Why did I have to build a prototype? 

Well, besides being a great learning experience, I built it to help our team—House Warrior, aka WONDER WARRIORS (represent!)—to decide on a game idea.

During the initial brainstorming session, we spat out around 50 game ideas, which we narrowed down to 10, and then again to 5. 

There are five of us on the team, so we each chose our favorite of the five finalists, then built them over the weekend for our cohort to playtest in class (playtesting may well merit a future article).

So, here’s how I did it—in convenient list form!

Step One: Choose Your Weapon(s)

After I picked an idea to prototype—a VR Steampunk Airship Captain Simulator—I had to decide on what kind of prototype to build. I chose to do a paper prototype, and it was a fairly obvious decision—I reckon it will most likely be for you, too.

The decision after was far more consequential—what would I use to build the prototype? Living on the opposite side of the country as my teammates, an actual analog paper prototype was out of the question (my drawing leaves a lot to be desired, too). So I had to do a digital one.

But what could I use? I wasn’t a designer, so Figma would’ve been too steep a learning curve for what little time I had (and I didn’t yet know you could use it for prototyping, anyway). I couldn’t use a “traditional” game engine like Unity or Unreal, because—just in case it wasn’t clear—I’m not a coder. But professional-grade writing apps like Scrivener and Ulysses will turn out word prototypes, which I wasn’t going for.

Fortunately, I learned about several different game engines designed specifically for text-based games. Since I was—and still am—a writer, I could map out the gameplay loop in the engine, and then use my storytelling skills to paint a vivid and detailed picture in the player’s mind.

The two narrative engines I experimented with were Inky and Twine. Just like any game engine—or any tool, period—they each have pros and cons. I preferred Inky’s user experience, stability, and syntax. But ultimately, I went with Twine because it had a visual interface, allowing me to visualize each scene and how it linked to the others at a glance. Twine was much buggier and way more temperamental than Inky, and gave me more than a few headaches. But ultimately, it worked best for my own workflow.

If I’d known that, it would’ve saved me about a dozen hours of work. So do your due diligence ahead of time, and save yourself the stress.

Step Two: Map Twice, Build Once

Once you’ve chosen your idea, decided what kind of prototype you’ll make, and figured out what tool(s) to use, it’s time to map out your prototype.

If you haven’t already, now’s the time to hash out your gameplay loop—this is the sequence of scenes and events your player will experience while playing the game. For instance: the gameplay loop for Super Mario Bros. would look like: Start -> Jump Around -> Stomp Goombas -> Eat Mushrooms and Flowers -> Reach Flagpole -> Repeat.

Usually, you’ll use a diagramming app to map your gameplay loop (or, failing that, good ole’ PowerPoint is always an option). 

But since I was using Twine, which uses a visual interface, all I had to do was create each scene, which took all of five seconds. Then I’d link each scene, which only involved putting text in brackets. Boom, instant gameplay loop.

Regardless of what you use, be sure to stick to the path you laid out on the loop. Scope creep tends to creep up on you (pun intended), and it will sink your nascent game idea before you can show it to the world. If you’re using Twine, this is ridiculously straightforward, as you’re always looking at your loop. If not, print out your gameplay loop or pin it to a floating window so you can quickly reference it as you build out your project.

You don’t have to think of things like character names, dialogue, or even themes (be they visual or narrative). Not yet, anyway. When mapping your prototype out, only concern yourself with your gameplay loop, and how the player will progress through it.

Don’t neglect this step! As much as you want to jump into actually building your prototype, resit the temptation. The more you plan in this stage, the more your prototype will fall into place later. Fail to plan, and you plan to fail.

Step Three: Pump Up the Game

Ok, now that you’ve got your game mapped out, and broken up into discreet scenes, now you can focus on the fun stuff: theme, visuals, setting(s), characters, relationships, and plot. 

Run wild. You’re only limited by your imagination and your proficiency with the tools you’re using. Trust your instincts. If your ideas are “bad,” your playtesters will tell you. Don’t assume that just because you think it’s a good idea, so will other people (and vice-versa).

Depending on which tools you’re using, you can get really inventive and use creative “hacks” to make up for not having a digital, playable prototype. Recall the prototype built on Figma, or the literal paper prototypes I mentioned earlier.

With Twine, I could’ve gone really ham if I had more time. Since it’s HTML-based, you can use any formatting and styling you can on the web. This includes adding visual elements, and even “gamey” elements like HP meters and inventories. In the interest of time, I had to make do with mostly my words—but know that this is available to you and your prototype.

Step Four: Bring a Buddy

Wait, hold up: if I’m not a coder, how did I use HTML with Twine? Well, I didn’t! 

Twine has a robust WYSIWYG (“What You See Is What You Get”) editor that makes adding things like variables and if/else statements easy and seamless.

Getting them to work, however? That was far beyond my pay grade. As I mentioned, Twine is very buggy and mercurial. And when the code invariably bugged out (#SorryNotSorry), I might as well have been translating the Dead Sea Scrolls. 

Fortunately, I was part of a team. A team that included coders! So I was able to get help ironing it out—and believe me, it was a doozy. No way I would’ve figured it out on my own (shout-out to Valencia—THANK YOU!).

Even if you’re not part of a bigger team, you have resources available to you! Ask your friends. Ask on a Discord server you frequent. Ask people on StackOverflow, GitHub, or a coding subreddit. Don’t think you’re incompetent or annoying for doing so—everyone needs help with something at some point in their lives.

Besides, people will be happy to help out. It makes them feel smart, and most folks like feeling like they helped someone.

So don’t be shy—your success could depend on it.

Step Five: Know When to Stop

“A work of art is never finished, merely abandoned.” ~Paul Valéry

Substitute “work of art” for “novel,” “film,” or “game,” and the adage still applies. If you’re creatively predisposed (and if you’re engaging with as supremely creative an act as making a video game, you most likely are), you know it to be true. You can revise any creative work from here until the heat death of the universe and it’ll never be done.

This means that if you don’t have a deadline, you’ll never finish your game. Or prototype, in this case.

Having a deadline does wonders for your focus. I don’t condone procrastination for anyone who values their sanity, but I’ll readily concede that there’s nothing like an impending deadline for getting your creative pistons pumping. Especially if others are counting on you.

Furthermore, deadlines help you properly finish your game, for similar reasons. It’s one thing if you’re working on a personal project, and have the rest of your life to get it out. It’s quite another if you’ve got artists, programmers, and project managers expecting your script or narrative at a certain date and time. 

Basically, you have no choice but to release the fruits of your creativity, no matter how incomplete it is. Not only does this actually get your game out into the world, but it also trains you to actually “abandon”—no, finish your projects.

Epilogue: Have Fun!

“Nobody knows what’s gonna happen at the end of the line, so you might as well enjoy the trip.” ~Manny Calavera, Grim Fandango

Far too often—and not just with creative folks—we get so fixated on the outcomes we expect from a project that we forget to enjoy the process of working on it. You’ll have a much better, easier, and more enjoyable time making games if you remember to enjoy yourself.

Everyone wants to make a splash (or make a lot of money). That’s totally normal, and totally fine. But we need to temper our expectations. Chances are, your first game will not be the next Elden Ring or Cuphead. Your first prototype could bomb harder than Diablo: Immortal. That doesn’t mean you wasted your time, or that the experience wasn’t worthwhile.

We’re always learning, even from our failures—actually, especially from our failures. Better to make mistakes early on, and learn from those mistakes, than to losing everything because your ultra-niche passion project didn’t have a large enough market to recoup its costs. 

Besides, just by taking the initiative to bring your vision to life, you’re already ahead of 99% of everyone who’s ever wanted to chase a dream or sell an idea. You’re doing all the right things, even if it feels like you’re doing all the wrong ones. Yes, it’s true—there’s always a possibility (often larger than we’d like to accept) that your prototype, alpha, beta, or even final release will be a total stink bomb. But that’s ok!

Pat yourself on the back, be kind to yourself, celebrate your wins, take your Ls, always be learning, and most importantly: HAVE FUN! These are among the fondest memories you’ll back on when you’re old. Enjoy every minute of them.

Jay Rooney is currently enrolled at Jili 77 & Scatter Game Academy. He writes about the lesser-known and unexplored aspects of gaming at https://gameandword.substack.com