toffwee's blog

failing to fail fast - why big projects end in heartbreak

this happens a lot!

https://www.youtube.com/watch?v=GhTAoilsFUs

this video by jdh is extremely cool, and i do not mean to slight him in this post, what he's done was probably a great experience for him - but it also showcases what i think is a very common trap for many indie devs, new studios, and a shocking number of AAA games:

he sketched out his game idea, wrote a narrative, designed a set of mechanics, then started work on his custom c++ voxel engine

absolutely great for learning - awful if you want to make a good game

this post went pretty viral recently and it made me really sad:

i made a game for 3 years and only sold $143 in 3 months

the reason this is so heartbreaking to me is because both of these scenarios are something so easily avoided. it's not a "visibility" issue like they say - it definitely got seen by enough people and was promptly ignored - but it's an issue that's not talked about enough in educational gamedev content because all of the educators fall for the exact same trap:

"phew! i've made my todo list of features! if i can just implement X, Y and Z... then i'll have a fun game!"

for a youtuber this is fine, it's content - but solo devs and indie studios copying what they see often ends in the same story:

from their perspective, it felt like they did everything right. their art was good, the programmer made the mechanics feel good, they copied what they've seen everyone else do, they were just unlucky or gamers are evil etc. it's naivety, because educators don't hammer the point home

too many gamedevs see the craft of game development purely as a series of technical challenges, and not as an iterative design challenge where enourmous failure is a crucial part of the process

there's an analogy i heard that gamedev is like "exploring" through a jungle, cutting through greenery, pathing any direction to find what you're vaguely looking for - but many devs, before they even know where they're going, have started laying down pavement

"im not exploring - i have a plan"

it's also misleading to think that if you plan enough, you can dodge failure: it doesn't matter if you have a simple kernel of an idea, or the most verbose thought-out design document of all time - you will fail. expect to fail. design docs are guides that are expected to be wrong if you're making something novel. it's unreasonable to perfectly describe something that hasn't been discovered yet. there is no reality where there's no failure at all

having 0 failures means you're likely not making something new

the perfect development cycle is not when you don't fail, it's when you fail as fast as possible

experienced devs know that you have ~0% chance of getting it right first try. all you need is a method of making sure what you're about to make is going to be worth the effort, and that method needs to be way faster than making your own c++ engine. it needs to take a day, an hour

fucking it up at an unprecedented rate

so what should we actually do?

because game design is a fairly new and barely-charted graybeard hyperskill, the easiest way to arrive at something cool is to just make a ton of stuff using your gut instinct and seeing what sticks. these aren't "practice" games or "homework" meant for you to get better at gamedev, this is a real part of making something huge. the game you're prototyping should be a game you really want to make and are excited about, and you're testing your theory in practice

make it quickly, test it with other people (!!!), and see if youre going in the right direction

this isn't just arcade games, you can make a single horror chase sequence in RPGMaker with default sprites. you could like, make a single date in your Moth girl dating sim in Powerpoint and give it to friends and see what routes they all take, see if it was too easy or too confusing, see if someone is proud of getting the moth girl the first try and sets their discord name to moth rizzler or something. basically what im saying is i think its really rare that a game idea is too complex to be prototyped in a day

now you've made your small weekend game, is it good? what worked and what didn't? what were people's reactions? what part of the process did you love? what parts did you hate? (which is why ive actually been making retrospectives! theyve helped a lot)

and if you're doing this over and over, you'll want to use the tools that let you make things as fast as possible. forget all judgement from others, just use gamemaker or whatever, make a paper tabletop game or even roleplay it out. work with what you're fastest with, and only once you've got a functional, fun, and proven playable game, THEN you can make your C++ voxel engine and write a narrative and draw the goth shopkeeper etc

the one thing a lot of people get wrong about prototypes and minimum viable products is that many devs don't actually make something minimal. they go straight to coding with good architecture, they make basic assets, they make a "demo" or a "vertical slice" - a small taste of what will be their final game. maybe it's missing some pieces, but everything that exists is fully implemented and has been labour-intensive. demos and vertical slices are a deceptively large amount of work, and you really don't want your prototype to be this. hardcode it like complete garbage, fake a bunch of stuff, sketch art in seconds. like, don't even make bullets hurt the player, just get in there and pretend that you need to dodge them

so i'd say if you're studying game design, instead of researching design docs or watching educational content, focus on optimising how quickly and shittily you can make a big handful of games that each demonstrate a core experience, knowing that you're going to throw them away

instead of the same heartbreaking story, here's what id like my process to be:

and there you go you've made a good game and you're not crying on reddit

so ya thats why i have 1000 unfinished projects lol wowoow

0 cools!! 🩷

Go back home