In 1943, during WWII, the United States air force was experiencing high rates of casualties. American bombers were being taken down in large numbers by German anti-air defense forces. Men were not returning home. In an attempt to minimize the losses, the US military sought the help of the Statistical Research Group, aka the SRG, at Columbia University.

Abraham Wald, a mathematician at SRG, was tasked with determining where to reinforce the planes with armor to reduce the number of casualties. He was given data on where all the planes that returned back from their missions were shot. When plotted on a single image, it looks something like this:

With the data in hand, Wald set to work.

Indie Games

Indie games are BIG, and you probably already know that. Some of the biggest video games released in the last decade, that you’ve probably played, have been made by indie developers.

The thing is — most of those games aren’t really indie. At least, not according to the original definition.

You see, indie games are so big now that the term “indie” has morphed in meaning. Originally, indie meant, “a game made independently, typically by a small team.” No publisher, no investors — just the team and their game. But now when you hear indie game, you’re less likely to think of the conditions of development and more likely to think of it as a whole genre of games with a certain type of ~vibe~ — some intangible quality that just feels indie.

Most games you would consider “successful indie games” today wouldn’t have been considered indie at all a few years ago. They’re often made by larger teams, with bigger budgets, funded by publishers or other investors, and given access to resources that wouldn’t have been available to anyone outside of a major studio a decade ago.

There’s a particular point in time where I think this shift started to happen, and that point in time starts with — Indie Game: The Movie.

Indie Game: The Movie

Indie Game: The Movie is a cultural touchstone for indie games. Released in 2012, the film follows three indie games and their developers — Braid, by Jonathan Blow, Fez by Phil Fish and Renaud Bédard, and Super Meat Boy by Edmund McMillen and Tommy Refenes.

These games are three of the earliest examples of truly successful indie games; so early that the release of these three games and this movie is when I think “indie game” went from not just a description of the conditions of development, but to a description of genre. Before these games were released, “indie game” wasn’t really a term most people were familiar with or used to describe games. Indie games existed, of course, but nothing that had the likes of Soulja Boy playing them online.

Of the three games featured in the movie, Super Meat Boy has the most complete narrative arc, beginning with development and ending with release. We watch Edmund and Tommy go through development of the game until they’re offered a great opportunity: Xbox, Super Meat Boy’s launch platform, is willing to include the game in a new promotion called “Game Feast.” The catch? The promotion is in two months, far sooner than the four or so months the game would need to actually be ready to release. Well, no big deal, they can just skip the promotion and release at the original time, right?
Wrong — if they miss this date, they can’t launch for so much longer afterwards that they would run out of money and become financially ruined.

The pair end up crunching in order to get the game out in time for the promotion. If you’re not familiar with what crunch is, it’s a term that refers to a typically months-long period of chronic over-work. We watch the pair’s mental and emotional health greatly suffer as they do this. Edmund talks about how in the height of crunch on Super Meat Boy, the only way he could find some solace was by filling the bathtub with hot water and then laying in it until it went cold.

It was a grueling time for the pair, but sure enough, they came out the other side with a finished game shipped in time for the promotion. In a bit of poetic cruelty, they didn’t even get the promotion in the exact form they were promised, and what they did get was late anyway — but it thankfully didn’t matter, since Super Meat Boy went on to outsell Braid and become one of the best selling XBLA (Xbox Live Arcade) games of all time.

Independent Failure

Indie games have gotten so big that in 2021, of the over 11 thousand games that were released on Steam, 98% of them were indie games. Sadly, though, only 8% of all the games released sold over 10k copies. [Source]

For some perspective, if you sold 10k copies of a game on Steam at, say, $5 a copy, you’d be looking at $50k in gross revenue. Pretty sweet for a solo dev, right? Well… when you factor in Steam’s 30% cut, about 15k, and then factor in income tax, let’s just call it 20% to simplify things, you’re looking at net revenue of 28k. That may still sound like a lot to you, but that is not enough to live on in most of the US. Not only that, but that’s not considering how the game will sell in the following years, especially when most of a game’s sales typically happen in the first month of release. It also doesn’t consider how much it cost to build the game — if you paid for licenses for any tools, or contracted anyone to help, you’d have to remove that from your profit as well. Very quickly you can start to see how it’s really not all that much money. Your game that sold 10k copies probably doesn’t even break even. Imagine how much worse it is when you don’t even sell 10k to begin with.

