In my last post I examined the scope of a subset of NES games in detail to see what solo developers could learn.
Now that we have a better understanding of what these games did, I want to talk a bit about what they didn't do.
After this, I want to re-ask myself if using these games as a guide makes sense for bedroom devs, and I'd love to hear your thoughts on the subject.
tl;dr ๐
Here's what I learned:
- โ Set limits. Preproduction includes identifying modern features to not implement.
- Including anything that they didn't means doing work that they didn't.
- โฑ Less is more. For solo devs, short games beat long ones.
- โ Promise only one thing. Identify what is most crucial in your game to minimize time and money spent elsewhere.
- ๐ Polish what you promise. Know what you're delivering, and put your time and money there.
- ๐ฅ Know your players. Ask what assets and content they care about, and put your time and money there.
- ๐ Be sure you like this approach. Early NES games don't always mean small or quick!
Of Time & Templates ๐บ๐
My friend's initial pitch of the idea to me included the words: "using existing NES games as a template to control scope and maintain viability". I now think the key phrase is as a template.
To paraphrase Merriam-Webster: using these old game as a pattern to guide the form of our own new game.
Below is an image of Steam's idea (as of this writing) of what constitutes a 2D retro pixelart game. Most of these, including Vampire Survivor, Rivals of Aether, and Sea of Stars all pictured below, have features that no NES game ever had, let alone Black Box games.

I began by saying that Shovel Knight used NES games as inspiration. But inspiration is a starting-point. To control scope, we need to set limits.
Hard Limits ๐ง
If we take Black Box Era NES games not as a source of ideas but instead as imposing inflexible boundaries to our work, then we are talking about producing a very different kind of game than what is typically marketed as "retro" today.
This would mean embracing not just technical limitations but design limitations that recall 1987 or earlier.
What would these design limitations look like?
Capcom gave us some really great examples to consider:

Mega Man 9 and 10 were made in the exact same style as Mega Man and Mega Man 2, with the same basic elements and the same primary mechanics.
But 9 and 10 were made 20 years after the earlier games and they are thoroughly modern titles with features, content, and affordances that the old games can't match.
Even without spending hours analyzing those games, I think I can mention some things commonly done today that were extremely uncommon during the Black Box Era:
- Complex UI
- Wide Variety of Primary Mechanics
- In-Game Play Instructions
- Character Customization
- Complex NPC Interaction
- Environment Modification
- Detailed Cut Scenes
- In-Game Lore & Backstory
- Detailed Character Development
- Simultaneous Multiplayer
- Optional Content
- Achievements
- Mini Games
- Voice Over
- Autosave
- Modability
- Network Access
Some of these things wouldn't become the norm for decades, but others began showing up regularly in just the next NES Era. Are we willing to strictly limit all of them?
If the answer to this question is "yes", then our preproduction must include identifying features we want that we are not going to implement.
Perhaps that NPC only ever says one thing.
Perhaps the castle screen doesn't update to show that the ice on the mountain melted.
Perhaps there are only 12 stages and the hero can't gain EXP after level 16.
Perhaps there's no HUD and 255 ammo is the max.
Perhaps there's only one game mode and nothing explains how to open the door at the end of the hall.
All this would be in keeping with the Black Box Era.
Safe, Sane, Salable? ๐ด
On the one hand, limiting our designs to Black Box Era standards means that we as devs have less to do, which was exactly the point we started from. On the other hand, it means sacrificing things that players have come to expect, even in their pixel games.
My main question, then, is: will players in 2024 or later buy games that so rigidly recall 1987? Beyond the homebrew scene I don't think this proposition has ever been tested.
Let me know if I'm wrong!
However, there's probably room to pick and choose here. I certainly don't want to go back to the days when accessibility options were nearly unheard of and I had to enter a long, confusing password to continue my progress.
The thing to keep in mind as we pick and choose is that every time we say "yes" to something these old games didn't do, we're agreeing to do more work than those well-funded '80s teams did. For this to work out, our tools need to be pulling their weight and then some!
For now, I think the only way to know if this model is financially viable is for people to try it and see if players are interested.
But, Is It A Good Idea? ๐๐โ
When I first started this research project, I was pretty convinced the answer would be "yes". After looking into everything, I'm not so sure.
I've come to realize that even among the early NES games I chose to investigate, many are pretty large, complex beasts! They're not necessarily a secret sauce for small or quick.
While it seems to me like an experienced indie team of 4 to 10 could knock out most of these games in a year and change, could a solo dev do that?
Speaking for myself, I have to honestly say that I could not. Not unless I was out-and-out cloning them. Maybe once I have more solo experience?
Then, too, there's the limits question we just discussed. While taking inspiration from old games ups the odds that there's an audience for them, every time we chip away a contemporary nicety, that potential audience potentially shrinks.
But, there's a silver lining: looking into these details has got me looking at my own development from a new perspective.
So What Did I Learn? ๐
-
First, length of play.
When making the Yurivania games I always wanted my next game to be bigger: more palace, more monster girls, more to do, more to see, more to read.Looking at Black Box Era games has reinforced the feedback I was already getting from my players: size matters and shorter wins.
This makes sense to me when I think again about being a bedroom dev. People don't look to me for the next game they'll sink 1,000 hours into; they look to me to give them a very brief experience they can't get elsewhere.
-
Second, mechanical finesse.
As a self-taught designer who's very much still learning game design, I always wanted each Yurivania to include fresh game modes: new abilities, new quest types, new minigames.But that isn't how Black Box Era games worked. And that's usually not what people want even today. Players seem to want a small set of mechanics that are really, really well done.
So next time I start feeling like my main mechanic isn't interesting enough, I'll know the answer is not adding additional, unrelated mechanics! Instead of making the game longer, I'll aim to make it better.

