In a recent post at intfiction.org, a poster asked for advice on a (very) complex text-based game they wanted to create. The postscript read:
Also, yes, I am aiming WAY too high, thank you for noticing, especially considering my complete and utter lack of skill, practice, and focus, but guess what. I DON’T CARE. I’M GOING TO TRY ANYWAY. I REFUSE TO ACHNOWLEDGE FAILURE AS AN OPTION.
I have two immediate responses to this. The first, as you well might expect, is, “Oh you poor human, you are doomed to disappointment.”
The second, though? “ROCK ON.”
There are a thousand reasons to make small games first. The experience of starting from nothing and ending with a playable, complete project is extraordinarily valuable, regardless of whether you’re in a commercial or noncommercial space. And most people who decide to create The Ginormous Project first will fail. Relatedly, check out yourgameideaistoobig.com (which gives ridiculous lowball figures for all its costs and time estimates).
That’s why my first, reflexive recommendation is always to cut scope. What’s the smallest possible version of your game? Build that. If you get it done, expand later.
But those are recommendations for a commercial context. If you’re not in a commercial context, then your goal isn’t necessarily to ship. It might be (c’mon, don’t we all want to see our games go live?) but it might not be. You might just want to make the game of your dreams.
I can’t find the quote (if you remember it, help me out in the comments?) but there’s a saying about people who want to become published writers. The essence: People who say they want to be writers will never be writers, but people who say they want to write – they just might succeed.
If Original Poster just wants to have released a game, this isn’t going to work out. But if Original Poster loves the process of game development, they just might pull this off. I’m willing to be optimistic. I like it when people succeed.
So… when your game proposal is larger than text-based Skyrim, what’s the next step?
Design the game. Break every feature down and document it in so much detail that you could hand it to someone else and they could build it from your notes. There’s a huge difference between saying “I want the player to be able to build a house” and figuring out what that means – does the player type “BUILD HOUSE”, or do they negotiate with an NPC, or do they dig a foundation and hoist every wall themselves? Can the player have one house, or many houses? What commands do they use, and what resources are needed, and how will the creation of a house restructure the map, and how are you going to communicate all this to the player?
Depending on the size of your idea, this will be days, weeks, months, or even years of design work.
If the process of designing a feature is exhausting or boring, then consider ditching it. Devs use paper prototyping because designing a game on paper always takes less time than building it in engine. If designing the feature is grueling, then building it will be pure misery.
Once you thoroughly understand your design, you’ll know which features are the heart of your game and which are frosting on the cake. You’ll be able to choose your game engine and other tech intelligently. And you’ll be prepared to start the actual process of building your game.
The number of people who want to be novelists is much larger than the number of people who have actually written novels. Game development is the same way. If you really want to be taken seriously as a game developer – loop back and release something small first, or build an early prototype that you can show around. You won’t gain credibility with a project that no one has seen, and building a very large game will take a very, very, very long time.
To get your work in the public eye before you’ve built The Whole Thing (generally a good idea), build a reasonably polished but minimal-feature version of your game and release it as an alpha. Then continue adding features with future releases. This is classic behavior for building MUDs, but many modern games have also used this approach, including Starbound, Crypt of the Necrodancer, NEO Scavenger, Desktop Dungeons, and Dwarf Fortress.
And if it stops being fun, let it go. Remember, you’re building a noncommercial game here. That has to be true because, if it were commercial, you’d have scoped like someone who actually cares about whether the game ever sees daylight (since you’ll never get paid until it does). So don’t quit your day job, and keep the electricity running, and do what makes you happy.
Dear Patreon subscribers: If you haven’t filled out the backer survey yet, please do, as it will directly influence the future of Sibyl Moon. And thank you for your support!
If this post was helpful or thought-provoking, please consider becoming a patron. And then fill out the backer survey, for the reasons above.