If you look on social media, especially YouTube or Reddit, you’ll find hundreds of posts from indie game developers with games that commercially failed discussing what they think went wrong with their game — trying to attribute their game’s failure to something tangible and within their control; an attempt to rationalize their failure.

They attempt to put these factors into a concrete list. Even though they failed this time, they’ve figured out what went wrong — “silly me,” they say, “I simply didn’t market my game! Now I know that I need to market my game, so next time I’ll succeed. I’ll finally be able to go full-time indie. If I just post harder, I’ll be fine.”

If you’re also someone who makes games (like myself), it can be easy to read these posts and get a little smug. “How foolish of them. Clearly this game was going to fail from the start — their art sucks! My game’s art doesn’t suck, and I know how to market my game. I won’t fail because I know better. I’m just like all the successful indie game devs. The world just doesn’t know it yet.”

Ironically, in the comments of many of these posts, or even in posts of their own, you’ll see commercially successful indie game developers warn others to avoid taking the same path. They offer a tough-to-swallow pill of realism: that there is no pot of gold at the end of the metaphorical indie game rainbow. Instead, it’s a pot of instant ramen noodles and a life of just barely scraping by. Even if you sell tens of thousands of copies of your game, which is already putting you in the top 10% of games, chances are it’s not enough to really live on, never mind save for retirement.

Yet, despite all of that — despite all the postmortems on failed games, despite the financial realities, despite the odds being so stacked against success, and despite all the warnings from those who were successful — people still want to do it. For every warning or failed-game post mortem, there’s probably 10 posts of would-be indies asking “how do I make a game,” “where do I start,” and “how much money can you make as an indie game dev?” Something is not clicking — it seems like more people than ever want to make indie game development their full-time job even when the overwhelming evidence says that they should not.

Survivorship Bias

When the military presented the data on where US planes were being shot the most to Wald, they thought it was obvious — the planes should be reinforced where the most red dots are! That’s where the planes are getting shot at the most, so it would make sense to reinforce those areas with armor. Right? Well, not exactly.

Wald figured out that the areas to reinforce were the ones with no damage. The logic being that the planes who were shot in those areas never made it back to be part of the data set to begin with — there’s no dots on the engine not because the planes weren’t getting shot there — but because those planes never made it back at all. Wald proposed reinforcing the engines with additional armor, and it ended up saving American lives.

Now, the story likely didn’t go down exactly like that. In my research, I learned that Wald actually used a statistical model to determine that the engine was the most likely area to be hit and the most likely to cause the plane to go down; he didn’t just look at the image of dots on a plane and use superior facts and logic to outsmart the military.

I told you the romanticized version of the story because it’s used as one of the primary examples to illustrate how survivorship bias plays out in real-world scenarios.

Survivorship bias is, “the logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.”

To give a relevant example: looking at successful YouTubers and assuming that it’s reasonably achievable to also become a successful YouTuber is survivorship bias. It’s easy to listen to successful YouTuber’s “how I made it on YouTube” stories and think it’s possible for you to do it, too. Often they have similar stories: they just started uploading good videos and people flocked to their channels. Maybe they attribute it to good SEO or trendy video topics. All of that advice can sound really basic — because it is. The problem is that you’re missing the stories of the millions of people who try and fail to also become successful on YouTube. You have survivorship bias — you’re only hearing from the people who already made it and not nearly enough from the people who didn’t, because they didn’t make it. There’s millions of people who have made really good videos that you’ll never watch — that pretty much no one will ever watch. Unfortunately, it’s statistically far more likely that you will never be a successful YouTuber.

Even more relevant to our main topic: it is statistically far more likely that you will never be a successful indie game developer than it is that you will succeed as one. Most of the stories you hear are success stories — unless you’re looking for them, you probably don’t hear any of the failure stories. And even if you do hear them, it’s easy to dismiss them because they seem so rare. The failures aren’t visible precisely because they’re failures — you’re working with incomplete data.

Indie Game: The Movie contributes to the survivorship bias of indie games — none of the developers failed in the movie. They all went on to not only have their games succeed, but they as individuals became household names in the industry. I believe it was an intentional decision on the filmmakers’ part as well. Here’s the secret: Indie Game: The Movie wasn’t always about these games and their developers. In fact, it was originally about a whole group of Indies and all of their games — you can see remnants of this in the beginning of the movie when other folks are interviewed about indie games as a whole. Those interview segments eventually dry up and the narrative moves to focus entirely on the developers of the three main games.

