Recently I surveyed a large group of industry executives, seeking information on their thoughts and perceptions of game engine middleware. Last week I shared the general results of that survey with you; this week we’ll talk about some of the technology-related results.
The survey was split into two sections, one for production-oriented folks, and one for technologists. This blog post will describe the results from the technologists, who were largely CTOs, VP Techs, Tech Directors, Engineering Managers, etc. The questions were focused to get their opinions about game engines in general, not feedback on particular ones: what features do they look for in a game engine, what tools do they expect, what engines are they currently using, that sort of thing. We could have delved much deeper into this, but perhaps that’s something to address later.
As discussed last week, the responders to this survey leaned heavily toward what is considered the “core” game industry, with their current games being designed for these platforms:
As a result, feedback on engines which run primarily on Mac, Linux, or iPhone did not accumulate enough information to make the results statistically significant.
55% of the responders stated that they are using a middleware game engine on their current project. Of those people, 39% are using Unreal, and 22% are using Gamebryo, with other engines landing significantly smaller percentages. But our survey showed that only 9.3% would actually choose to use a licensed game engine if they felt they were able to easily do otherwise. If that’s the case, why are all these people using game engine middleware?
These were the only responses that achieved over a 50% “yes” rate, and they echo some of the things we discovered last week: one of the primary reasons for using a game engine is to give the content creators more time to work on the title, especially during the prototyping and early concept stage. When a tech team needs to create an engine and tools from scratch, it’s harder to give the artists and designers something useful to work with right away. Giving the content creators valuable prototyping tools should conceivably result in more refined or unique gameplay. Similarly, using game engine middleware should allow the programmers to focus on creating technology that distinguishes the game from others of a similar genre. One commenter mentioned that they like using a licensed game engine because it’s easier to hire people who are already familiar with it, as opposed to bringing someone up to speed on a custom engine!
As echoed in the results from last week, we again see the idea that perhaps a game engine can help us develop a game more quickly, though one of the lowest valued benefits in this section was using an engine to reduce engineering staff headcount – the technologists by and large don’t believe that using an engine will allow for smaller tech teams, rather the team will need to remain the same size but the extra resources will be used to more effectively distinguish the game from others.
Using game engine middleware to bolster technology sharing across multiple titles at a studio was low value, as was the idea of avoiding rewriting general purpose systems. The very lowest rated reason to use game engine middleware was the idea that purchasing a game engine would give you state-of-the-art technology from game engine specialists! Clearly, this is not an idea that should wind up in any engine’s marketing material.
On the other side of the coin, the technologists expressed substantial concerns about using middleware game engines in general. The results echoed back some of these same themes. What concerns do they have?
The strongest concern is that a particular game engine may not work well for your game’s genre. One of the things game engine manufacturers should be doing to aid technology decision makers is highlighting games of various genres that use their tech, in order to demonstrate that the engine works well for those genres. Most of the engine manufacturing companies at this point also make games themselves – certainly this is a great way to highlight that an engine excels at one particular genre, but it can also reinforce the belief that it is only good for that one. There’s also a potential unfortunate side effect if that game fails in the marketplace or plays poorly. It could spell doom for sales of the game engine!
A strong theme coming out of the technologists’ comments in particular is the difficulty of working with and modifying an unfamiliar code base. It is stated repeatedly in multiple sections of the survey – it is the most important thing next to genre appropriateness. Having access to engine source code helps out immensely, but being able to evaluate the engine to make sure that it integrates well with existing tools/tech is vital, as is the level of support. Commenters pointed out that they have spent more time debugging poorly-crafted middleware than they would have spent writing it from scratch themselves. And what if the middleware company were to go out of business, or be purchased? Clearly having source code helps immensely in these circumstances, but it’s a frightening prospect that should also be covered in any legal agreements.
Platform feature parity also came up repeatedly in the comments, especially around platform launches. Having an engine that runs well on one platform but poorly on another makes the engine as a whole only as useful as the lowest-performing platform. Chasing feature development in a piece of middleware by continuously re-integrating version after version is time consuming and aggravating for all involved, but sometimes difficult to avoid. Platform manufacturers would do well by the developer community to bring middleware engine and library providers into the development process of new platforms early.
The practices by engine manufacturers vary significantly, in terms of support, source availability, delivering and sticking to a roadmap, etc. What do technologists really want from their engine provider? We asked about a few important practices to see which would stand out. Here’s what stood out as being most important:
Clearly having source code access and easy integration with other middleware libraries is most important, even more important than details of the engine itself, such as having the ability to modify memory allocators. Some of the engine providers give continual access to new engine builds, and this is valuable indeed but it seems less valuable than the currently working feature set. The fact that having a clear engine roadmap is judged as having the same value as ongoing access seems to imply a desire to lock in on an engine version and not worry about upgrades during the development process (something mirrored in the way that many studios lock in on a version of their third-party tools during the span of a game’s development).
One very important comment about having an engine’s development roadmap was made by someone who said “I would not purchase nor use any middleware where I am dependent on a future feature – tying my studio to the whims of development of a third party is not good business.” I think that says it all.
Looking at the various game engine options available, it’s clear that different engine manufacturers have different definitions of what “game engine middleware” should provide. What systems should be included in an engine? Should the engine be a completely custom and thorough system, or simply a thin base layer into which middleware libraries from other vendors can be easily integrated? Here’s how the responders replied to the importance of various engine subsystems or features: