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.
Let’s talk about game simulations. Today we ask ourselves basic architecture questions.
Most game engines handle simulation tick by calling an overridable method on each game object. Why is that? And is that the only approach out there? Isn’t it odd that a very objected-oriented approach is the default in an industry that keeps complaining that OOP is bad and we should do data driven instead?
Let’s talk about game simulations. And how to make them go fast.
A lot of articles I read about game development focus on performance (and also retvrning to C, but that’s another topic entirely), and yet they seldom talk about game simulation. They often focus more on graphics and asset loading/streaming. This might be because they are often bottlenecks on AAA games, but that’s not the only type of games out there. And even for a AAA style game, I ‘d argue this is an under discussed topic. At best it will come up when talking about “large” number of AI actors. It’s probably no coincidence that Unreal’s Mass Entity beta framework is found under their “game AI” section in the documentation.