The movie came out as good as it did because of how they changed the focus from indie games as a whole to these three specific ones. It made for better pacing and a more interesting story — it follows the hero’s journey rather than being a purely informational documentary. You end up only seeing the ones who were successful.

Now, let’s put aside the likelihood of success in indie games for a moment. Even if success were easily achievable — what’s really in it for you?

Sticking with the examples in Indie Game: The Movie, Edmund and Tommy severely crunched for several months straight. Try sleeping for only a couple hours a night and spending nearly all of your waking hours working. Not talking to friends or family, not spending any real time with your significant other, not playing games, not watching TV — not doing anything but working. Now do that over and over, every day of the week, including weekends, for several months in a row. Now — add the pressure on that if you don’t do that, no matter how exhausted you get, how beaten and broken down you become — that you will lose your job.

That is sadly the reality for many people in the games industry, indie or not. But now add on the indie angle of the pressure: not only will you lose your job, but you’ll be financially ruined — like, in thousands of dollars of debt and with little to no safety net of any kind. Like you have thousands of dollars of debt because you’ve overdraft by buying Coke Zero, one of the only small pleasures keeping you going, every day kind of debt. That’s what Edmund and Tommy went through when making super meat boy. And so many successful Indies have gone through the same thing. Rami Ismail and JW, of the now defunct Vlambeer, talk about how they also spent months just eating ramen noodles and working on games. The truly sad part is that so many folks who have failed have gone through the same thing as well — their stories just don’t end with a best-selling game.

Yet, it’s easy to watch Indie Game: The Movie and walk away with this feeling that it was all worth it — that you would want to do the same thing if given the chance. Maybe you’re like 14 year old me and think “hey, it’s hard, but anything worth doing is hard! At least you’d be doing something you love.” To be honest, I’ve rewatched the movie several times over the years and did it again for this article (and the video), and I still found myself walking away thinking, “man, that would be pretty awesome.”

And that’s no mistake — it’s a really well done movie, and I don’t think it would’ve done as well as it did if the Super Meat Boy story ended with the game failing. It would’ve likely been too depressing for most people to want to watch.

“So what,” you may be asking. “The odds aren’t great, but clearly some people are still able to do it. There’s got to be SOMETHING they did that set them apart from the crowd.” And you’re right — all of these developers DID have things that set them apart from all the others:

Jonathan Blow:
* had parents who supported his interest in programming at an early age
* had already started an indie game company with a friend and failed, gaining first-hand experience in running a company and what not to do
* was supporting himself as an independent games contractor
* had made dozens of prototype games
* was known in the games community for starting the experimental games workshop at GDC and writing a monthly column for “Game Developer”

Phil Fish:
* had parents who supported and even shared his interest in art and games at an early age (his dad even translated Zelda I into French so they could play it together)
* worked at Ubisoft as a level designer for a time
* Worked with Renaud Bédard (among others) on Fez
* had a grant from the Canadian government to make Fez
* Won an IGF award for Fez before it released
* Released Fez after Indie Game: The Movie came out

Edmund:
* had been making indie games for years, helping to make the cult-classic Gish
* made a ton of flash games like Aether, Time Fcuk, and Meat Boy
* was the original artist and animator on “Braid,” though his work was later replaced by David Hellman’s

Tommy:
* had professional experience as an engineer in software
* later moved to games and worked on porting Unreal Engine 2 and HoopWorld for WiiWare

Super Meat Boy as a game had an Xbox timed exclusivity deal.

You might notice that none of the factors I mentioned have anything to do with the quality of the games. They’re all really about the circumstances of these developers’ lives. And I’m not trying to somehow shame these developers or say “a-ha! See? They didn’t really do any hard work, their games weren’t actually good — they just had all of these factors that gave them a head start!” They all are incredibly talented people who worked tirelessly to make incredible games, and they deserve every ounce of praise and recognition for that.

My point is that when watching something like Indie Game: The Movie, or when looking at just the successful part of someone’s story — you miss the bigger picture. You miss all the little factors that helped set them up for success in the first place. You focus on the end result and not the journey.

If you want to see what happens to the people who don’t succeed, Surviving Indie by James Cook takes a look at what happens to those who don’t make it out to the other side of success in indie games. Spoilers: it doesn’t end well.

Conclusion

