Making the most of middleware

Follow us on:

Developers share their approaches on when to rely on proprietary tech, and when to bring in externally built tools to improve the quality of your game.

Few developers have the resources to build video games solely from their own technology. From even the most ambitious indies to the biggest AAA studios, almost every team making games requires additional software that can integrate with their engine and other tech to enhance key areas of their project.

Collected under the umbrella term ‘middleware’, the range of tools on offer to studios is incredibly broad - from those dedicated to entire disciplines such as audio (with widely used examples including FMOD and Wwise) or physics (such as Havok or PhysX) to very specialised areas (such as vegetation modelling middleware SpeedTree).

The reasons for using middleware, rather than taking the do-it-yourself approach, are manifold. Tim Chapman, technical director of Electric Square’s Reactor R&D team, says studio using these tools “save significant production time and expense by not reinventing the wheel.”

Meanwhile, John Fuller - chief technology officer at Just Cause developer Avalanche Studios, says that new and unique approaches to development tools and tasks can take a long time to research and develop - and might even prove to be fruitless.

“They’re generally things we’d shy away from in our own development and go for something that [already works], and then we can move on to another area,” he says. “Those types of middleware can give us higher quality in a certain area.”

He continues: “We want to put our most experienced talent and expertise into the areas where we feel we have unique selling points, where we do something different or our engine does something special, and pushes certain aspects of our games that people won’t see anywhere else. That’s where we want to put our cycles, and if we spread ourselves too thin, then cycles can be stolen from those areas. Middleware can help in that area.”

James Levick, CTO at mobile racing games studio Hutch, adds that it also makes recruitment easier in that you can advertise for candidates with specific skillsets, and it reduces the need for training when compared to getting a new starter up to speed with a proprietary tool

He adds: “In the case of open source middleware you’re also benefiting directly from that developer community, and with experience are able to identify and fix issues yourself directly if needed, which is very powerful. Middleware can also often improve portability, allowing you to run on multiple platforms without much additional work.

“Ultimately, as a developer you have limited resources, so it’s best to invest your limited time on enhancing what differentiates you from the competition, rather than painstakingly implementing new technology that already exists in a packaged form.”

That’s not to say middleware automatically makes games development easier - far from it. Each product can come with its own flaws and disadvantages, and even if it doesn’t, it might not be a perfect fit with any proprietary technology you are using - a discovery that Avalanche has found to be “costly and time-consuming” to deal with, according to Fuller.

“There is always a ROI calculation to do,” he says. “That’s not usually something they print on the front of the brochure, they usually assume integration is easy. But there are always hidden complexities to these things... You might get a piece of middleware that was built on PC and runs well on PC, but then it was an afterthought whether it runs on PlayStation or some other platform.”

Fuller speaks from experience; he previously worked in middleware, helping to develop widely-used physics tool Havok in its earliest days. As such, he knows that middleware firms ultimately retain full control over their technology, which can cause issues for studios like Avalanche.

“Sometimes we don’t have the source code, and that introduces the potential for stalls in our production. If we find a bug, even if we can localise it and identify it - even if we know how to fix it - often we have legal or technical constraints so we have to live with that bug for however long it takes for the partner to put some resources on it and send us a new release.”

Developers are also beholden to price, Fuller says, which may change over time - something that will affect titles that have longer development cycles. The Avalanche CTO says his studio have at times been held hostage and the goalposts are moving” in such situations.

Other complications can arise when a middleware provider is acquired by a larger company, with Fuller pointing to EA’s 2004 acquisition of RenderWare as an example.

“A lot of people had ditched their proprietary renderers, licensed RenderWare... and then EA bought it,” he explains. “Many companies had to give out a company-wide edict: ‘We can’t release a game that is built on an engine owned by EA. Let’s pause all development and write a new renderer.’ That’s the nightmare scenario, but it hasn’t happened as often since. But the rate of acquisition for middleware components is as high as it’s ever been right now.”

Game engine providers are particularly notable for acquiring middleware tools and using them to enhance their engines. Interestingly, two of the three companies we spoke to consider engines to be middleware, although there are those that debate they come under their own category. After all, you can build an entire game with an engine, but not with a single piece of middleware.

Chapman adds that it’s important to strike a balance between the use of middleware and your own technology “Middleware's one-size-fits-all solutions necessarily introduce comprises and trade offs. Bespoke custom solutions still remain the only way to squeeze the last drops of performance out of the hardware platforms that cutting edge video games require.”

Levick agrees, adding: “Overuse of middleware can also have the potentially damaging effect of increasing the parity between you and your competition, thus taking away what makes your output valuable. It’s important to continue to maintain control of the areas where you’re adding your personalised stamp of quality.”

With such a wealth of options out there, finding the right middleware for your project can be “an art in itself,” according to Hutch’s Levick. It’s not just about whether the tool meets your requirements on paper; you also need to take into account performance, the availability of support and documentation, how it will affect your workflow, what training is required, any potential security risks, and more.

“Generally you’ll need to perform an in-depth evaluation, preferably on your own terms as opposed to through demos and sales calls with the provider,” Levick explains. “Testing and integrating it with your code and systems, evaluating performance, support responsiveness and so on are all highly important parts of the process.

“Recommendations from contacts you trust can be very useful to find the right direction, but it's important not to forget that the market leaders are often leaders for a good reason. So don’t economise for the sake of it when looking at commercial products, but definitely do consider strong open source products as well before locking yourself in.”

Huw Bowles, studio R&D lead at Electric Square’s Reactor R&D, adds: “In pre-production, we evaluate different solutions and see if they can be adapted to the project requirements, or perhaps if the project requirements can be adapted to the middleware. It is usually not possible to test in truly representative conditions as the project has not been built yet, so experience from previous projects is used to make judgement calls. Then a decision is made whether middleware is the right path, or if the tech should be built in-house.”

Fuller adds that new technology and development techniques are emerging all the time, and new middleware with them - examples including machine learning, or advanced facial animation. Avalanche is constantly evaluating whether it would be worth researching and integrating this directly into its own tech, or whether it might be “more cost effective for us to go with someone who has already done that and save us some time to market.”

The ever-changing landscape of games development technology is also bringing the engine and middleware spaces closer together, as Electric Square’s Bowles observes.

“Unreal and Unity are extending their feature sets in pursuit of becoming 'complete' game development solutions - adding UI, networking, audio and so on,” he says. “This in turn reduces the need for additional middleware. In-house engines are becoming rarer over time, and some studios that were famous for in-house engines have made high profile moves to off-the-shelf solutions.”

But he maintains that there will be plenty of areas for middleware providers to specialise in the near future, pointing to the increasing sophistication of artificial intelligence as a prime example. Given the time and research required to explore AI’s full potential, few studios have the ability to delve into this in-house so it had become a popular area for middleware development.

“But despite many forays into this area so far nothing has stuck,” says Chapman. “The interesting parts of video game AI behaviour are typically highly product specific, which doesn’t mesh well with the middleware need to adopt standardised solutions.”

Finally, Hutch’s Levick says the continued adoption of cloud technology is also opening new opportunities for middleware, whether it’s a smaller open-source package with a specialised role or a full backend-as-a-service solution for multiplayer developers.

“This gives startups and small games studios access to vast amounts of functionality at little to no cost,” he concludes. “That is incredibly powerful; where previously a startup studio had to spend a year building an engine, setting up servers and so on, now they have access to turn-key options and can innovate and iterate quickly on the fun parts of a project, getting it to market quickly.”

Cookies

Making the most of middleware

Share this page