Two things I've learned from game development

I’ve worked my entire career in web development. I’ve done backend work in PHP, Node.js, Python, Ruby, Java, etc., and frontend browser coding in JavaScript and TypeScript. Working in just once niche like this gives you certain ideas and impressions, and it’s easy to assume things work the same way in other niches of software development as well.

Here’s two things I’ve learned from doing game development as a hobby, which are contrary to what one might think based on just doing web dev.

Sometimes Subversion is better than Git

I’ve been hanging out a lot in the Unreal Engine Discord community. One thing that surprised me was learning that game developers actually prefer using Subversion over Git. Well, actually they seem to like Perforce, which I tried installing and immediately disliked, but I digress.

Back when I first learned about source control tools, Subversion was the go-to, but I think nowadays Git has entrenched itself as the tool of choice in many programming niches. So how is Subversion better than Git? In game development, you often deal with binary file formats. Subversion works better with these, and it provides file locking which Git does not. Locking might sound archaic, but when working on binary files, it can reduce issues because you can’t do merges into them. This can be a problem especially in larger teams.

There seems to be some git extensions like git-lfs which attempt to address these challenges, but at least out of the box, it seems Svn is often preferred over Git in gamedev.

One millisecond is a long time

I’ve done a lot of performance optimizations at work these days. We have a large browser-based application which shuffles data around and processes it, does large UI updates, etc., and performance issues crop up from time to time especially in cases where the amount of data is larger than average.

Typically this manifests itself in some action taking a few hundred milliseconds. Typically the fix is good enough if it’s reduced to under 100ms, ideally into 10-30ms. At that point, it becomes less noticeable to the user under most circumstances. At least in the types of applications I’ve worked on, you rarely need to be any faster than that when reacting to user input.

But games are an entirely different story. A typical PC game should run at 60 frames per second as the bare minimum. This means you only have about 16 milliseconds in total to do everything your game needs to do in a single frame: Game logic, entity AI, collisions, rendering, etc. - and the boundary gets even tighter if you want to hit “good” framerates like 120 fps, at which point you only have around 8 milliseconds to do all the work.

So in game development, 1 millisecond is a long time. I don’t think Chrome’s performance tooling even shows you values below 1ms, but Unreal Insights displays microseconds, and optimizing code to run in sub-millisecond time can actually matter. In many games you also control a character directly, so the framerate must also be consistent or the player will notice hitching. This makes performance optimizing games quite a different task from the average web app.

Thankfully nowadays browsers are quite performant, but it wasn’t always like that. Back in 2009, I wrote about Optimizing JavaScript for performance and memory consumption, and the tricks I had to use back then were kind of ugly.