-
Third, what matters to the player?
The Black Box games answer this in two ways: sound and visuals.-
Sound
I love game sound tracks; I listen to OSTs for games I'll never play. For Yurivania, I always emphasized background music.As we've seen, this is not how Black Box games worked. They put their money into their sound effects.
This might be because, for most old games, the sound effects do more work than the soundtrack. Soundtrack influences player emotions and builds character or setting, but sound effects communicate information about how the game is actually unfolding in realtime.
In these early days, that mechanical feedback may have been more important than setting mood or building tension.
-
Visuals
Yurivania was for me first and foremost about the setting: the Midnight Palace.Before I knew any of the characters or their personalities, I knew where they lived. I wanted to communicate this place to my players.
From the standpoint of an artistic vision, that's fine. But that's not how the Black Box games worked. They put their money into player art and enemy art.
I didn't do this because, as a beginning pixel artist, it was easier to draw lots of different bricks than to draw lots of different expressions or postures.
I believe that the Black Box games favoured character art because '80s devs expected players to be invested in who they're playing as and who they're playing against.
Of course, neither of these points are going to always be true โ different games have different aesthetic requirements. But up till now I didn't even consider this.
-
-
Fourth, deliver the best version of exactly one thing.
We saw this with Mechanics vs Narrative but it could apply elsewhere, too.My guess is that this is imperative for bedroom devs hoping to break even. Maybe indie teams of 4 or more can afford to promise their players a whole raft of priorities; I suspect that we solo folk need to hone in on exactly one.
That doesn't mean neglect everything else altogether; I don't mean "deliver a crap story and hope the mechanics will pick up the slack".
But all the same, I'll be thinking differently about my game's context going forward.
By analogy, it's not on me to prepare a balanced breakfast; instead, my job's to make the soy milk and leave the cantaloupe, grapefruit, and avocado toast to others.
-
Fifth, to repeat a point from the last post: speed is of the essence.
If Shigeru Miyamoto and Yuji Hori (not to mention all those queer Itch devs) had to get their games out in under a year to keep their companies afloat, I probably need to as well. -
Finally, "Did NES devs do it in '87? If not, maybe I shouldn't do it in '24."
I really like the sound of this.I mean, it could be taken too far. But for the moment it feels like a good way to remind myself that I don't have to be all things to all players.
That's It for Part Three... and this Research Project โ
Whew! Like developing a game, this project took a lot longer than I expected!
For me, it's been worth it. I'm not sure if any of this is useful to anyone else.
If you have any comments or corrections, please let me know!
Otherwise, thanks a bunch for reading! Hopefully we can keep playing one another's games as we each grow our skills~~