It would be great if there was a way to identify the engine on the metaphorical plane of indie game success; if we were just able to point to the area with no dots on all the successful indie games and say “there, that’s where everyone else needs to put more effort and their games will succeed, too.” Sadly, though, there’s really not. If anything, if they’re being honest, most successful Indies would say that the engine is “luck.”

And while luck can feel like this intangible quality; unable to be effected by our efforts yet able to affect us in every way, I do think it’s possible to improve your luck, however incrementally.

You can develop strong skills in one or more areas of game development, form a really skilled team that works well together, post as much content about your game as possible online, or even show up to as many local events and expos as possible. None of these things replace making a really good game that people want to play, but they do help ever so slightly in making sure that people do end up playing the game you make.

There’s also something to be said about making games just for the pure fun of making games. All this time, we’ve been talking about commercial indie games. If you’re making games as a hobby, it doesn’t matter whether people buy it and play it or not if the goal is creative expression. And really, that’s what’s at the heart of it all — it’s why so many people want to make indie games, why indie game the movie is so inspirational; it’s that intangible quality that has made indie games a genre of their own.

Thanks for reading! This article was adapted from a video essay, which can be found here:

I’ve always wanted to be a solo game developer, but have never fulfilled that desire until recently.

My first time developing a game was during an online high school course, where we used an old version of Game Maker Studio to make simple drag-and-drop games. I remember being so excited to finally be realizing my dream of making games that I went online to learn GML (Game Maker Language, Game Maker’s own programming language) on YouTube and ended up making more complex games than the class required. I carried that passion and desire into Video Game College™ where I ended up specializing as a Producer (for those unfamiliar, they’re similar to a project manager in software or other related fields). From then on, I never really developed something on my own — I was always on a team, always supporting/leading the team, but never coding, creating art, etc. I thoroughly enjoy that role (and being able to work on a team is incredibly important!) but it’s always bugged me that I’ve never actually released a game that I worked on by myself.

After over a year of not touching game development, in December of 2019, I started a project called Shell Kicker. Taking inspiration from a “Bros. attack” in the Mario & Luigi series of games, I created a simple arcade game where the player has to “kick” a shell into a crate at an ever increasing rate of speed. The main goal: release a project that I worked on solo, start to finish. In this post, I want to talk through what I learned from releasing my first solo game project in the hopes that someone reading this can learn from my mistakes and motivate themselves to finish their game.

In order to actually complete the project, I intentionally kept the scope of the game as small as possible: the main core loop (tapping the shell, hitting the crate, tapping the shell, etc.) and a high score system. I added sub-goals during the development of the project as well:

1. Do pixel art animation
2. Release on iOS & Android
3. Integrate ads

It ultimately ended up taking me from December 2019 until the end of May 2020 to finish the project, mostly due to long periods of lowered motivation, other Life™ priorities, etc. I would spend a few hours on a random weeknight or weekend working on the project, and then end up not doing anything with it for a few weeks, rinse repeat. Eventually when the COVID-19 pandemic hit, I took the extra time to finish the project and ended up releasing it to iOS on May 27th, with Android following on June 4th.

So — what did I learn, and what can you learn from my mistakes?

Lesson 1 — I can actually do this!

As I touched on a bit earlier, I’ve never actually finished a project on my own. I’ve worked on and released projects before, sure, but nothing by myself. Working on Shell Kicker and releasing it was an incredible moment for me: I finally proved to myself that I can, in fact, develop a game and release it by myself.

One of my weaknesses as an individual is that I can tend to over-plan and not take as much action as I know that I need to. Finishing Shell Kicker got me over those feelings and helped me focus on executing rather than trying to plan everything out.

To anyone who is staring at the giant abyss/void that is game development, I wholeheartedly encourage you to take that leap and just start. It can be daunting, and there’s an infinite number of excuses you can make, but if you genuinely want to do this — go for it! You’re not going to be perfect at everything right away, and you’re not going to be able to build everything you’re thinking of — and that’s ok! Play to your strengths and scope small. If you’re good at programming but not so much art, then use a stock asset pack or make very simple art assets! If you’re better at art than programming, use an engine or toolkit that allows non-programmers to code without having to write out a single line of code!

As an aside — learning to accurately scope a game (or any project, for that matter) is a skill you build over time just like any other. My main recommendation would be to think of as small of a game idea as possible — and then chop that in half and do that. I guarantee you it’ll be more than you think. As awesome as that giant “RPG with 20 hours of gameplay” idea is, it’s just not a realistic project for a beginner to take on. You’ll learn more by quickly building smaller projects than you will spending 5 years on one giant project.

