4.16.2012

Some thoughts about flexibility of game engines

I've been thinking about this for a while now and for some reason I cannot help but it seems that there are atleast two different approaches common in video game development about how much flexibility is wanted in a video game engine. On one side you got the modern approach of given a simulation base connected to a scripting system and high level access to stuff like when and how to apply what sort of shaders and to which objects and so on. This requires a lot of work and brings a base for companies doing only this and nothing else or just a very small amount of games to show off engine features with adding any sort of nice gameplay (like Epic Games, just saying). On the other side there's the specialized engine made to feature a fixed set of things, like seen in countless game series by studios that only do a few different games. Personally, I always preferred the specialized approach because it brings a certain sort of philosophy, that there are things that will always be included, that it is known what will be featured in a game. I will never know what sort of engine my favorite games have besides those where the studios are more opento informing their fans or so. Or small indie studios that blog their process and so on. But especially for console games, I just don't believe that use interpreted scripting languages or stuff like that just to feature more flexibility. I simply don't believe in it. PC games can feature quickly interpreted languages with small amounts of scripted code because they are usually faster and more powerful. But since interpreting does always bring shitloads of commands to interpret (well, using a scripting language's syntactic sugar is the key to keeping it quick I guess), it's a total waste of execution time and also memory. Just take S.T.A.L.K.E.R for example: it parses stuff almost constantly and you'll notice that when modding it a bit. There are mods showing how incredibly wasteful a single script can be and it also explains why it often takes heavy lags when triggering quests and so on. I can't tell for sure but as far as I remember, there's more scripted than good the engine. The first part was sort of acceptable, the second was a true nightmare in terms of lagging events and the last one reduced every scripted AI to a minimum to have almost immediate scripting response. That's what I noticed because the engine core was still the same.

There are also other examples that base on VMs. Thinking about it, Minecraft is a good example hat's possible to "script" with a VM-based setup. Essentially all Java games can be seen as VM-based game footage. Most flexible-to-script engines either utilize their performance very well by not using scripting that often or limit themselves to very basic and fast features. There simply is not much of a different trade-off besides using non-interpreted languages - you have to sacrifice stuff in any way. That said, I'm more a fan of specialized engines that only have the stuff that's really needed for the game. This is also the way I'm thinking of video game creation: choose a set of things your engines should feature and then make a game out of it. Well, I'm also quite conservative about the games I play, so I can't say that this works for those game designers usually doing the work in professional games nowadays. Both extreme approaches have their advantages and I will not try to judge about which is worse and which is better. My personal vision of having a VM-based scripting languages with my very own set of stuff and commands is still what I strive for. Bad side of both approaches is that it takes a shitload of work and thought, so they are both equally demanding on the way...

No comments: