We take a little break from our “What Makes A Game Tick” series to get a little bit philosophical about the topic of performance and what it means for different people.
I was at CppNorth a month ago and after listening to a few talks and having conversations with fellow speakers and attendees I realized that despite all of us being here because we care about performance to some degree (else we’d all be doing Python or Javascript or something) when it came to nitty-gritty details, I wasn’t sure we were talking about the same thing. And maybe that could explain some of the disconnect I can sometimes observe between various industries talking about using C++ on social media?
Let’s talk about game simulations. In this episode we go back to code architecture and check out a few approaches to using multiple threads.
After a threepartdigression about scripting, it is time to revisit our first two articles. Back then we mentioned how some of the common engines on the market handle ticking in a somewhat crude virtual void Tick() {} fashion. Today I wanna show some alternatives I have used when making Grand Strategy Games.
Let’s talk about game simulations. Today we look at some more real life script performance issues and discuss the two hard problems in computer science.
Last time we studied one real life case of script performance related to gameplay. While it required a bit of game knowledge, and perhaps more software engineering experience than what we expect designers to have, it was easy enough for us to fix and could be done entirely without access to code. But sometimes studying those performance bottlenecks reveal problems that run deeper and require some re-engineering to be properly solved. Today we look at an art bug from early Victoria 3.
Let’s talk about game simulations. Today we look at some real life script performance issues I had to fix.
In the previous article I brought up the idea that scripting in games can often be a source of performance bottleneck because it’s a powerful code-like tool used by people who are usually not trained to be programmers. And to be honest I expected to get more flak for it, but to my surprise the comments were mostly pointing out games that figured out how to restrict scripting for better performance (although interestingly all of them were using bespoke engines rather the most commonly licensed ones). So I figured this week let’s look at some “bad” script and discuss how we got there. My hope is that this will give both my designer and programmer readers some insights.
Let’s talk about game simulations. In this episode we bring up scripting and the challenges it brings to architecture.
Scripting and editors are great for productivity. They allow designers and artists to work and iterate on gameplay and level design fast. They are also one of game programmers’ worst nightmare. And I’m not talking about implementing or maintaining them (not that it’s an easy job, more like it’s a different conversation). Today I want to talk about the impact on game performance that scripting languages and associated tools can have. And the more powerful they are, the worst it can get.