Lesson 2 — Discipline is key

Shell Kicker likely could’ve been finished over the course of a week or two, realistically, if I had spent an hour or two a night and a few hours on the weekends. However, I was inconsistent with my development time and ended up taking far too long to complete the project. The core issue was that I would “lose motivation,” or whatever the excuse of the day was. The real problem was that I wasn’t disciplined enough — I wasn’t structuring my time in a way that allowed me to work on the game; instead, I was leaving it up to when I felt like it (which is completely valid if this is just a for-fun hobby!) and leaving room for excuses.

For anyone pursuing a creative endeavor (game development or not) I would highly recommend setting a realistic schedule for yourself and being disciplined enough to stick to it. You don’t have to be perfect, especially if it’s just for fun, but being disciplined and consistent will ensure that you meet your goals and actually finish your project!

I’ve also heard of some folks that can operate without a specific schedule and just know when they should be working their game, resting, etc. Unfortunately, I’m not one of those magical people, and I have a feeling most folks reading this are not either — so a schedule it is for the rest of us.

Lesson 3: Follow my own advice

In the past, I’ve given various pieces of advice to other game development students; things like, “make sure you test early and often,” “be objective in your analysis — make sure you’re collecting data,” “market your game!!,” etc.

On this project, I neglected to follow that advice. Since my goals were a bit more basic and weren’t as focused on releasing a highly-polished product, it was easy to neglect those pieces. I think I made the right decisions for this project in terms of scope, but I know that I need to focus on doing these things for my next projects if I want them to be successful. It can be difficult and intimidating to let other people play your game, or feel like you’re being annoying on Twitter by constantly tweeting gifs of your game, but they’re all necessary steps in commercial game development.

I highly encourage anyone reading this article that is interested in game development to research and start learning! There’s a LOT of resources out there that will help you get started. I would suggest starting with Unity, GameMaker, or some other engine and running through some tutorials on YouTube. You’ll quickly learn the basics and start branching out into more complex areas and soon be able to make something of your own that you, too, can release!

You can do it.

(If you’d like to skip the intro. and context for this series and go right to the post mortem, click here)

People who know me personally know that I’ve structured myself as more of a producer/business-type than a designer or developer as of late.

Having focused on production, running a business, finding contracts, etc., my coding and design skills have atrophied. Being frustrated with this and wanting a solution, I’ve decided to begin working on one new prototype every week. Inspired by JW’s 300 prototypes in a year and Rami’s challenge to Adriel for becoming a better game designer, I set out on a similar challenge to better my own design sense.

I’ve decided to do the following:

1. Begin working on a prototype on Saturday
2. Work on the prototype for at least two hours per day
3. Finish on Friday
4. Upload the game to my itch.io page
5. Write a post mortem on my medium blog to accompany the game

Questions

With each prototype, I’m structuring my mindset so that I’m answering a question with the prototype. This article describes it pretty well, but here’s my interpretation:

By asking a question, I mean asking a critical question about the core mechanic/identity of the proposed game with the goal of honestly determining if the idea is worth pursuing/changing. For example, one question you could ask and answer with a prototype would be, “is swapping between colors/dimensions while shooting fun?” That question would then be the direction for building your prototype with the goal being to find the answer. This helps with building focused prototypes that find the core of your game rather than adding a ton of junk that’s completely irrelevant to your core mechanic. It also helps avoid building a prototype for the sake of building one (i.e. “This idea is great! Let’s prototype it so we can say we did and just move on to full production!”). Having this honest, critical eye on your prototype with the goal of “finding the fun” by answering your question(s) can help avoid wasting time and money building something that isn’t actually that good. In other words, it keeps your scope down to a somewhat realistic level that you can actually manage.

Having this honest, critical eye… can help avoid wasting time and money building something that isn’t actually that good.

Post Mortem Structure

For each post mortem (including this one), my structure will go as follows:

1. The Question (see above)
2. The Process
3. The Good (what I liked)
4. The Bad (what I didn’t like)
5. What I Learned

