The More I Learn About Game Dev, The Less Simple It Looks

It isn't that any particular element is especially difficult, it is that most people severely underestimate the elements.

• It's a software project, so you need software engineering skills, either your own or from other people hired to do it.

• Unless you're building a text adventure it's an artistic project with images, so you'll need art skills, either your own or from other people hired to do it or purchased art.

• If you want those things to use 3D models, it needs modeling skills. (again, either from you or from other people.)

• If you want those things to move, it needs animation skills.

• If you want music, you'll need music composition skills.

• If you want sound effects you'll need sound and Foley skills.

• If you want fun game mechanics, you'll need game design skills.

• If you want storytelling aspects, you'll need storytelling skills.

• If you want it to work reliably for many people on a variety of hardware, you'll need QA skills.

• If you want people to know about it, you'll need marketing skills.

Each can be your own, or come from other people, but if you want them in the game someone needs to do the work.

Then many people imagine up in their mind projects that cost tens or hundreds of millions of dollars. They want a project they can do as an individual in a few weekends as a lone novice, expecting the results that took a few hundred industry professionals multiple years of work.

An individual can do it, there are people who have skills in all those areas. I'm a veteran programmer, I'm a decent enough musician (pianist and organist) who can do light composition, passable artist particularly with sketching and watercolor, but in the professional world on only one of those skills gets the job title. Having all the skills lets me more easily talk with people among the disciplines, and I have the ability but not inclination to do a lone wolf project.

sophie-talks said:
Coming from more of a gaming/business interest side, I used to think the process was basically just “learn an engine and make a game.” Clearly there’s a lot more depth to it than that.

The popular engines, especially Unreal & Unity, are developed by massive corporations and are aimed at massive studios, with the goal of providing an extensive tooling suite that allows art teams with no technical knowledge to produce art & content without having to bother the programming teams. They are basically intended to act as a project management platform for large teams where the individual teams have nothing to do with each other. But that also comes at a cost: these engines are overly generic and it's hard to do specific things in them, and they are tailored towards the logistical needs of large teams. And what also nobody tells you: the large teams those engines are made for also have dedicated programming teams who write lots of code by hand. The blueprint functionality is not meant to replace serious programming. It's there so that some artist or designer can clobber something together without contacting the programming team. They are slow and clunky, but usable by a non-technical person, intended for solving tiny, simple problems quickly (or for allowing a level designer to do stuff like “this lever should open that door” on his own).

Indies don't have the logistical problems that the big engines try to solve in the first place. The main bottleneck for an indie is producing enough polished assets: models, textures, animations, sprites, tilesets, sounds, etc.. A 1–2-man team can only make games that are very limited in scope, even if they spend 2 years on a game. The kind of economy of scale effects that these engines try to tackle don't even occur at that scale.

So what you really need as an indie is something that lets you easily build & iterate on the code. Using the big engines actually complicates that, because you have to work around the engine's interfaces and systems, to do things that are supposed to be pretty straightforward. Look for example at the recent thread about collisions for a brick breaker game or this thread about getting a sprite to jump in a 2D platformer. Having to work with the engine actually massively overcomplicates the work, because you don't just have to figure out how to solve the problem, but also figure out how to do that using the functions the engine ships with. Which means you need to research a lot of documentation and get lucky and find the right things, like the “rigid body” subsystem of Unity being responsible for that kind of thing, apparently? So you have to already know the right terms beforehand to even find the functionality you need. Versus when you build it yourself, you can make something simple on your own just by thinking about the problem and then writing code that does it, without being forced to go through the engine's facilities to do it.

sophie-talks said:
What’s one thing you wish someone told you when you first started learning game dev?

To not try to solve anything with object-oriented programming. Object-oriented programming is a paradigm that makes you solve every tiny bit of work in isolation, and in a generic way (usually even handling eventualities that don't actually occur in practice) that has as little prior contextual knowledge as possible. But when you have to process 100K things of the same kind, then it would be orders of magnitude more efficient to write code that processes them in one bulk operation, with all knowable contextual knowledge baked directly into the code, rather than processing them all individually and pretending that this is some kind of generic process.

Talks like this one or this one were quite influential for me, as well as Casey Muratori's performance oriented series of lectures, the Data oriented Design book and the uops.info reference for understanding CPU performance.

For game design, the Indie Game Clinic channel on youtube was quite good, it teaches first-principles-based thinking about game design. I wouldn't recommend focusing too much on the individual points he raises or advice he gives, but rather, take him as a great overview over all the aspects that are relevant and that have to be considered. Because there are lots of blind spots that almost every indie dev falls into.

And of course finally, all the failed indie game videos, although rarely do those developers actually come to the right conclusions and understand why their games failed.

sophie-talks wrote:

What’s one thing you wish someone told you when you first started learning game dev?

Interestingly, nothing comes to my mind when thinking about this question.

Contrary, i could not stop talking to my former self if it was about proper guitar technique, for example.

I guess this is because for the latter i did things wrong initially, it took time to unlearn them and trying something else, only to figure out years later they don't work either, trying something else next.

But for gamedev i did not really have this problem. I did things wrong too, but changing programming habits is easy and quick, so learning from your own mistakes is actually a good way of learning. Also, because i've started out in the 80s already, i could not really learn in the wrong order. 3D games existed but were rocket science, so i had to learn 2D first. Programming languages were simpler, the hardware was simpler, and so on.

That's why i personally recommend to learn gamedev in chronological order. Starting with Pac Man is better than starting with Doom, C is simpler than C++, etc. You need to learn less at once, so you learn faster and memorize better.

If i would start with gamedev today, i would probably pick up Unreal and try to make some FPS game with their visual scripting.
And only years later i might understand what steps a realtime application actually does, how the underlying math works, who calls my scripts and when, why some things are expensive and ruin performance.
I would surely notice i have done things wrong or inefficiently. And maybe fixing those flaws would be just as hard as fixing my guitar technique is now.

BTW I made a 2D tower defense game in SDL when I was maybe 14 or something, and then a minecraft clone in OpenGL 1.1, when I was 15 or something. I started programming at 13 when I got a C++ book. So, C++ is definitely a possible beginner language despite what people claim online when they whine endlessly about it. Though I would nowadays recommend C instead of C++, because it doesn't try to hide anything from you the way idiomatic C++ does.

If you're making a 3D first-person game, I recommend either doing something like minecraft, because that's the simplest thing you can possibly make: it doesn't have complicated physics/collisions, the terrain rendering is straightforward, and you also don't need complex animations, and the terrain geometry is also trivial. The reason why people use big engines is because those come with a large library of pre-existing systems that you can use, like having a mannequin walk around and adapt its posture to the terrain shape and all that.

If you're making a top-down/bird's-eye 3D game, like in a strategy game, then you don't need nearly as sophisticated animation technology, because the terrain doesn't need to be as detailed and also the figures aren't shown up-close. However, writing a good AI for the computer enemies is pretty hard (though that's actually true for all games that have computer-controlled characters of any kind). But an engine can't help you with that anyway, because the AI has to be made explicitly for your game, with a deep understanding of your game's mechanics and systems. Most RTS games simply let their AIs cheat, just like basically all racing games give rubber-bands to their AI, so that they get a speed boost when they fall behind the player, which is extremely frustrating. And in FPS games, the AI simply gets an aim bot.

