By: Willem Delventhal
A few weeks ago I wrote a post about managing remote teams in which I mentioned “Celebration” as one of my top three tips. Today one of our community members asked me how I go about celebrating my team and keep them motivated. Here are a few ideas!
1. Call out and recognize the accomplishments of your team members:
Always be sure to call out cool stuff that people do. For instance, I’m consistently careful to mention who came up with ideas when talking to others, especially leadership. “Oh yeah this new system we’re building, which was Surya’s idea, is…” Also do this when talking to them 1 on 1. “I noticed that you added a new Discord channel and people seem to love it. Great work!” And finally, encourage them to do this for each other. This will happen naturally as you show it to be the norm, but you can speed it along by simply asking. “Did you see what Surya did? It was pretty epic!”
2. Compliment sandwiches actually work:
Compliment sandwiches, where you give a compliment followed by feedback followed by a compliment, work remarkably well for adults, not just for kindergartners. And it makes sense. We tend to remember “firsts” and “lasts” but everything in between gets a little grey. when you need to tell somebody that something needs improvement, start by telling them something they’re doing well. Then get into what could be improved, and frame it as such. It’s not a failure, it’s an opportunity for something even more epic. And finally finish with acknowledgement of their successes.
3. Sprint Celebrations:
If you are familiar with the concept of “Sprint Planning” (a scrum technique where the team decides what tasks need doing for the next two weeks) you’re also probably familiar with “Sprint Closing.” In a typical Sprint Closing people show what work they’ve done to hold everyone more accountable.
I often do what I call “Sprint Celebrations” instead. Instead of making it about accountability, make it about celebrating each other. Let everyone know that this meeting, usually about an hour, is exclusively to showcase what amazing stuff everyone accomplished. “Surya! What cool stuff did you build this week?” Add some clapping and jokes and suddenly you have an event people look forward to where they know they’ll get kudos from the team, instead of a chance for people to scrutinize them.
4. Make it fun:
And finally, just remember to enjoy your time working together. This means very different things for different people. My older brother loves an environment where people are kind of jerks to each other, but in fun way. Other people wouldn’t necessarily like that, but it worked for him and his team. So figure out what makes the work environment fun for your team, and then build towards that. Be a little silly where you can, and always stay patient and kind.
That’s all I have to say about celebrating for now! What are your ideas to encourage a culture of celebration?
By: Willem Delventhal
A new age question I hear a lot is “How do I run a remote team?”
Well! It’s a tricky one. But I am pleased to say that I have run a heck of a lot of teams entirely online, for the most part successfully. As I sit here sipping my coffee, I have compiled 3 quick hints for you to do it yourself well.
Hint the first: Autonomy First
One of the greatest challenges for remote teams is staying coherent and organized. In a classic office setting you can simply walk over to somebody’s desk and collaborate with them, or check for that thing you really need right this second. In online teams, however, people can and will ghost you.
So how do you keep everyone on task? Honestly, I have found that giving a high degree of autonomy has worked best for my teams. At first I would meet regularly with team members, check in on their work, ask what they needed. But more and more I’ve realized that by empowering them to seek out help when they need it, and otherwise letting them get to work, your employees and coworkers will really shine.
Hint the second: Fewer, more flexible meetings
In my first online startup I met with my team members once every morning, plus a 1 on 1 once every two weeks, plus an all hands once a week. Yeahhh. They hated it. And so did I, honestly.
These days I much prefer checking in with each other digitally, and saving meetings for the big stuff. The schedule I have found that works best is:
– One team-wide meeting to kickoff the Sprint at the start of a two week timeframe
– One 1 on 1 with my three core team members per Sprint (every two weeks)
– One “Sprint Celebration” at the end of the Sprint to showcase what we each achieved in the past two weeks.
This winds up meaning I only have 5 meetings with my team every two weeks. We of course wind up with an ad-hoc meeting here and there, and we collaborate extensively on our Discord, and they meet with each other as well. But Just 5 meetings cover 90% of what we need. Crazy, right?
Hint the third: Celebrate
Did you know that we tend to remember those things that have high emotional impact on us? This is why you can’t remember what you had for dinner last night, but you can remember that embarrassing thing that happened to you 15 years ago.
In our classrooms at the Indie Game Academy we ask all of our students to adhere to three Core Agreements, and the second of these is “Celebrate.”
By celebrating the successes of your team members and making sure to call out these successes to the rest of the team, you build a greater sense of camaraderie and kinship, which is critical in an online team.
And by the way, be sure to celebrate failures too. “X didn’t work, but we sure learned a lot!”
And that’s all for now
So you’ve decided to build a game. You have your genre, gameplay loop, visual theme, and monetization strategy down pat. All you need to do now is sit down and start writing… the story.
Yes, the story. Yes, even if you’re not working on an RPG, visual novel, or point-and-click adventure game. And yes, even if your game’s a simple platformer, or multiplayer FPS.
Story’s more important to a game than you think. It’s easy to look at the often toxic backlash against story-focused video games (especially with so-called “walking simulators”) and conclude that narrative must be a new thing in gaming, and, therefore—by extension—that both are mutually exclusive. Quotes like John Carmack’s infamous quip likening stories in games to stories in porn certainly don’t help, either.
With all due respect to Mr. Carmack (and none to toxic players who can’t fathom the existence of games that don’t cater to their exact tastes), this is totally bogus thinking. Video games and stories are intertwined, and they have been since the medium’s earliest days.
Decades before insecure fanboys started wailing against the developers of “walking simulators” for centering story and leaving out challenge, competition, and “traditional” gameplay, Sierra and LucasArts adopted the exact same approach for their point-and-click adventures. Not only have these titles’ pedigrees as “video games” never been called into question, players of a certain age consider them essential, “must-play” entries in the gaming canon.
Even before then, text-based adventures like Zork were bestsellers as far back in 1976. And going back even further, the tabletop games which directly preceded video games were story-centered as well. Even Chess, the grandaddy of modern board games, is an abstraction of a medieval power struggle.
True, a game should primarily be a game—you should never elevate narrative at the expense of the gameplay that makes your game fun to play. It’s also true that several early gaming classics got away with either a basic story or no story at all, yet weren’t any less fun for it (Super Mario Bros. Comes to mind).
That said, if you lack the AAA-scale budget required to create hyper-realistic, 8K ray-traced, sprawling open worlds, the easiest and most effective vehicle to immerse your players into your game is its narrative. A good story is also a sure-fire way to ensure players find the experience of playing your game meaningful, and will remember it for years (even decades) afterwards.
If you don’t believe me, look at every Game of the Year award throughout the past ~15 years, and notice how many of them cite these games’ well-crafted stories.
But… there’s a problem.
You’re not a “writer.” You haven’t written a story since your high school English class. Dammit, Jim, you’re a coder/designer/producer/etc., not a narrative guy!
Well, don’t despair! For I am here to give you a few storytelling “hacks” that will give your game’s narrative a huge creative jolt, yet are accessible enough that literally anyone can use them. Best of all, these hacks are either free, or incur a trivially nominal cost.
1. Remember Your Three “3”’s
These are your 3 Essential Story Elements, 3 Act Structure, and 3 Style Essentials.
The 3 Essential Story Elements are Setting, Characters, and Plot.
Setting simply means “world.” The world your story takes place in—whether it’s our current, present-day world, our world in another past or alternate era, or a galaxy far, far away.
Characters are the agents which figure into your story. Whether they’re protagonists, antagonists, foils, NPCs, humans, elves, aliens, or whatnot, building believable characters is essential to writing a good story.
Plot is the story itself—the sequence of events that leads to your protagonist (lead character) achieving their goal.
The 3 Act Structure is the simplest, most hassle-free way to structure your plot. You divide your story into three acts: Introduction (Act 1), Conflict (Act 2), and Resolution (Act 3). As the story progress, the plot’s main conflict gradually escalates until it reaches the climax at the end of Act 2 / beginning of Act 3 (in a video game, this would be the final boss fight). Once the climax is resolved, use the remainder of Act 3 to quickly wrap up the story.
The 3 Style Essentials will help you write simple, clear, and believable dialogue, exposition, and even UI prompts. The 3 Style Essentials are Voice, Tone, and Readability.
Voice refers to how different characters talk. Think about it. Some stuffy and posh aristocrat is going to speak very differently than a salt-of-the-earth factory worker, even if they’re speaking the same language. Hence, they speak with different voices.
Tone refers to how a single character speaks in a particular context. I’m going to assume you don’t speak to your grandmother the same way you speak to your friends. You speak to each in a different tone.
Readability is simply remembering to write in a way that sounds true to the character, and accessible to the reader—not to make yourself sound smart. To test this, have a friend read your script. If they have to pull out a dictionary at any point, your writing’s not readable enough.
BONUS HACK: If you’re writing in English and are struggling with writing more simply or concisely, try and use words with Germanic roots instead of Latin roots. To illustrate, we’ll use a popular nursery rhyme:
“Row, row, row your boat, gently down the stream…” [Germanic Roots]
“Propel, propel, propel your vessel, delicately across the estuary basin…” [Latin Roots]
See the difference? Now, this tip applies to English speakers, because English is a Germanic language. If you’re writing in another language, then make sure you choose words from the same language family.
2. For Worldbuilding, use World Anvil and Inkarnate
There is no writer worth their clicks that isn’t concerned with setting. And setting is one of those things that sounds really easy, but is actually really hard to do correctly.
Regardless of what setting you’re building—fantastical, realistic, or anywhere in between—you must always ensure that the world you create is internally consistent.
As an example: if you’re building a megalopolis in the desert, you’d better be able to explain (at least to yourself) how said city makes sure its population has enough to drink. Do they tap into an aquifer? If it’s a coastal city, does it have rows of desalination plants? Does it import water by the truckload, or pipe it in from elsewhere in the realm? Based on the recommended daily water consumption of 8 cups per day, how much water would it need to sustain a population of 20 million? What ramifications does this have to the city’s economy? What happens when the water exporter experiences a severe drought or political instability, and stops exporting this water? What political and military apparatus is in place to deal with potential unrest? Is there a precedent for such an event in the city’s history?
…it’s a lot to think about, isn’t it? Fortunately, while you DO have to think about these things, you DON’T need to include them all in your game. In fact, you should only bring in around 4% (ideally) to 10% (max) of the world you create into your game.
Still, if the very thought of hashing out these details is giving you a headache, fear not! Here are three hacks for you to try out:
First: Get organized. There are dozens of world building checklists and worksheets that’ll make sure you think of everything you need to think of. World Anvil is my go-to, but if you’re a minimalist, all you TRULY need is a pen and paper (or word processor).
Second: Create a map. Don’t underestimate how useful this is. Actually SEEING your world will give you a visual reference point for all your world building. And as a bonus, you can reuse your map as an asset in your game! Not a cartographer? Sign up for Inkarnate—creating a map has never been easier.
Third: Play Civilization. Pick a random map, random opponents, and random settings. Then, after each turn, write down a historical chronicle of what happened with your fictional civilization. By the time you reach the endgame, you’ll have a full-fledged timeline that can serve as your lore anchor.
3. For Character Creation, use a Tarot Deck
Ok, now hear me out here. I know this sounds a little woo-woo coo-koo. Whether or not you believe in the Tarot as a tool of divination is entirely up to you. Regardless, it doesn’t change the Tarot’s power and versatility when it comes to character creation.
Why does the Tarot work so well for characterization? Because it’s based on archetypal imagery. Archetypes like the Fool, the Wizard, and the Ruler transcend cultural and temporal barriers, appearing in mythologies and folklore throughout the world, through the eons.
So, how do you use the Tarot to create characters? Well, first you need to study up on the Tarot, because its imagery is very much wide open to interpretation, and can be hard to decipher at first.
Once you’ve got a good feel for it, lay out 8 cards, starting with the first card in the middle, then forming a counter-clockwise circle with the rest. The cards are as follows:
- What ties them to the story (love, money, revenge, etc)
- Their hobbies
- Their greatest desire
- Their biggest fear
- Their greatest strengths
- Their goal(s)
- Their shadow side
- Their biggest weakness (or internal obstacle)
Presto! By the way, feel free to adopt this draw to suit your style. For instance, combining Tarot with astrology is another popular method. None of this advice is set in stone, so make sure whatever you’re using works for YOU.
4. For Plot, use Story Cubes/Cards
Ok, so you’ve got your characters, and you’ve placed them in a setting. Now, what to do with them? Well, if you’re telling a story, you place them in a situation where they want something, but some external (or, sometimes, internal) force is preventing them from obtaining it. Bonus points if overcoming said obstacle involves your character(s) reckoning with or overcoming one of their flaws, traumas, or other shadows.
Really, as long as you’ve structured your plot properly (say, according to the 3 Act Structure I mentioned earlier), then it’s just a matter of placing your character in different situations where they have to overcome obstacles by way of personal growth.
But if you don’t know WHAT situations would work, try using story cubes to jog those creative juices. These are dice with cute little pictures on each side. Roll these dice, and try building a plot out of all the pictures you roll.
You may not end up using all (or even most) of them, but this is a great way to get started—or to break out of a rut down the line.
5. For Outlining, use Twine
I won’t say anything to you gifted writers who can just sit down and hammer out a novel from start to finish. You can simply skip ahead to the next entry.
But for those of us who aren’t that talented and need to plan and outline their stories in advance, let me let you in on something: Twine is your best friend.
Twine is a game engine built for narrative-driven, interactive-fiction type games. Think branching narratives, “Choose Your Own Adventure,” that sort of stuff. It’s not the only such engine, and it can be VERY buggy and temperamental. But it does have one feature to rule them all: VISUALIZATION.
Yes, with Twine, you can visualize your sequence of scenes—branches and all—with the click of a button. It’s an incredibly helpful feature, especially if you’re more of a visual person, or the narrative’s getting too complicated to follow through text alone.
Best of all, it’s free!
6. To get good at narrative, play a TTRPG
This here is the biggest hack for all you budding interactive storytellers: if you want to learn narrative design—like, REALLY learn it—play a tabletop roleplaying game. Think D&D, Call of Cthulhu, Star Wards, etc.
Better yet, become a DM/GM, write a campaign, and execute that campaign from start to finish.
Seriously. It’ll teach you EVERYTHING you need to know about narrative design.
It’ll teach you about world building. And characterization. And story structure. And most importantly, it’ll quickly get you used to the reality that players will almost never do what you expect them to do—and give you the tools to anticipate and adapt to this.
So if you’re serious about becoming a narrative designer, get thee to a D&D Discord server (or inquire at your friendly neighborhood game store) and start roleplaying!
(Oh, and actually create a narrative-driven game. You can do it with Twine in a matter of hours. There’s no substitute for experience.)
Want more storytelling tips? I am collaborating with my fellow writers at IGA to host a panel that’ll cover everything writing—characters, setting, plot, actually writing the script and UI, and game-specific narrative trends like environmental storytelling. To stay tuned, be sure to sign up for the IGA mailing list!
Imagine that you are an intrepid Pokemon trainer. You’ve just chosen your starter Pokemon and have confidently strode off into the luscious grasslands of the Kanto region. Suddenly an iconic musical jingle plays and your vision cuts to black before revealing your very first Pokemon battle. In front of you stands a Caterpie. And, long story short, your starter Pokemon proceeds to beat the ever-loving snot out of it. Poor Caterpie.
In the Game Designer’s Pokedex of prototyping techniques, Word Prototyping is the Caterpie. Small, approachable, easy to train and grow. Accessible by pretty much everyone. But also not particularly powerful or exciting, and not used by a terribly high number of trainers.
A Word Prototype is one of the simplest prototyping techniques out there, and it involves pretty much exactly what it sounds like. Rather than coding an actual playable version of the game, AKA a Digital Prototype, and rather than getting crafty with a representative mockup of the game, AKA a Paper Prototype, the Designer simply invents some stuff on the fly and speaks it out loud.
Okay that may be a bit of a simplification, but for the most part it’s true. A Word Prototype is simply a game concept that is actually playable, but only via auditory or written input and output. Most of the time this comes in the form of a multi-choice story or narrative that the Designer delivers to testers either out-loud or in written form.
For example, the Designer might have a cool new idea for a narrative arc in one of their games. Let’s call it Obegron Trail. It’s a remake of the classic game Oregon Trail, only in space. Because everything is better in space.
The Designer can quite quickly, often in under an hour, put together a Word Prototype that a tester could actually play. The Designer would generally start with a little world building. “Welcome to Obegron Trail! You are a space pioneer aboard a space covered wagon being pulled by some mystical space oxen. You are on a quest to follow manifest destiny, and reach the golden land of space California where you hope to find mountains of space gold.”
But this is a game, after all, and what is a game without player autonomy and choice? So the Designer moves on and starts to get the tester actually playing the game. “You start by choosing your profession. You can either be a space engineer, a space doctor, or a space janitor. Engineers can fix anything but are awful socially, everyone hates space doctors but they have massive quantities of space bucks, and space janitors are just solid, middle of the road people. Which do you choose?”
Along the way, the Designer takes the auditory input from the tester and actually incorporates it into the game. This helps give the tester some meaningful choices, and allows them to experience something vaguely approximating the fully published game concept. I have seen this used for a number of different types of games, not just narrative focused ones. For instance, I once saw a Designer use it to test a fantasy escape room concept. The tester started in a locked prison cell and had to tell the Designer what they wanted to do to escape. The Designer would then respond with what happened in the attempt.
It wound up playing a lot like an old-school text adventure game, a la Zork or Gnome Ranger, and by the end of the session the tester was giggling with excitement because they somehow managed to seduce a guard to help them escape. This helped to confirm that it was a promising game concept and was worth investing more time into.
You’d be surprised at the kinds of games you can put through this test. Puzzle games can be reduced to just a few meaningful choices that mimic the eventual puzzle gameplay. Strategy games can be reduced to just the barebones decisions that a player would make in a full, live action game. “You have 50 wood and 25 gold, but only enough time to build one building. Which do you build?” And so many other interesting ones. It’s a nifty little tool, and I highly recommend adding it to your tool-chest.
If you’re still unsure of what a Word Prototype looks like, there is an example of a fully playable Word Prototype at the end of this chapter. You may well recognize the concept.
Pros of Word Prototypes
The primary benefit of the Word Prototype is first and foremost time investment. An old mentor of mine, John Nelson Rose, who at the time of writing this is a Senior Technical Manager at EA, used to make up Word Prototypes on the fly. So his time investment per prototype was literally however long he’d spend playing the game with people. Remember that a big part of our job as Game Designers is to validate concepts as fun and therefore lower risk. Risk can be summarized as, “wasted time and money,” and so if you can spend 15 minutes to validate an idea before even investing in a full prototype, you can save a lot of time.
I also find that Word Prototypes tend to really activate the imagination of testers. Because they aren’t presented with any kind of graphical indication of how the game will look or play, the tester’s brain is free to fill in the blanks. This simple fact means you get tons of ideas of how to build the game that often vary dramatically. When you think about it, the console that the game is being played on is the mind of the tester, and therefore the game will look and play very differently in different people’s minds.
The final major benefit of a Word Prototype is that virtually anyone can make one on their own. With bulkier Digital Prototypes at least one engineer usually needs to be present to build a playable test of the game. This often also involves Artists, Sound Designers, Game Designers and more. And even with the smaller Paper Prototype, this often includes some visual design work that not every team member is capable of. But with a Word Prototype, anyone with a vocabulary and a spark of creativity can throw some words on a piece of paper and have a blast testing.
Cons of Word Prototypes
Alas, poor Caterpie, for they never seem to make it in the big leagues, do they? While many of my students at the Indie Game Academy love Word Prototyping for the fun and ease of production, they are truly unlikely to be found in established studios. The simple fact of the matter is: the data you get from Word Prototypes is wildly inaccurate. Think of that second pro I mentioned above: that because there is no visual data, people interpret the concept very differently from what the final product winds up actually being. This means Word Prototypes are riddled with false positives.
You may have thought Obegron Trail was a fun concept, but that is probably because your brain immediately filled the gaps in the prototype with exactly what you would want to see created. Our tendency to imagine our ideal version of Word Prototypes means that they are virtually never used alone. Even if a concept looks promising when testing in this way, it is essential that you then take the time to further test it. This may mean building out a full Digital Prototype anyway. This means those hours you saved could well become hours wasted instead.
Word Prototypes are also pretty awful at mimicking a wide variety of game types. They work well for pretty much anything that is narrative heavy and are decent for anything turn based, but the minute you get more complicated than that it becomes very difficult to translate the concept into a Word Prototype. Not impossible, but imagine trying to make one for Call of Duty.
When to use Word Prototypes
That being said, this doesn’t make them unusable, and I am a firm believer that they should be used more often than they currently are. Give the Caterpie its day, people! For instance, you COULD collect some data on the next Call of Duty. Say you’re trying to decide on the introduction to this new game. You could say, “You’ve just recovered from your drop out of the helicopter, and rounding the corner in front of you is a guard, armed to the teeth. He doesn’t seem to have noticed you yet. What do you do?”
For the most part, I find Word Prototypes most useful when used internally to validate ideas that you’re on the fence about. They are a quick way for Game Designers to bounce ideas off of their team members, and especially other Game Designers. “Hey Bob, I have this cool new idea for the boss fight. Can I walk you through a quick Word Prototype?”
They are probably not a prototype that you will create for every single one of your concepts, but you might use them to help filter the last few stragglers. Let’s say you’ve brainstormed 50 ideas and used filtering techniques to reduce those to just 11. But your target is only 10 concepts, so you’ve got to eliminate one more. This is the perfect use case for Word Prototyping.
Make your own Word Prototype
Now that you have a white belt in Word Prototyping, it’s time to level you up to yellow, senpai. Let’s take you through the process of actually building one.
We have prepared both a Worksheet (You’ll find it at the end of this post) for you to use that will take you through the steps below as well as an example Word Prototype for you to check out.
Step 1: Choose a Concept to Word Prototype
First, you need to brainstorm. If you have never brainstormed before, that’s a deep enough exercise that I could cover it in an entirely different blog post. But for the sake of brevity: start by simply quantifying your constraints, and then give yourself say five minutes to write down as many ideas as you can. In this case, your constraint is simple: you must be able to play the game via a Word Prototype. Once you have some concepts, choose one that you’re excited about (or perhaps on the fence about) and that seems like a good candidate for a Word Prototype. Then write the concept on a piece of paper.
Choose your game concept now.
Step 2: Draw your Core Loop
Next, define the core loop of this concept. Remember that a core loop is a diagram of the actions the player takes over and over again in this game. If you’re familiar with a state machine, it’s similar. It’s a diagram of the states the player can enter into and how they get there.
In Flappy Bird, a simplified core loop would be: jump, avoid pipes, get as far as you can. In Mario a simplified core loop would be: move right, jump over obstacles, ground pound enemies, collect coins, and reach the flag.
Defining your core loop is useful for many reasons, but one of them is to make it easier to prototype. After defining your core loop, you know exactly what is most important to test in order to validate the concept.
Draw your core loop now.
Step 3. Define your Testable Elements
A step often skipped by those who are fresh to prototyping is defining what information you wish to learn. Newbies will often spend days, weeks or months to make a playable version of their game and then just plop it in front of a player (or worse, themselves) and get generalized feedback. While this is still valuable, you can accelerate the evolution of your little Caterpie by simply defining what you hope to learn from your Word Prototype.
Remember that when prototyping a full game concept, you’re generally looking for three very important things: could this concept be fun, what are its magic moments, and what are its risks. Use these three prompts to help you think up what is most important to test. What are you worried might make this idea a bad one? What do you suspect could make it wonderful? Write down your top three testable elements now!
Write your top three three testable elements now.
Step 4. Create your Word Prototype!
Now that you have a game concept, a core loop to build the prototype from, and the top three things you want to prove or disprove about this concept, it’s time to write! Grab yourself some notebook paper or open up the doc we provided and get to work! Remember that the only differentiating factor for what makes a Word Prototype a Word Prototype is that our input and output channels are lingual. We use written and spoken words, with no visuals.
Typically this means Word Prototypes wind up like a choose-your-own-adventure. Start by writing an introductory blurb. Tell the player about the setting, and give them a mental framework of the narrative you are trying to tell.
Pretty quickly, within a paragraph or two, give them some kind of choice. Once they have chosen their path, progress the game forward a bit more. Explain new details, new events, etc. Ask them to make new decisions, and modify the outcomes of the game based upon those decisions. You can write down exactly what will happen given their different choices, or play it a little looser.
In fact, if you have ever prepared or participated in a Dungeons and Dragons campaign (or other roleplaying system) you’ll feel right at home here. Word Prototyping is basically just roleplaying with a more professional fit, and the skills you apply to one definitely apply to the other.
You want to set up enough detail to be able to easily play this game with a tester, but not so much detail that you waste a bunch of time writing things that never get surfaced. You can be very strict about choices, “You have options A, B or C” or you can be loose about it, “What do you do?” When you are more strict, you control the test better and get more specific data, but you also limit the player’s creativity. When you are more free form, you have to improvise responses more often, but get a wider breadth of feedback.
If you’re still not sure how to handle writing your Word Prototype, skip the next section to see an example. You’ll find a fully filled out and playable Word Prototype that uses many interesting mechanics to get your brain juices flowing.
Once you finish your Word Prototype, share it! You can post it in the celebrate_your_work channel in the Indie Game Academy Discord. Our community there is wonderful and you’ll quickly find yourself flooded with positive affirmations and feedback. You can also share it around using the hashtag: #igawordprototype to see other people’s Word Prototypes.
Step 5: Playtest your Word Prototype!
Now that you have a fully playable version of your game, find somebody who is willing to play! Just like Brainstorming, Playtesting is a massive concept to try to teach you in one small paragraph. I’ll have to write you another article soon!
In the meantime, the simple version is to: find someone to play, explain just enough about the game to get them playing, sit down and play together, try not to talk and only listen, finish playing, and finish by asking a few questions to answer your testable elements.
Do that two or three times, and you’ll have a pretty good idea of whether or not this is a promising game concept! Remember, even if the game sucks, that’s a success! Another concept crossed off!
So perhaps Caterpie is not so useless after all. They may not be the strongest, and the only useful skill they learn might be string shot, but they have a certain charm, don’t they? And they are immediately approachable, and easy to train. And hey, at least they aren’t a Metapod.
The Word Prototype is the simplest of the three major types of prototypes we will cover on this blog. They are made up of entirely spoken or written words, and offer a sort of gut check for concepts you are unsure about. They are extremely fast to create, and can even be made on the fly. This makes them a super low risk tool. However, they are also quite inaccurate, and hard to use on many types of games.
In the end, my hope for our little Caterpie is that it gets brought out and used in more places! Perhaps not in all the places, but definitely the right ones. Caterpie won’t win the elite four for you, but it sure will help you get through those first few grassy patches, and maybe even level up your starter Pokemon along the way.
If you have enjoyed this article, this is actually one chapter of a book the author is writing on the Concept Validation Funnel, a process by which professional game designers choose the best possible game to work on.
Should you want to get more chapters of this book free to your inbox, and hear about its progress, sign up for the Author’s Email List here.
Download our Word Prototype Worksheet here.
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 Indie 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.
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 Indie Game Academy. He writes about the lesser-known and unexplored aspects of gaming at https://gameandword.substack.com
By: Jay Rooney
Indie Game Academy’s professors offer priceless insights into the games industry more broadly, as well as what goes into making an individual game. Level 3, Cohort 4’s first professor, Anthony (“Tony”) Sharma, is an industry veteran, currently working at Wizards of the Coast.
In addition to attending his lecture, I was fortunate enough to sit down and chat with him about games, game design, and game careers. And now, I will share select portions of our 2-hour-long conversation with you.
GETTING HIS START IN THE INDUSTRY
Jay: Thank you for joining me, Tony! To start off with, could you tell our readers how you got started in the industry?
Tony Sharma: I used to tell people when I was growing up, “I’ll do one of three things when I’m older: I’m going to be a lawyer, a standup comedian—though I’m not very funny—or a video game designer.” And at the time, when I was growing up, being a video game designer wasn’t really a career path. There were probably a dozen game designers in the entire world when I was very young.
And someone saying, “Oh, I’m gonna be a game designer,” was like saying, “Oh, I’m gonna be an astronaut! I’m gonna be a rock star!” I knew it was what I wanted to do, and eventually, I got to go do it—due in no small part to my wife pushing me and saying, “Go and try, go out there! Keep, keep trying.”
But yeah, I probably would’ve ended up being a lawyer if nothing else. But I did get a computer science degree, so I guess I could have been an engineer. But I wouldn’t have enjoyed that as much as doing games.
Jay: Did you have a big break of sorts, a moment that really propelled you forward in your path?
Tony Sharma: Getting into the game industry is the hardest part. And especially so back in the day. I was working at Microsoft at the time. And while I was there, I was playing MechWarrior: Dark Age when it came out, and I went looking and found that one of the nearby game studios had a club where they were playing. And so I reached out to them and […] I started going over there. I became friends with one of their lead designers, and I would go there after work to go play with them.
And one of the times that we did this, I got dropped off at my apartment. And one of the guys said, “Hey Tony, have you ever considered working in games?”
And I said, “Full disclosure: that was part of why I joined this club at all, to network and make connections and stuff.”
He said, “You’re really good! You should consider applying, we have a game design position.” And I know you’re an engineer, and we also have an engineering position open.”
I interviewed for both jobs, and they offered me my choice of either, and I chose to do game design.
And that was the thing. If I didn’t put in the effort to go out and network, I wouldn’t have gotten that first job. And once I got that first job, I could leverage that into other jobs. Some of it is serendipity. Some of it is tenacity. Some of it—I actually think the bulk of it—is just being in the right place at the right time.
Jay: I have this theory for most creative professions, especially if you’re trying to build something for yourself or pursue a dream: We’re always closer to the brink of success than we think we are.
And it’s really tragic how often we give up on our dreams, when really, you never know if—even just a month later—something could have clicked.
Tony Sharma: Yeah. Something else that was really important was that, even though I didn’t know when it would happen—or if it would happen—I was always putting in the work. I was playing games because I enjoy games, but I was deconstructing them. I was reading up on them. I was talking to other people about, “Oh this game, you know what could be better about this?”
And when I did get the interview, I was as ready for it as I could have been. But even that didn’t prepare me for the realities of sitting down and making a game, as part of a team. I had to learn all the tools. There’s just a bunch of stuff I didn’t know.
But without that foundation, I wouldn’t have made it through the interview.
If I learned anything from formerly being highly competitive about stuff, is that success comes from effort. Everybody I’ve ever played any competitive game with, all of the highest level, highest-ranked, most successful people treat it like a job and just play the heck out of it. Talk about it, think about it, live and breathe it. And the people who don’t are less successful, because it doesn’t matter how naturally talented you are, if that’s even really a thing. There’s no substitute for putting in the work
And we live in a magical time where you can make games! You could just make games and you don’t have to buy an expensive dev kit. When I was working on Nintendo DS games, those dev kits cost $15,000—in early ’00s money, so that’s even more if you account for inflation. So the barrier to entry was very high.
Unity didn’t exist as a thing, so you didn’t have this free/low-cost way to handle all the boilerplate stuff that you used to have to do on your own. Putting a sprite on the screen is a trivial thing with middleware like Unity, but it is very complicated if you’re trying to do it on your own.
And think of hardware. If you get something to show up on-screen on the PlayStation, it won’t work the same on the Xbox. Whereas with Unity or Unreal, you can build, set your target platform, and move it over. So it’s a lot easier.
And as that transition happened, the bar for what I expect when I interview people has also gone up. If somebody tells me they come to an interview for an entry-level position and they say, “I wanna make games,” I’ll say, “What games have you made?” and if the answer is “None,” I’ll be like, “Do you really want to make games?”
Like, maybe you just want to be involved in games in some way, or you want to be in QA, or you want to play games. But if you want to make games, the barrier is so low now that even if the games aren’t great, you should be making them!
GAME DEVELOPMENT: EXPECTATIONS VS. REALITY
Jay: What would you say is the most common myth, or something people misunderstand the most, about being a game developer?
Tony Sharma: So, I get this a lot from people who aren’t in the game industry: they think I play games for a living. And I absolutely do not. I play games for research, I play games with my family, I talk about games a lot with people. But mostly what I’m doing, especially where I’m at in my career? Now I have a lot of meetings. I talk to people a lot, I solve problems, I remove obstacles. Occasionally, I get my hands dirty and do design, which I have to in order to maintain sanity.
But the idea that I’m playing games for a living is a thing that I hear a lot. And no, it’s not that at all. It’s actual work—and it’s hard, intellectual work. Because it is both craft and science all at once. Yes, there are lots of games that have sort of an ephemeral thing to it that makes them really special. But there are also games that just get fundamentals wrong, and are therefore terrible.
And there are many best practices for how to do things. But they don’t always apply all the time, depending on what the game is, or how it’s monetized, or what kind of audience it is. And you have to know all that stuff. You have to have a large mental inventory file system of mechanics and games that are successful and failed that you can draw from.
And that’s not something that you can really acquire without putting in a lot of work to do that.
And actually, one of the other things is: I typically am not able to enjoy games in the same way that a lot of other people can, because I find it very difficult to not critically evaluate the games that I’m playing.
So it doesn’t allow me to meet the game on its own terms, suspend my disbelief, sit down, and enjoy it. Some franchises do that, but I think it is harder for me to enjoy just in, to extend the cooking metaphor…
I think a very well-established chef is going to experience food differently. “This is slightly under seasoned,” or maybe, “This would’ve been better if they had used this cooking method for this,” or, “The plating wasn’t as good as it could have been,” or, “These things don’t pair very well together.”
And it’s not to say that I don’t have fun, but there’s always that part of my brain that is evaluating the stuff I’m playing. And I do think, in some ways, it’s a bit of a loss, not being able to just kick back and enjoy an experience, as a lay person.
The further away the game is from things I’ve developed, the easier I can do that. I love rhythm games. I’ve been playing them for a long time. I’ve never worked on a rhythm game. And so I can just play them and have fun with them, in a way that I can’t for strategy games.
LIFE LESSONS FROM DEVELOPING GAMES
Jay: So, let’s narrow it down a bit. What do you think is the best or most useful life lesson that you’ve learned from making games—not even necessarily from a design perspective—but from a more human or “life” perspective,
Tony Sharma: Everybody’s different, and my assumptions about people are almost always wrong.
When I was working on one of my first mid-core RTSs, it was a Facebook game. And we had a lot of direct connections with the players, and we would do new content updates about once a month. And you could spend between $5-$7K/month if you wanted to speed your way through the content.
And one time I messaged [one of those players], “Hey, far be it for me to discourage you from spending money on a game that I’m designing. But you know we’re not going to have another content drop for a month, right?” He’s all, “No, it’s fine. Besides, my wife loves that that I’m doing this instead of my normal hobby.”
And I was like, “What’s your normal hobby?”
He says, “Oh, buying exotic cars.”
And I’m like, “Oh yeah, this is significantly cheaper than buying exotic cars”.
And he goes, “And I get many more hours of entertainment out of this investment than I do those. Because I have to buy new ‘houses,’ go get more garage space to put the cars in. And I don’t actually get to drive them all that often.”
And so, everybody’s circumstances are different, and change over time.
So I try not to make too many assumptions about other people, and how much they can or can’t spend, or how much they do or do not want to play a game. What I do, is try to be as transparent as possible with people so that they can make informed decisions about what they’re going to do. I think that’s the fairest way to go about doing stuff.
It’s, “Here’s all the information. Here’s what you’re gonna get for your money.” If it’s a premium game, it’s, “Here’s everything that’s in the game. Here’s what you’re getting into.” If it’s a game as a service or, something with microtransactions, it’s, “Here’s what you’re getting for each of the microtransactions you could be doing.”
It’s one of the reasons why I don’t love loot boxes. Because a lot of that is hidden information. And I think even that’s okay if you’re like, “Here are the odds of what you’re getting.” And there are a lot of countries where you’re required to give those odds now.
So, you let people know the likelihood of getting a particular thing. So they know how much they’re actually gambling. So I think that’s the biggest thing.
ON THERE BEING A GAME FOR EVERYBODY
Jay: My wife’s not a geek. She’s not a gamer. But she did sit through the entirety of What Remains of Edith Finch recently. Because the narrative was what engaged her and kept her interested. What games might you recommend for a “non-gamer” to introduce and ease them into the hobby?
Tony Sharma: I say this all the time: I do think that there are games for everybody. To say that there is not a game for somebody is like saying that there’s no music for somebody. I think I would’ve suggested Edith Finch. I would’ve suggested Journey.
Jay: Yes, that’s another one. Actually, one thing that has engaged her is tabletop RPGs. She does seem to enjoy those because of again, the narrative focus. She very much likes stories.
Tony Sharma: Yeah. That’s one of my great loves. Stories. Not necessarily the stories in the game, but the stories that the game generates. It’s these shared moments that people have because they went and they engaged in this game—experiences. That’s really what brought me to games a long time ago and has kept me engaged with them.
Because I’ve been playing video and tabletop games for almost my entire life. We had a pong set a long time ago. When I was six, my older brother’s friend introduced me to Classic Battletech, the maps and miniatures game. And so I’ve been playing Battletech/MechWarrior in some form or fashion through most of my life.
One of the games I was third in the world at was MechWarrior: Dark Age. I got cheated out of first, which is a completely different story for another time.
Jay: Finally, if you could give a one-line platitude that distills the number one thing you would advise any of our readers who are also budding game designers… what would it be?
Tony Sharma: I think the most useful one is the topic of the lecture that I did just: eating is not cooking. Know the difference between the two, and learn how to cook really well. Figure out a cuisine that you like, and become exceptionally good at that cuisine, but don’t neglect all the rest of them.
Because having a broad range of skills is going to be useful because the people that you’re working with may not want to do the type of game that you want to do. And you need to be open and flexible to do whatever’s necessary—and to find joy in the work.
Back to cooking: even if you’re making a dish that you personally don’t like that much, the act of creating it should be enjoyable. Because if it isn’t, you’re trying to get into the wrong line of work.
So, if you can’t think of a cooking metaphor for something, you’re not trying hard enough. There’s always some kind of food metaphor for everything!
Tony’s Life Lessons from Designing Games:
- Don’t make assumptions about people
- Be transparent
- Be fair to your players, as much as possible
“It doesn’t matter how naturally talented you are. There’s no substitute for putting in the work.”
“Everybody’s different, and my assumptions about people are almost always wrong.”
“There are games for everybody. To say that there is not a game for somebody is like saying that there’s no music for somebody.”
“It’s these shared moments that people have because they went and they engaged in this game.”
“Eating is not cooking. And if you can’t think of a cooking metaphor for something, you’re not trying hard enough!”
TONY AT A GLANCE
Favorite Games: Monster Hunter, XCOM (The original 1994 one), Company of Heroes, Elite Beat Agents
Favorite Magic: The Gathering Set: Kamigawa: Neon Dynasty
Favorite MTG Color: Blue
Preferred Diablo Class: Rogue
Alliance or Horde?: Alliance
Preferred StarCraft Race: Zerg for mechanics, Protoss for lore
One-sentence advice to budding game designers: Eating is not cooking!
With the first post of our blog, we’re happy to announce that our 4th Cohort of Level 3 has officially begun!
If you are new to Indie Game Academy and what we do, Level 3 is our game development bootcamp, where students will learn how to run a succesful gamedev studio and publish a monetized game during the course of 3 months, during which they’ll learn the basics of programming, marketing, producing, publishing and more.
The students are sorted into Houses, specifically House Warrior, Rogue, Cleric and Ranger, and will be rewarded with points by participating in classes, completing tasks and just having fun! The house that ends the course with the most points will become the winners of the prized House Cup, with House Rogue being the current champions.
Here’s a Youtube video about what we do in IGA and the basic question of our program: How to start an indie game studio?
Also, feel free to join our Discord community, we have an amazing group of people that are always happy to help, share and celebrate your work.
We’ll be constantly updating you on the progress of this cohort during the next months, both in here and in our social media, and we will also publish articles of interest to the gamedev community, so make sure to subscribe!