Friday Facts #59: Fail Fast
The Game Awards 2020 were last night and this unprecedented year had some unprecedented games. And I’m not just talking about TLOU2!
The winner of the best strategy and simulation game was Microsoft Flight Simulator, a game that originally released in 1982! The program and the company have come an extraordinary way since then. MFS is an amazing piece of technology that deserves the accolade, but it puzzles me to think that if NewCity were somehow nominated we’d have to compete with it. It’s not a similar simulation at all!
The city building genre is a niche that deserves more recognition this year, which brought us wondrous games like Per Aspera or AoE3: DE. NewCity has a lot of cards up its sleeve, yet to be played for 2021.
I’m an active follower of SpaceX. You might have heard that their “$216 million Mars rocket EXPLODED” this week.
Of course, the headlines don’t tell the real story. SpaceX didn’t fail – to paraphrase Thomas Edison, they found one way of landing a giant rocket that didn’t work. In technology (and in many other areas of life) you need a high tolerance for failure before you can eventually succeed.
You may have noticed that this week’s NewCity update was a little light. That’s because I was working primarily on behind the scenes work. Specifically continuous integration, or CI, which means having a server that can automatically compile, package, and deploy the game. We want to reduce the amount of work that Supersoup and I have to do every time we release a patch, and having an automatic system for the entire process will give us more time for programming.
Setting up a server to compile the game for Linux was pretty easy, since Linux has great support for scripting. Building for Windows has been the hard bit. There are two ways I could make the Windows build. The first approach is to set up a Windows server to build the game using Microsoft Visual C++ (MSVC), the standard compiler for Windows.
There’s two problems with this; firstly, if the game is built on two separate computers, then the two builds would have to be shared between the machines to be packaged together, which is certainly possible but would be complicated. The more fundamental problem is that I have no experience scripting or automating on Windows, and I don’t even know what to Google to find out. (Knowing what to Google is half the battle.)
So I started investigating the second approach: an obscure compiler that can build a Windows exe on a Linux system, known as Mingw-w64. Actually, this was how I originally built the Windows exe, before Supersoup joined the team. At some point along the way, compiling on Mingw was broken, and we got into the habit which we are now in: Supersoup manually builds an exe with MSVC, shares the file with me via Google Drive, and then I run a script to build for Linux, package the game zip, and manually upload to Steam.
I spent much of this week trying to get the Mingw build working again. By Wednesday, I thought I had cracked the problem, having set up a server that could compile, package, and upload to Steam the game for both OSes, and that (mostly) worked for Windows. However, when other team members tested the build, it crashed often. And there was a worse problem.
If you know anything about programming, you know that it’s mostly about functions. Some programming languages use different terms, such method, subroutine, or procedure, to refer to the same basic concept: a bit of code that can be “called” at any time to do some useful work. Functions often call other functions, and at any given time, there is a chain of functions-calling-functions which we call “the stack.”
When something goes wrong, it’s extremely useful for the programmer to know what the stack was at the time so we know where in the code the problem occurred. This is called a “stacktrace” – the list of the functions that was called leading up to the problem.
When NewCity crashes, it writes into the log file a stacktrace, and we read the stacktrace to determine what caused the problem. It’s usually pretty easy to fix the problem once we know where in the code it happened.
Internally, the computer doesn’t see words, only numbers. You can learn more about this in a past blog post. To a programmer, functions have names, but to the computer, they are just numbers. When generating a stacktrace, the computer translates the numerical addresses by which it knows the functions into names that are familiar to the programmer. But the computer must have a map of numbers to names. And that brings us to the problem with Mingw.
When a stacktrace is produced in a Mingw exe, it only shows the numbers, not the names. Without a way of translating numbers to names, this is completely useless to us humans. I’ve tried several different methods of producing stacktraces, and I even tried implementing my own solution to the problem. However, I have not been able to get accurate stacktraces from Mingw builds on Windows. And without good stacktraces, I can’t find the cause of crashes and bugs.
So, for now, I’m calling the Mingw approach a failure. I’m betting that there aren’t any other commercial games that are built for Windows with Mingw – it’s just not the way things are done. Even if I can get a Mingw build working, we will also need to know: is it better or worse than MSVC from a player perspective? The relevant metrics are, is it more or less stable? And, does it give a higher or lower framerate? We currently don’t have a firm answer to any of these questions, and it could go either way, but intuition suggests that MSVC would be better.
We’re still working on this, because we really want CI. My next attempt will be to create a Windows MSVC build – the first approach. I will have to learn how to automate Windows and I will have to find a way to share the file between two systems. Shouldn’t be too hard.
But first, I want to get back to real programming. It’s been a while since we had a significant new feature for NewCity, and there’s some things I’ve been itching to implement. We’ll have something new and fun for you before the end of this calendar year, so stay tuned.
Questions? Comments? Feedback on the game? Sound off on our Discord.
As always, we’re incredibly thankful for our great community across the web. We love seeing the hard work and attention to detail you pour into your cities, and it inspires us every day to keep building. Thank you again for your support.
If you want to play the game and haven’t got it yet, head over to our Steam page. We’re also on Reddit and Twitter. Give us a follow if you haven’t, and we’ll keep you up to date on what’s new with NewCity!