5 ms·
Game dev in general has a much tighter feedback loop than most software. If you're leaking memory, you're doing that a hundred times a second. If your code is s
by martindbp 11mo ago
Game dev in general has a much tighter feedback loop than most software. If you're leaking memory, you're doing that a hundred times a second. If your code is slow you get visual stuttering. If you want performant code you need to think about things like cache coherence, you can't use GC etc.
- piker 11mo agoI agree, but that's really true for questions like "does it run fast"? And those kind of arguably fit into the "legible" camp. Whereas "is it fun?" is a question less able to be formally tested and articulated. It's "illegible". The tighter feedback loop that helps to answer that question comes from dogfooding.
- Pannoniae 11mo agoI agree with you for almost all of this, just a small nitpick: GC isn't really incompatible with games, for the overwhelming majority of games, it's basically a non-factor in performance if you spend even the slightest amount of time on performance. It's kind of similar to native code - don't allocate too much, reuse resources, don't leak them uncontrollably. It's only a problem when you need guarantees (i.e. the game should never drop a frame) but basically no game fulfills that nowadays and it isn't a player expectation.
- gnulinux 11mo agoGC is ok as long as you aren't writing some factorio-like etc. Modern computers are perfectly fine doing shit ton of useless stuff 120 times a second without blinking an eye.
- martindbp 11mo agoIf you're allocating stuff every frame you'll run into problems quickly. Sure, you can use an object pool or arena allocator, but then you're basically circumventing GC.
- yencabulator 11mo agomalloc often isn't fast enough for games either; arena allocators and ECS came to be for a reason.