One of the big annoyances about working on MMORPG Tycoon 2 is the huge world which gets generated at the start of each new game. The release builds that I put up for people to test are fully optimised by the compiler, and when the game is started, the terrain typically gets built in a matter of seconds.
But when I’m working on the game, I’m not usually running fully optimised builds. I run debug builds, which are useful for testing features and debugging issues. And are much, much slower.
As of yesterday, it typically took just over 30 seconds for MMORPG Tycoon 2 to build a world, in a debug build. Which meant that every time I made a change to the code, it took 30 seconds for me to launch the game up to the point where I could test whether my new code worked as I expected it to. That’s long enough that I normally don’t just sit there and wait; I get bored, and start working on something else while waiting for the game to load. That’s actually a big, big problem. (It’s even worse when I’m testing AI, where not only do I have to wait for the world to build, I also need to interact with the world in order to get the world into a state where people start to subscribe to the MMO and I can check that their AI is working the way that I expect it to)
There’s an old bit of folk wisdom in development, which says that premature optimisation is harmful. And to a certain extent, that’s true; you really want to have a full picture of where time is being spent before you spend time trying to speed up anything in particular. Otherwise, you can wind up spending a lot of time trying to speed up something which was already fast, or which isn’t a significant contributor to runtime. This sort of folk wisdom is commonly used to cover all optimisation on games which are not yet feature-complete, on the basis that even if you’re doing profiling properly, you still don’t know what the full game’s actual performance is going to be like yet, so you don’t know what will actually be most useful to optimise.
In practice, there’s one big exception to this: iteration time. Anything you can do which makes it faster to get from writing code to seeing that code run in-game, that’s gold. Lots of mainstream AAA games do much of their game coding in a scripting language for that very reason; while the game might take a minute to boot up, they can rapidly modify a script and reload it, while the game is still running. In my case, all the code is native, and so anything I can do to make compiling and launching faster means that I can do more coding iterations per day, which means I can get more done per day.
Today, in a debug build, I’ve brought the world-building launch time down from 30 seconds to under 10 seconds. This is short enough that I don’t feel the need to find something productive to do while the game is starting up, which has once more gotten me productive.
Something else I’ve done today was to poke with the world generation. Compared against the terrains being built in the rendering tech builds from earlier this week, these terrains are about four times as detailed, the different terrain types typically have more interesting surfaces, and each region now contains more than one terrain type by default, which give players a reason to think more carefully about which regions they’d like to activate and make use of. Oh, and now they build three times faster than the old ones did.
