The brutality of the marketplace is unlike any other - Steam has over 100k games in it's store, with 18k added just last year. Yes, as in anything there will be the breakout few which go on to generate fame and riches, but in general if you are a single or small group indie with little to no marketing budget you are unlikely to ever turn a profit. As the saying goes "just because you wandered through the desert does not mean there is a promised land."
While thinking of making a game I’ve found these helpful:
1. The Art of Game Design, A Book of Lenses by Jesse Schell - https://schellgames.com/art-of-game-design
2. 20 Tips on Making Games by Jordan Mechner - https://www.jordanmechner.com/downloads/library/20tips.pdf
3. Liz England’s blog - https://lizengland.com/blog/
Discourage reading Jesse Schell if you want to make _good_ games instead of corporate slop. He's never made a game you like or anyone you know likes. Agreed everything he says sounds great but then why hasn't he made any good games?
> Agreed everything he says sounds great but then why hasn't he made any good games?
Quick browse of the portfolio on that website (https://schellgames.com/portfolio) seems to show multiple games that has won awards. All their original games seems to have "Mostly Positive" or above on Steam as well.
What metric are you judging this developer by? I can't say I've played/seen any of those games myself, but clearly they seem to be putting out some games that people play and enjoy.
I Expect You To Die, Among Us VR, Until You Fall. All good stuff
Jesse Schell's book is a great read beyond game design.
Thanks for the other links.
To leave something in return, here's something I read the other day and kept thinking about it (I'm designing on a PvP motion based game)
"In competitive games, there is little more valuable than knowing the mind of the opponent, which the Japanese call “yomi.”
As a side note, I would even argue that the “strategic depth” of a game should be defined almost entirely on its ability to support and reward yomi."
The Yomi Layer concept is a reminder that moves need to have counters. If you know what the opponent will do, you should generally have some way of dealing with that.
I have tons of friends that took his classes at CMU, as much as everything he says sounds good I don't know a single person that has ever enjoyed a game he made. Because of that, I have to assume what he says is either fluff or wrong even if i can't perceive why exactly
Obviously you’d be a better judge than I am given your inside knowledge, but your comment reminds me of the many virtuoso musicians who don’t really make music people like. There’s a gap between technical ability and taste, artfulness.
It's not that he's making games too avant garde or something that might be going over my head. His company just makes corporate slop, not a single enjoyable game amongst them
I feel a great deal of the games Schell produces are for clients (like ports) or serve as a more in-depth proof of concept.
I think the client work pays the bills though, looking at their catalog.
Yep, but that's a totally separate thing from making good games
One of the reasons I got into software development was that I wanted to make some games (even just small ones that I release for free).
I've now been coding for like 14 years, and I still haven't done it (besides a number of prototypes). And I'm so burnt out on writing code that I never have the mental energy to push through and get one done.
> I've now been coding for like 14 years, and I still haven't done it (besides a number of prototypes). And I'm so burnt out on writing code that I never have the mental energy to push through and get one done.
I was basically the same. Played video games before programming was even on my mind, and first exposure to programming/structured data was trying to mod GTA Vice City vehicles, and then eventually got drawn into programming while trying to game dev by night basically.
On and off I've tried Gamemaker, Unity, Phaser, Godot, Unreal Engine and everything in-between, for the last two decades or something. It always end up the same, game logic so complicated I can't make head or tails of it anymore, and it was really hard to decouple things enough so I could be as confident editing game logic as I am reading/editing other types of codebases.
So I never really got anywhere, until I found Bevy. I'm not particularly fond of Rust, way too verbose and strict for my taste, but ECS turned out to be a god-send for organizing game code (in my case). Suddenly writing decoupled game logic became a breeze, and since discovering Bevy (but really ECS gets most of the credit here), I've even shipped some games during game jams that I'm moderately proud off and placed well in the ranking compared to my expectations.
If you're of similar traits that you need code to be of a certain quality to be able to effectively work with it, ECS might be up your alley too, and worth a try if you haven't already. It made a huge improvement in terms of how flexible the architecture end up being, and made it a lot easier to incrementally work on games.
I have a suggestion for you. Try making a board game instead. No complex technology to learn, way different than already being burnt out from coding all day, you can iterate on the fly by writing on your prototype, some can be tested solo (but having some friends come over once a week isn't insurmountable and is very social), lots on online testing available using "no rules" engines that let you just move "objects" around (a little tech to learn but done in a few hours), etc.
If if your game never gets published, etc. you could have a game that you and your friends got countless hours of enjoyment from. I personally get a lot of enjoyment from it. Good luck!
Heh, I started working on a board game with a couple friends and then got caught up reading card descriptions from a shared Google Spreadsheet and generating images to work with Tabletop Simulator.
It's a different kind of work from my usual though, and it was fun to see my friends in awe that they could write arbitrarily many new cards and almost instantaneously see them in the game.
Taking ClarityCorp as an example, I see an opportunity to focus more on the design phase (testing ideas) than the implementation phase. As engineers, we often dive directly into coding and implementing systems related to our problem rather than asking simple questions like, "is the game loop fun?" I've seen some brutally simple prototypes (150 lines of JavaScript) that represent an idea well enough to determine whether the idea has the potential to merit the time investment required to bring it to fruition. Personally, I'd rather test 15-20 different concepts at the lowest fidelity before settling on a direction than 2-3 half built games over the course of a year. Not knocking the author at all (kudos for producing some work). Just offering suggestions.
Multiplayer game development just stinks. It's not because of the networking and the tricky bugs and cumbersome testing setups (fake latency, packet loss, a bunch of open game clients) if you like these sorts of things (though of course that can suck sometimes and does frequently), but if you get far enough, you just depend on everyone you know for play testing constantly. The more people you need per game the worse it is. I worked on a 3v3 game for a couple months and it got really hard to find people to test towards the end. Just imagine making any plans for a group of 6 people. That's almost always annoying. Now try to do that once a week and some of those people don't really know you, so they don't care about being late or flaking out. This is not just annoying, but it really impacts the game. The game requires design and tweaking and experimentation just like any other, but if you can properly play test your game once a week for an hour or two, game design progress is very slow and tedious. I'll never work on a multiplayer game again solo, only with a team at least as large as the number of players the game is designed for.
>you just depend on everyone you know for play testing constantly
I had this problem, didn't figure out the solution till the end of the project- it's bots. Even bad bots are HUGELY important for multiplayer game development because now you can iterate every second instead of every week. I thought bots would be too hard to make for my game, but they really weren't as they don't even have to be good. With LLMs i'm fairly sure almost any type of game can be botted at this point too.
Almost any type of game can and has been botted since forever, nothing to do with LLMs
I more meant like now you can bot word or story type multiplayer games too e.g. if you were designing a codenames or a mafia style party game or something. 95% of the time though ya you are just doing basic AI logic, go towards objective, attack nearby enemies, avoid nearby danger, etc
I used to be part of an indie play testing group which was spun off from the community who took over developing natural selection 2 after the dev team moved onto subnautica, it was great as we all got to play new games every time, with the same people and just have fun. No idea if it still runs now but it was a great idea!
thanks for the reminder of one of my all time favorite games!
It stinks but sounds like your compensation for their time was too low.
I’m not entirely sure why, but I find myself drawn to reading about failures and the reasons behind them, far more than success stories. There’s something uniquely compelling about failure—it often teaches us hard, invaluable lessons that are nearly impossible to grasp when everything goes smoothly. Success, on the other hand, can sometimes be attributed to a stroke of pure luck, leaving fewer insights to learn from.
Similarly, when I’m considering a purchase, I tend to focus on the negative reviews (those rated 3 stars or below) rather than the glowing, positive ones. Negative reviews often provide more logical, specific reasoning as they shed light on potential deal-breaking issues. That said, they can sometimes veer into irrelevant complaints that don’t resonate with me. For example, when I’m browsing book reviews on Amazon to decide whether a book is worth reading, I frequently come across one-star reviews criticizing the print or paper quality. If I’m planning to buy the digital version of the book, those complaints become irrelevant to my decision-making process—even though they might be incredibly important to someone else.
In essence, I find value in the nuanced, sometimes brutally honest critiques that failures and negative feedback offer. They paint a more realistic picture—one that helps me make better decisions and understand the world a little more clearly.
I think putting off polish for later as the OP and multiple comments here recommend is a fallacy. There are many popular, successful games that would just not be fun if they didn't have good animations, no effects and everything was boxes. Every game that relies on "feeling good to play". It might be fine for an RPG or an RTS, but it's probably not for something like Overwatch or Doom (the new ones). Just imagine Vampire Survivors without sound or effects. Some games live off the art style alone. This is a very controversional opinion, but I think if e.g. Ori and the Blind Forest had bad art, no one would have played the game. Some games you can evaluate really well with bad art and no juice or polish, other games need some and there are even games that need a lot of it, before you know if they can be fun. It's not that simple imho. I remember working on games that were not really fun until I added some effect and suddenly it was really addicting. People like flashing lights and noises and pretty pictures. If good, unique or interesting art was irrelevant, no one would invest in it, but people do.
I don't think anyone is suggesting to ship a version to actual customers without some polish, but foregoing polish is good advice. I've attempted to make games on several occasions and my current is the first to stick because I intentionally decided not to worry about aesthetics too much at first, that allowed me to quite rapidly get to something that's fun to play, which in turn has motivated me to keep going. It also drastically reduces the pain of sunk costs when the entirety of your projectile system is a coloured box shooting spheres rather than a lovingly crafted gun model which isn't actually fun to use.
Having watched/read a few things about the white boxing stage the general advice is to put in as much polish as you need to do that and no more. If you're trying to prove out jump mechanics literally just some boxes for platforms and a sphere as the character is enough. If you're making a stealth game then you'll need some lighting in your level because it's a core game mechanic.
> Just imagine Vampire Survivors without sound or effects.
I can't help but feel that this completely undermines your point - Vampire Survivors is bashed together using rudimentary knockoffs of sprites from games from the 1990s, in an engine which barely supports the idea of particles let alone proper visual effects.* It is the gameplay that carries Vampire Survivors, not the aesthetic.
Game feel is of course essential to producing a good game all-round, but a competent game designer can and will tell the difference between a good game design and a bad one, way before polish and juice are layered on top.
*I don't say this as a criticism - Vampire Survivors is fantastic - but the idea that it's propped up by its look is just daft.
The point of the OP (which I agree with) with is that the gameplay and the aesthetic are not orthogonal to one another. Even with Vampire Survivors which is not strictly beautiful the aesthetics are a big part of the gameplay. Largely the visuals and audio need to do several things:
- Make the game legible. A good example would be to reduce the whole game to boxes, you still need to differentiate things, so you might want to color them. Aesthetics in support of gameplay to make the game understandable.
- Add 'game feel'. This is where audio is especially important as you tend to notice the lack of good audio rather than its presence. But also 'juice', animations and what not all layer in.
- Support the fantasy. The name Vampire Survivors carries expectations that boxes do not match.
If you've ever done a lot of playtesting with your target audience one thing you'll find is that missing these elements gives you much worse feedback. Most notably legibility because it's so integral to being able to play a game but the others as well.
Game designers to an extent can get past this but it's still an attempt at extrapolation which is necessarily less concrete. Also if you're new to making games then you're going to make it harder to judge your own work.
The good thing about Vampire Survivors as an example is it shows that you don't need to do much but enough.
Overwatch was prototyped by making levels out of plain boxes, using character models ripped from a previous game, then iterating until the game mechanics were fun. Of course, it then received many layers of polish before it was launched, but nonetheless the devs prioritised getting the basics right first.
The dev team had just come off developing Titan, a cancelled MMO where they had trouble making the core game loop engaging after seven years of development, so they had a lot of motivation to start small and make something good first, then polish later.
I don't think they're saying don't polish it all before you release it, but to not worry about polishing it until you have a solid gameplay foundation
You might spend a ton of time and money on art and polish only to suddenly realize your game isn't fun at all. Many such cases.
The idea behind postponing polishing is that if you can’t build a strong foundation using the skills you’re most comfortable with (coding), there’s little point in starting with the harder parts. It’s better to make as much progress as possible with the tools you already know, since the areas you’re less familiar with will require more research and move slower.
Most indie projects die before getting there.
Learning how to prototype a game is a skill. I've prototyped hundreds of games over 30 years for work and pleasure. Seeing the potential is genuinely hard but it IS a skill you can learn.
Understanding that the general public should not and indeed cannot be expected to see the potential is also a hard lesson. Games like VVVVVV are unicorns. Never bet on being a unicorn.
The point about art being hard for programmers hits home. I hit the same thing when dabbling with game programmer (at a much less skilled level than OP). Difficult to stay motivated when the early drafts look like crap and you’re coding against stickman art.
I’m guessing these days there are placeholder art libraries available?
> Difficult to stay motivated when the early drafts look like crap and you’re coding against stickman art.
I think learning to see past this and be able to evaluate "Is this fun?" regardless of it looking like shit is a skill to learn like any other.
A great way to train this is to start playing random games people publish on low-stake platforms like Itch.io. Most of them lack in the art department, but even some of those have really addicting gameplay hooks, or otherwise novel gameplay elements you can notice shines through the awful art.
Hopefully after a while you'll be able to discern more between "Is this not fun because it doesn't look fun, or because it doesn't feel fun?"
This is an unpopular opinion on here, but generative AI is getting very good. I think it will soon be the way non artists create art assets for a variety of purposes. It’s not perfect yet, but it’s rapidly improving.
There is an entire vast ecosystem of services and a community of artists offering production quality assets of every conceivable type, often for free. Generative AI doesn't solve any problems in this space.
That is great if your idea for a game or other product only requires those already existing assets. However, what about assets that don't already exist? You would have to commission an artist to create them, which costs money that you as a bootstrapped independent developer may not have. It also takes considerably more time than generative AI does.
This is a contrived example but, what if I wanted a Walrus riding a surfboard, wearing a top hat, holding a katana in his right hand, and holding a slice of Hawaiian pizza in his left hand.
Despite the biases people have against generative AI, it will solve a LOT of problems in this space.
>That is great if your idea for a game or other product only requires those already existing assets.
Which many will. Just look at the indie games on Steam, a vast amount of them use pre-existing assets.
Jim Sterling poisoned an entire generation of gamedev's minds against it, but there's nothing wrong with doing so.
>You would have to commission an artist to create them, which costs money that you as a bootstrapped independent developer may not have.
If you want a game with quality, unique artwork, likely a style you want to build a brand around and monetize, you should be willing to spend the money on an artist to create it. Using a technology which is trained on the work and style of artists (without their permission, mind you) to extrude an art-like product just to avoid having to pay for it is gross.
>It also takes considerably more time than generative AI does.
Does it? Chances are that "Walrus riding a surfboard, wearing a top hat, holding a katana in his right hand, and holding a slice of Hawaiian pizza in his left hand" is going to be replete with errors, not have a consistent style, have bad geometry if it's a model, and need to be edited anyway. It isn't going to be what you imagined in your head, because generative AI is a mediocrity machine, and it isn't going to compete against a coherent design implemented by real artists who care about their work.
You'd be better off just buying assets or hiring an artist either way. It isn't even that expensive, artists are desperate for work now that AI is eating them alive.
Hiring artists is still a cost and potential time sink, for a game done in your free time that is really unlikely to turn a profit. Generative AI is free and takes just a few minutes.
OK. I guess there is literally no other option for you and it was a mistake to imply otherwise. Have fun with your derivative slop, then. ¯\_(ツ)_/¯
100% this.
I have done work in embedded game dev off and on for about 20 years, and I could have done so much more had I had even one ounce of artistic ability.
And (other than hobbyist or OSS), it's very hard to use canned artwork. Everything just needs to be unique for a commercial offering.
But in all fairness, I don't think many of the artists I worked with could code. Just seems to be opposite skillsets (beyond just the creativity).
This came up a few days ago: https://news.ycombinator.com/item?id=42671472
Free art bundles for gamedev:
I can actually draw pretty well but art for games is a whole other thing. Like, my ability to draw portraits doesn't really help that much haha. I mean it probably does but it's a slightly different skill and the sheer amount of assets needed is overwhelming, so it still takes ages.
I really enjoyed the article, especially the focus on a gameplay loop, and leaving polish for later. Often I have found that I can tell if a game will be "fun" after a super low fidelity prototype. One of my games began as a jupyter notebook, for example. Of course, the rest of the process is also very important, but I am not sure a game that is not fun from the start can be made into a good game.
In the same vein, I can recommend this book: https://www.goodreads.com/book/show/34376766-blood-sweat-and...
It shows that even big companies and development efforts can often struggle to create a fun game, even when the people involved have a lot of experience. It is a hard thing to accomplish!
Agree. I used to fast-prototype games — and if they were kind of fun in even their rough stage, I might be on to something.
To be sure, there were a lot more game prototypes that got swept into the bin. Often for the same reasons the author mentioned (specifically there were several I knew were going to be too much of a time investment to do properly).
So many games will use a Capsule as their player for so long that it seems impossible to get a fully rigged player later on
I have barely done anything in game development, but in terms of engine, what has been better for you as a solo dev?
Risk of rain comes to mind as a great multiplayer videogame with a small team, it was made with gamemaker studio.
I am curious how is the ecosystem right now and if Godot has become a more attractive option for solo/indie development.
Really liked the article, I think there is also something to be said about the difference in learning game design and game development. I think people tend to want to do both at the same time, but spending some time just on game design can help you feel less helpless when learning development.
If I learned something every time I failed to finish a game, I'd know a bunch of things now.
Dont you?
Maybe they didn't read the article and thought it was about someone failing to play a game till the end.
I really enjoy living vicariously through indie gamedev retrospectives like this. Both technical and non-technical sides.
Nice work and best of luck with taking game #3 forward!
I started building an iso game a couple years ago and like you was not looking forward to having to make so much art. Then I had an idea. Build it in a 3D engine and lock the camera in an iso like position. Now I can use 3d models and not have to worry about creating all these different views. Also you could do effects when walking around the board by spinning the camera and then locking it in a different iso position. I'm pretty sure this is how newer iso games are made.
If you are using a 3d engine that doesn't support actual isometric views, you can put the "iso" in isometric by moving the camera far away and at the same time zooming in on the object. This has the effect that all points of the object have roughly the same distance from the camera (compared to the huge distance you moved the camera away), so there is no perspective "shortening" of points farther away. This is especially important if you have rectangular wall segments that must fit together.