This is a similar structure to what Rami talked about in the video I linked to earlier. Rami’s structure is a bit different, but I think the first two are just as important for contextualizing and documenting the prototype. The question I ask is presented to reinforce that mindset for me; I find it valuable to think of prototypes in those terms and want it to become second nature for me. The process I go through is useful for documenting how my process has changed over time for myself and for educating younger devs that may come across my posts to understand how little (or much) they need to do something similar. The rest are useful for obvious reasons; they document my thought process over time and encourage critically analyzing my work so that I can identify my strengths and weaknesses. However, I removed Rami’s “what I could do better next time” as it could be interpreted as either “if I had a chance to remake this” or “what to do on the next project.” I feel the latter can be too broad depending on what the current and next prototypes are, and I feel the former can just be lumped into “The Bad” as a solution follow-up.

ANYWAY, with all of that general context for this challenge out of the way here’s the actual post mortem for the first prototype:

Brief description of the prototype for context: it’s a platformer where you can throw an object and hold the throw button to hold the object in place. You can then jump on top of the object to jump higher or farther.

The Question

With this first prototype, I was initially inspired by the hat throwing mechanic present in Super Mario Odyssey.

Watching it in motion, I thought that creating a platform and then jumping off of it to reach greater heights looked incredibly fun and could make for some interesting platforming situations. So, the question I came up with was: Can I make a similar mechanic in 2D fun?

The Process

For this prototype, one of the subgoals was to refamiliarize myself with game design, coding, etc., so I used GameMaker Studio 1.4, which I’ve been familiar with for a few years. Rather than try to add the additional challenge of learning a new engine or language, I wanted to stick with something I could relatively quickly un-atrophy. GameMaker also makes it much easier to quickly prototype something in 2D, whereas something like Unity would take a bit longer to achieve a similar result.

All of the art was super basic square sprite art for the sake of simplicity and time (I’m by no means currently a great artist) and done in Photoshop for documentation and workflow purposes, though they could’ve just as easily been done in GameMaker’s own sprite editor.

For task creation/documentation, I just used a piece of notebook paper and a pen (more formally known as the Organic production method). I could’ve used something like Trello, but the amount of overhead involved just wasn’t worth it for something this small and experimental.

For time management, I generally use a slightly modified version of the Pomodoro Technique. While I didn’t use it as strictly as I would’ve liked, I still worked just fine without using it much. I attribute that to the motivation, passion, and excitement I had for working on The First Prototype of the challenge. However, as many others have said, discipline > motivation, and that will hold true for future prototypes. Additionally, I had more free time for this prototype than I will future ones, so I think Parkinson’s Law had a bit to do with it as well, which encourages my future stricter use of Pomodoro.

Of minor note as well is my use of Github for source control; while I never needed to revert or branch or anything like that, it was still worthwhile had something gone horribly wrong.

The Good

With this prototype, the main mechanic was pretty solid from the start. Even from the very first build of the prototype where it was ugly boxes and an empty room with just a floor and the main mechanic, it was still fun, which I feel is a strong case for a good mechanic.

I gave the throwing mechanic multiple uses/interactions; you could use it to jump higher, jump farther, or hit objects (walls to make it bounce back quickly, switches to trigger an event). The higher/farther is kind of a cheat, as they could be categorized as one function, but more on that later.

I added a “forgiveness time” to jumping when falling off of a ledge. After falling from a ledge, there’s a 20 or so frame delay that the player can still jump. This makes the game feel “more fair,” when in fact it’s actually being quite forgiving. It’s small enough where the player won’t notice it, but long enough to reasonably accommodate the player’s reaction time.

I juiced the visuals/effects of the game well. When jumping and landing, the player has squash and stretch. Every object has a drop shadow behind it to stylize the visuals a bit more past the basic colored squares. If the level is larger than the default display size, when the player moves and the camera needs to follow, the camera lerps/lags behind for a “smoother” camera effect.

The Bad

The throwing mechanic could’ve been pushed even further with more uses for it, such as more ways to directly interact with it (jumping under it?), more objects to bounce it off of for interaction, etc. I had initially planned for adding some sort of collectable to collect by throwing the object at it, but it was a bit out of scope and not wholly necessary for the prototype. I also considered adding enemies that could only be defeated with the throwing mechanic. This all goes back to a design principle I’ve heard a few times before: every mechanic in your game should be able to be used at least 3 different ways (I’ve heard it from a number of devs, but the main one that sticks out in my memory is Edmund McMillen, so I’ve provided his explanation).

The switches only move one type of block in one specific manner. I could’ve added more types of blocks that move in different ways, different switches for different blocks, etc.

The squash and stretch could’ve been pushed even more by allowing for horizontal collisions to result in a similar effect. Currently they’re only vertical, but having some sort of effect would make horizontal collisions feel less artificial.

