Dana Callista Lexa 🏳️‍⚧️

my takeaway from all the articles about nintendo's Tears of the Kingdom physics talk at GDC is that they basically rolled their own physics system, yes, but that their real success was in managing to, from a design and structural standpoint, put that physics design at the core of their development goals, such that rather than it having to compromise for the sake of other departments' vision, all departments' goals and tools stemmed directly from the physics system and when the physics was getting in the way the solution was not to stopgap it but to iterate and even add to the physics system until it facilitated that gameplay.

That's like. Really hard to do. I can't overstate how hard it is to do that. It requires not just a really strong top-down vision but a willingness to throw away a lot of traditional game design principles and tricks that would interfere with said physics design in favour of coming up with ideas that facilitate it instead. The amount of testing and iteration and organization that must have gone into this whole thing on an every-department level... my god.

So often, you're greeted with the splash screen of Unreal Engine or "Made with Unity" when booting up a game, two of the most common game engines today. These are robust and mature engines, but they're not always the best options for independent developers, according to longtime developer Rez Graham. At a GDC 2024 talk titled "A Case for Making Your Own Game Engine," he advocated for building games on your own tech through frameworks and libraries—existing tools that offer some major advantages and, admittedly, some disadvantages developers should be aware of.

Graham has been making games independently under BleachKitty following his work at Electronic Arts on The Sims series. From his perspective and experience, the most popular game engines aren't always the best fit for development, and it really depends on your goals and the type of game you want to make. That makes sense on paper, but he outlined several factors that need to be considered when deciding whether to build your own tech or work with existing engines.

Read our full write-up of the talk at Game Developer.

I appreciate that there's an argument to be made here depending on the goals and scope of your game but also "C++ programmer with 20 years of professional experience says you should roll your own engine" is advice I'd caveat fairly heavily compared to if it was coming from someone in a less technical role

I don't really think any of the problems people cite about game dev YouTube are endemic to YouTube or the YouTube format. Most game dev advice is awful, and most discussions about 'game dev' online are from a profoundly uninformed perspective. Poke your head in /r/gamedev for a sec if you really want to stare into the abyss; it's a truly Boschian hell of the ignorant giving advice to the disinformed.

And the industry doesn't really help this situation. If anything, it makes it worse in several ways.

First, knowledge is actually gatekept. I don't know how we can argue that it isn't when most GDC talks are behind an absurdly expensive paywall – nevermind the expensive ordeal that is attending GDC.

Second, I do think a lot of industry people have forgotten what it's like to be a beginner and are very eager to push people towards solutions that are practical for a real professional team but are not really relevant to someone trying to just make a crappy first game, join a game jam, or develop very basic and early skills.

Third, the industry has done very little to discourage the grifter industrial complex built up around game dev. The industry keeps supporting GDC, an event that is extremely friendly to grifting. It hasn't really done anything to distance itself from the various for-profit schools selling kids on 'game dev degrees' that the industry often doesn't take seriously when hiring.

Before I became a solo indie developer and made games like Chessplosion and Ducky's Delivery Service, I spent over a decade working for other game studios. I was mostly a gameplay programmer at AAA studios (~150 people) and "big indie" studios (~15 people), and I've done some engine/tools programming and some game design consultant work too.

I was going to write a big post on the game production process but I realized that most of it is pretty obvious. You come up with an idea for a game, then you make sure that the idea is good by prototyping its mechanics and planning everything out (also known as pre-production), then you make the rest of the game (also known as production).

It's just like any other type of art. You think of an idea for a drawing, then you sketch it, then you render the final picture. You think of an idea for a book, then you write an outline and a rough draft, then you write the final novel.

The only part that isn't obvious, judging from how I've seen this exact mistake being made over and over again on all sorts of games, is that you shouldn't move on from pre-production to production until you are 100% confident that the game is already good enough. I really cannot overemphasize how important this is. Ignoring this is by far the biggest and most common mistake that I see game developers make, and it is often game-ruiningly bad.