These are the actually hard parts of making games for which you definitely need to be able to program in order to solve them. An engine can't help you with that, and if you do those parts poorly, the game will be unenjoyable, regardless of how fancy it looks.

I initially wanted to make a racing game for my current project, but we decided against it, because we weren't really sure about how to deliver polished environments in a 3D game, even if we also used 2D pixel art billboards in the environment. So after a random incident, our current game is a 2D platformer, which can be roughly considered to be a metroidvania game, maybe, although it doesn't fully fit that genre. The only big uncertain part (in the sense of maybe being too hard to solve) in this game is making the AI feel good. In the racing game, we had several such headaches that could break the game if we didn't manage to solve them, or didn't manage to solve them before we run out of money/time. However, racing games, besides minecraft-likes, are actually the lowest-effort 3D games in terms of assets, etc. They don't even need animated characters, because cars are basically just static models, and the spinning wheels are also trivial to do even without an engine. And then all you need is heightmap collision detection.

Also, a common misconception is that 2D is definitely easier to make than 3D, but making a 2D game can actually take way more effort than making a 3D game, because the asset creation can be that much more complex, especially if you want animated sprites that for example show the equipment a character is wearing. You quickly end up with a massive amount of permutations that you need to animate, even if you split up the sprites into individual components that are independently animated. For such a thing, a 3D game is actually easier to pull off, because you just model each equipment once, and each character once, you annotate the models with joints & bones, and then you do each animation once per character, and then you're done. And many similar characters can even share animations.

If as an indie, you make a 2D game, definitely make sure you plan for something that doesn't require you to make 1000 sprite sheets. 2D pixel art is extremely fast to make, especially for static props, so you should play into the strength of the medium.

Game dev is a never-ending snowball of skills you can learn. First, you learn basic coding in Unity, but you don't want to pay for someone else's assets, so you learn to draw basic pixel art. Then you realize that your game has no sound, so you shoddily learn Fruity Loops to make music and sound effects. Then Unity does something to piss you off, so you hop off it and try and make a custom engine and that takes a while to learn; then you grow tired of 2D game programming, so you jump onto 3D programming with Unreal Engine, but that's C++, so you have to learn that. Eventually, you get fascinated with 3D graphics, so you have to learn all types of different math concepts: linear algebra, trigonometry, etc., etc. Eventually, you find yourself writing devlogs about graphics APIs. This is how it was for me, at least, a never-ending snowball.

I didn't even bring up animation, rigging, texturing, 3D modeling, or even just writing! Game dev really is never-ending.

NoticeSmeh wrote:

a never-ending snowball.

And then if you actually kick something out the door and put it in front of others, even if only a $0 high quality mod of some existing game, you learn a really painful reality. All that techno babble that you invested in, doesn't count.

At the end of the day, it's hard to get people to even discover or pay attention to your work. If you were using someone else's web servers to disseminate your work, whether that's Reddit or a fan site for the game, both can completely implode. I happened to mod a very old game, and then Microsoft decided to change Windows 11 in such a way that the GOG binary for the game broke. And then GOG doesn't fix it, even though someone made a patch for it.

So it's like, good God, what a complete waste of time. Not sustainable. Controlling your own destiny isn't easy, because of the abundance of infrastructure you actually need to do it. All that techno-wonking about picky 3D equations doesn't really count. You get insulated from that reality when you're someone else's employee, but when you have to mange the success of the product from start to finish, it's ugly.

Even if you vibe code, it’s still good to know how object-oriented programming languages like C++ work. It wouldn’t hurt anyone to do some introductory C++ projects.. small projects at first.

Of course, there was no real vibe coding when I first started programming, that’s how old I am. :)

taby wrote:

Of course, there was no real vibe coding when I first started programming, that’s how old I am. :)

The term was coined in February 2025

yeah, kind of a weird flex, haha