Why you should build your own engine

As a group eager to prove that a small team can develop a powerful proprietary engine, Cohort Studios built its Praetorian Tech.

In a frank and detailed guide, Cohort’s head of technology Gordon Bell details the engines development, and offers advice for those looking to do the same.

“Based in the Scottish game development hotspot of Dundee, we at Cohort Studios pride ourselves on our internally developed game engine, Praetorian Tech.

As a fully featured game engine with a range of rendering options and integrated support for middleware solutions, Praetorian represents some four years of continual development and proves that relatively small teams can compete with off-the-shelf products.

As Cohort’s head of technology, below I’ll go through the story of Praetorian’s development, along with the benefits and drawbacks of building your own engine.

Start with a ubiquitous, relatively open platform and then migrate
We began Praetorian on Windows PCs with a three-man team. The initial prototype was built in C++ with Open GL handling the graphics, and our intention from the outset was that the engine should be cross-platform rather than format specific. This meant working at a relatively high level and abstracting away from platform-specific APIs as much as possible.

As we knew we’d be working on PlayStation 3 for our main projects, migrating from Open GL to the PS3’s native PSGL was an early priority. Getting the first PS3 version going also involved writing some low-level components like memory, controller and I/O management, but on the whole it was a painless affair.

For the base code, we did stumble slightly by relying on heavily templated code within Visual Studio for the Windows prototype, which led to some heavy re-working once we compiled for the PlayStation 3 via GCC. We’d say that it’s incredibly sensible to test the code with different compilers nice and early, even if the engine isn’t ready to run on other platforms yet.

Integrate into a project as early as possible
Imbedding the engine coders into development teams for our first PlayStation 3 projects was an essential early step.

In a small company, engine development has to be focused on practical realities such as feature sets, deliverables and working to project milestones, and this is best achieved by applying ongoing engine development to a specific project.

As we had three PSN titles underway, we had perfect testbeds for Praetorian to grow within. After six months of progress, we’d added FMod for audio and a Collada pipeline to manage graphical assets with an export path for Maya and 3DS Max.

Once up-and-running, refine, refine, refine
One of the great strengths of owning your own cross-platform engine is being able to fully adapt it to each platform you’re working with. About a year ago, we decided to refine Praetorian on the PS3 by switching from PSGL to GCM for our graphics API. By this time, GCM had become something of a standard for high-end work, so we knew we had to make the swap to keep us at the cutting edge, which also gave us some nice optimisation headroom.

Our early decision to abstract out as many APIs as possible paid dividends here, as we only had to work on low-level renderer implementation with no major changes to the rest of Praetorian’s codebase, which meant our project teams could carry on working with zero disruption.

Interestingly, the addition of an experienced Xbox 360 programmer to the team made the transition to GCM a lot easier, as there are some pleasing and surprising similarities between the GCM and DirectX APIs.

Overall, refining Praetorian on the PS3 via GCM had given us performance boosts for both RSX and Cell work – as high as a 20 per cent improvement in some cases. We also ended up moving from FMod to Sony’s native Scream for audio, to really move Praetorian as ‘close to the metal’ as we can.

One other offshoot we were able to look into, thanks again to having abstracted APIs from the start, was an implementation of deferred rendering. We were free to have engine coders experiment with this sort of thing without interfering with our ongoing projects.

Other refinements we made to Praetorian included support for LUA scripting, which is pretty much the standard now, as well as including a physics and dynamics package, which for us meant integrating the Havok suite. Thanks to our great relationship with Havok, we were able to really push this side of the engine.

Both sets of engineers co-operated on ways to improve Praetorian’s physics integration and equally, we were able to feed our own suggestions back to improve the Havok API.

The results of all this close interaction, and the improvements both parties came up with, can be seen in the high levels of environmental destruction we have running smoothly in The Shoot.

Release, Release, Release
The early integration of engine development with projects means that Praetorian has now shipped in three titles for PSN.

The benefit here is on the platform holder relations side; Praetorian had passed the SCEE TRCs, giving us a clear road for using it in much bigger future projects, such as The Shoot.

We’d say that releasing via smaller titles on digital platforms is the ideal way to trial a new engine, as the smaller the project, the easier it is to iron out those inevitable kinks once your technology comes under the eye of external approvals – not to mention that having a proven engine will give platform holders and customers more faith in your schedules.

The Benefits and the Drawbacks
Building your own engine brings a multitude of unbeatable benefits:

• Deep knowledge: You own the technology and have intimate knowledge of it in terms of its strengths and, just as importantly, its inevitable weaknesses.

• Hardware familiarity: Coding your own engine will, by default, give you a better insight into the hardware you’re working with.

• Support: Your tech support is in the building, not on the end of a phone in another time zone, or an unknown user on a forum.

•Flexibility: You can adapt your engine to suit your needs, project requirements and the ever-changing middleware landscape proactively, rather than waiting for your external solution to catch up.

• You won’t be caught out by price hikes or being behind on latest versions.

• If you start with a high-level, open-ended mindset, you can specialise with platform-specific APIs as projects demand them, plus you don’t have to commit to any single platform. We’re now looking at implementing Praetorian on Xbox 360 and bringing the original PC/Open GL iteration up to current Windows/DirectX standards.

But is also comes with a few drawbacks:
• Being proprietary, newcomers to the coding teams can’t hit the ground running with Praetorian as they might with the popular middleware engine solutions.

• The engine needs to be supported with full documentation too. It’s great to have an engine team in-house but if core members leave, you need to have some kind of contingency plan in place so work can be picked up.

• You need an ear to the ground when it comes to emerging trends in game development – new middleware solutions, for example – and need to have the ability to adapt your engine to these trends as they become adopted standards.

Wisdom and learnings
We’re lucky at Cohort to be very close to the University of Abertay, which gives us a great body of eager and talented graduates to bring in. If you can arrange an internship with a well-accredited college running either a game development course or that has a good computer sciences faculty, then take advantage of it to create special project teams.

We needed to design and produce tools to support Praetorian in terms of things like user interface design and so on. We had to assign a dedicated team to create these and, naturally, we underestimated the time required to output sufficient tools with sufficient documentation and tutorials.

One key learning here is to start your tools early – and that the success of your engine is dependent on the tools that the various teams use to interface with it.”