The tutorial could’ve been done miles better. If I had the time, I would’ve implemented a “dynamic” tutorial that gave prompts when the player needed to perform an action and get rid of them when the player had fulfilled the requirements. However, something like this would take awhile to implement and would need heavy testing to confirm it not only worked from a technical standpoint, but also from a teaching standpoint (as all tutorials do, which is why there’s so many bad ones).

The throwing mechanic was pretty poorly programmed; in the spirit of “quick and dirty, just make the thing work” I used a pretty method of making the mechanic work. Throwing the object itself was fine by prototype standards, but what wasn’t was shifting the speed at the arc and deleting the object after it was no longer useful to the player, i.e. it had returned and gone past the player. Duct tape code is an understatement for how I did this one, as I used both speed and a timer that somewhat arbitrarily counted down after the object hit a certain requirement of speed, location, and direction. As a result, the following could occur: Player throws object and holds it in place > player jumps past object > player waits a few seconds > player releases object > object deletes. You can see how this would be pretty annoying to a player if they intended to use the object after letting go.

The actual physics of the game could’ve been done miles better. I had plans to rework them, but the amount of effort and time needed to refactor all of that would’ve simply taken too long. As a prototype, the “quick and dirty” mentality was followed, so attempting to rip out the physics and implement something better was just too time-consuming. If I could’ve done it, I would’ve added a higher terminal velocity for falling, added friction and acceleration to general movement, and added a delay when changing direction from right to left and vice versa (i.e. the little animation common in platforming games when the player moves in another direction to indicate the transition and make it less jarring).

Level design was also lacking and could’ve been done much better to make the game a lot more interesting. The main mechanic was fun, but often it’s what you do with the mechanics that make the game interesting, not just the mechanic itself. Obvious, but it can become pretty easy to forget when you’ve got tunnel vision after staring at a project for a week straight. In terms of improvements, I think the game needed more interesting platforming challenge designs that pushed the player’s skill with the throwing mechanic. However, during development, I worried that the physics’ relatively slow-paced-ness clashed with that type of level design and lent more to a puzzle game. Which then brings into question the whole pacing of the game, and we then go down a pretty deep rabbit hole. I’m still not sure if the game would’ve been better suited to Meat Boy or INK-style physics or as it were, but that would’ve been a great prototype question to ask and answer.

In this case, for validation, I could’ve set specific goals/target metrics to use when testing with others. For example, “testers play for at least 30 seconds or more.” Doing this would help define the quality/promise of the concept; however, for my purposes, I felt it was a bit excessive, at least for this first one.

What I Learned

I re-learned a lot about programming in general, especially with GML (GameMaker Language). Not so much a new thing, but it was a useful refresher nonetheless, which was one of the subgoals of the project regardless.

It is, in fact, possible to “find the fun” as early as just having the main mechanic in the game and not adding a bunch of flashiness to the game. I had my doubts before this, but this prototype really proved to me that it does happen.

When on such a limited time, don’t bother doing things that won’t add all that much to the game that could be done in other, less infuriating ways. My prime example of this was with the art. As I’ve mentioned, I’m not a great artist, and so creating art not only takes me a long time, but it never looks nearly as great as I want it to. I spent an entire evening trying to come up with a character I could easily sprite out. I had spent quite a lot of time painstakingly trying to come up with an interesting world and environment with some sort of “story” to justify the mechanics because I felt it had to be done to stand anywhere close to other “successful” jam games or prototypes. However, I realized that by spending all that time, I was wasting time I could be spending on actually improving the game in ways I could realistically do.

Not so much directly about the project and the game dev process itself, but I realized how important breaks and getting outside of your work environment really are. It’s something a lot of devs (and people in other disciplines or fields) talk about, but it’s not something I ever truly internalized. A few times while working on the project, I left my working environment to go outside and take care of errands or into the next room to do something else unrelated. I was amazed at how quickly I started getting new ideas, solving roadblocks I was encountering, and feeling generally better. The week prior, I had gone for walks and out to different plazas, and I had the same effect but even stronger; turns out not staring at the same screen all day and actually doing stuff outside is healthy!

That’s it! Thanks so much for reading this! If you’re interested in following my challenge as it happens, this blog is where I’ll post all the post mortems.

If you’d like to actually play the prototype, here’s the itch.io link: https://tylerehaddad.itch.io/prototype-1