- Spending all my time thinking about how to support 10 different resolutions
- Coming up with the perfect framework for managing state
- Working on silly menu systems and other UI elements
- Finding the perfect map builder and obsessing over data representations
- Tweaking an entity component system to death
- Etc
Next time I set out to make something, I'm not going to worry too much about the code. If the idea has merit, I'll refactor it later if I need to.
Summary--It's really easy to let details get in the way of ideas.
Unless you already have a playable game loop that's so fun it's hard to put down, you shouldn't be going anywhere near menu systems.
You should have what's basically a rickety CLI-invoked developer mode test harness, where the binary immediately enters a playable thing. Only once that is proven as something worth putting a menu system in front of should you even think about that.
Most game ideas suck when implemented so they're a total loss, or require a lot of iterating into something entirely different from what you imagined. So the top priority should be implement the game loop of your idea, learn if it sucks ASAP, then maybe try mutate it into something a person can't easily walk away from if you sit them down in front of it, or just cut your losses and do something else entirely.
There is another tenet from board game design to get the idea out of your head and onto the table. Showing designs to trusted others asap is imperative. Very much a "perfect is the enemy of good enough" situation.
I ask because I have a friend with a game idea that looks fun, but it has enough tweakable parameters that I could see a poor selection leading to unbalanced games, or a clever combo being difficult to beat, and so on.
The thing is that players don't want actual balance; they want to feel like it is balanced. And much more importantly, it must be FUN! If a game is too balanced it might well be boring and that is worse! My goal for balance is to try to make it so that players of equal skill and exposure to a game all have a reasonable chance of winning any game play.
I do know of some designers who start with a perfectly balanced game so they have an anchor. Then they adjust it over play-testing sessions to be more fun or create the experience they are designing for. I have a game that is Dracula vs Van Helsing in a hidden movement chase. I KNOW that Dracula has a 60/40 advantage. However, during unattended play-testing (random people are just given the game and rulebook and I'm not there), players overwhelmingly reported feeling that Van Helsing was far too strong!! Perception is everything.
As for your friend, they should look at having it played during a Protospiel or Unpub event. Some are in person but there are others online. They will get immeasurable feedback to direct their design. They are also innumerable podcasts that discuss these topic like Ludology and Discords like Building the Game and Break My Game they could join to get more feedback and advice.
As for random set ups creating unbalanced games, that can sometimes be even the desired effect. It depends a lot of the type of game, length of game and target audience. For example, Uno is completely random and unbalanced in terms of game decisions. However, the point of the game is to allow kids to beat their parents while learning matching. It is a 15 minute game so you just play again and move on with life. The memories and excitement are the desired game experience, who cares about balance?
I share your concern though. You don't want to publish a game only to find, when attacked by real players in quantity, that your design is broken.
For the board game I'm working on, I've found running many simulated games with MCTS-based AI players has proved instructive in some respects. For example, balancing for turn-order fairness.
This works with patterns used to create games though. Few will play rock-paper-scissors a lot, but using it as a conflict resolution mechanic with known characteristics works great.
I think that's probably true of all development, be it game, software, property, whatever.
- set a clear time boundary and a date, typically by estimating chunks of the work, it's better to make wrong estimations than to yak shave the crap out of something for way too long
- write down the goals and non-goals.
- make a clear, simple high-level design, including trade-offs and cutting corners to meet the goals
- implement vertically, get something going fast
Stuff like that...
Basically with an open ended, creative endeavor I absolutely need to restrict myself much as I can stomach. At least in cases where I actually _want_ to finish a project and know what its goals are. In many cases exploration and playing with code and techniques is the goal itself and that's OK.
For me the foreverproject is where I drive all that perfection energy. The surrounding games, well, they're just "experiments" and "prototypes", right? Surely prototypes don't need to be perfect ;)
I'm trying to break my own BIG IDEA into manageable experiments or profitable side hustles somehow too.
If I had to peg my general philosophy, which is tied to how I like to play games: it's on being open minded when it comes to strategies players can use to overcome challenges within the game, and try to codify some of that within the systems built into the game so players have options to overcome challenges in ways other than gladiatorial-like combat.
Basically, I think "exploiting" is fun, and believe it's an overused term.
The playerbase dwindled to nothing and I wanted a different challenge so I shuttered it. Over the years many people worked on it and while I'm sure they wouldn't mind if I put it up on github, I've lost contact with many of them so I don't feel right releasing it, so it's just in the bitbin of history.
Now I'm working on a 2D version of it, which adds a whole new dimension to the challenge. Once I have something more than just random prototypes I do plan on putting it up. But it's slow going - I have a job and kids, so I get about 1 hour per day to work on it.
One particular game jam I recommend is Trijam [1]. It takes place every weekend, has a fixed theme and ideally you should only spend a total of 3 hours on a game which forces you to do something relatively simple.
It's kind of the problem with games, they consist of so many fields it's easy to think you have a "small" idea only for that idea to actually be substantial. Then, reasonably, when you want to nail the details it becomes a gigantic mountain. To me this isn't perfectionism, everyone wants to nail details, but when the scope is too large it's difficult for that to happen - hell it's difficult for that to happen on teams of tens of thousands operating as cogs dedicated to their tiny section of work!
Any one of your bullet points could have been the "small game" to demonstrate how large you're still operating.
I also make sure it's default live so I can get continuos external feedback as well.
- Looking for the perfect domain name
Like I've worked on a lot of small games (https://vgel.itch.io), some better, some worse, but I've never tried, e.g., an FPSRPG or a Dwarf Fortress-esque simRTS. The process of "stripping down" those genres to be feasible as a small game fundamentally transforms them into something else. When you rip the complex skill tree out of an FPSRPG to simplify it, it becomes a different kind of game! And some people just don't like that—they only want the complex game. They didn't like early Minecraft, they only like Minecraft now, after 10+ years of development gave tons of interlocking features and mechanics. And that's... what it is. It makes me a little sad, but I don't think those people will be very happy as solo indie devs (unless they have the superhuman willpower to push through years of development on a single game without enjoying the early stages or the tight feedback loop of improvement you get by releasing smaller games).
I've tried to sell this vision to people before, maybe not as eloquently as OP, showed them Itch.io and some of my favorite games on there, and... they just didn't care. It didn't interest them at all. Other people got the appeal immediately. It just seems to come down to personal taste.
i think you are dead wrong. there is a lot of people just using the core of the game (previous the first alpha) to build stuff and that is just fine for them. past alpha (the survival mode) up to today i do not think it changed dramatically beyond some mobs and new stuff to find… the gameplay is still the same: collect -> craft [while surviving]
StarCraft Broodwar is an interestingly complex strategy game, not because it has a lot of layers, or even lots of things at all, but because it has a simple system of orthogonal, powerful features. It had less features and units than many of its competitors (RTS was a big genre at the time), but it found ingenuity in simplicity, minimalism. Every piece of the puzzle was to some degree relevant throughout the history of the game.
I think you are right in a general sense, but "layers" can be a misleading term here. You rather want to increase complexity and beauty by enabling manners of composition.
Another game that illustrates this is The Witness, which is probably one of the most praised puzzle games and again, is beautifully simple. In terms of layers it has pretty much exactly three: The panel puzzles, the environmental puzzles and then the visual secrets that you only see by looking at things in a certain way. But in terms of actual game mechanics there are very few things. The complexity then emerges by mere combination.
This is both an important insight and excellent writing.
Don't get me wrong, a platformer is a good small game project to start with, the game can be made with a level or two in a weekend using modern tools.
But even back on the NES we had way more than just platformers.
Sure, a beat-em-up is a bit more technically challenging than a platformer but I think cloning a Turtles game from the NES era is probably a fairly reasonable "small game" too.
Or cloning an RPG, or something like Fire Emblem, or Zelda.
It's weird how everyone wants to make a metroidvania but not many Zelda-likes are out there.
I don't think so. Remember the heyday of Flash games, Kongregate (before it was spammed by MMO clones or whatnot)? Many short & sweet games that weren't platformers. Some were puzzle-solving games, some were adventure games, some were escape-the-room, some were shooters, and yes, some were platformers.
I have the fondest memories from that era. I still remember the short and thoughtful "The Majesty of Colors".
That era was definitely defined by enthusiast creators instead of the modern indie-studio-ification of even the simplest games.
At least, this is the usual theme on people that are good on anything.
It's a simple RPG where your characters fights monsters and completes quest achievements without your input, but you get randomized chances to visit the merchant or medic, which largely determines your fate. It seems simple at first but it's harder than it seems as the game moves on.
https://github.com/donuts-are-good/consolequest
I made it just for fun one night, and found it strangely addictive all on my own while testing because I'd want to keep playing even after verifying the thing I was testing.
P.s. my high score is 356 days in game. not sure it's possible to get higher, you get wiped out quick.
It'd be my pleasure if anybody wants to play :)
The developer talks specifically about choosing a small scope for a game, and clearly spends a lot of time thinking strategically about being an indie dev.
I started building something from his code - https://github.com/sdwr/underlod
Anyway, his games were horrible messes of magical Peek and Poke statements in Atari BASIC. But . . . they were FUN. And they took a couple of hours to write.
It was a multiplayer game (most of his games were, because the AI is free when you can just give another player a joystick). It was a simple 2D top-down sprite-based animation with:
- A ton of robots on the screen, milling around and doing stuff.
- Up to three players controlling their own robot (with the rest being computer controlled).
- A "finder" player who controlled a cursor and got a limited number of guesses as to which robots were controlled by real people.
- The players could win by fulfilling some simple missions ("pick up the blue blocks / visit each corner of the screen"), the finder could win by identifying the players without running out of guesses.
Reminds me of a certain popular modern online game . . .
It's extra relevant in gaming too I think. Big games are very very expensive to make, and so are conservatively modeled on what works in other mediums like movies, tv, novels. Small games are where the real exploration of the dynamics and limits of the medium happens, but is held back because gamers overall have underdeveloped taste.
"I apologize for such a long letter - I didn't have time to write a short one."
props to the creator for how complicated it is, but man, just contemplating the time I would lose trying to dive into it is horrifying for me.
I’m wondering, because I was going through my steam library after reading this, just looking at the games I play and trying to fit them into “small” and “big” and while many seemed obvious, many were also hard to tell.
Is it the size/scale of the development (i.e. indie vs AAA)? The mechanical complexity? the graphical complexity? The volume of content? The size on disk? maybe some combination or something else entirely.
Yes, yes and yes.
> The size on disk?
Indirectly, sometimes. Also, how polished a game is.
At the end of the day, people severely underestimate the last 10% -- which take about 3-30 times as long as the first 90% -- of creating a game. Creating a bare minimum Binding of Isaac clone can be done in 48 hours. Creating a full sized Binding of Isaac competitor will take at least a year of full time work of someone who knows what they're doing.
On the subject of scope, I think it's helpful to remember the Mythical Man Month. If the game you're cribbing took four experts two years to create, that's eight person-years. Can one person hope to make something of that scale? There are examples, but few have that level of resolve.
Don't hand wave away things by saying "modern game engines." People were brilliant back then, and expectations were lower in some respects.
I've had a lot of fun developing a bunch of different games in it, and as more features / keywords are added, I get to write even more games! It's been a blast. We recently added physics capabilities to the turtles, and I'm working on using those for some new games.
I have a 13-year old guinea pig I've been teaching how to code in Logo, and she loves how much she can do in so few keywords. She's recently started competently debugging her own code and I'm proud of that.
https://turtlespaces.org (website) https://turtlespaces.org/weblogo (WASM IDE)
Unless screenshots were just for conveying the satisfaction point.
Hobbyists unite!
