THE CHINESE ROOM
Dan Pinchbeck, Creative Director and Studio Head
We made the decision to shift over to Unreal after we shipped Everybody’s Gone To The Rapture largely because of the community. As we knew we’d be self-funding a title, we wanted to be in a place where there were lots and lots of other developers all experimenting and breaking things and helping to fix them again.
We also wanted an engine that was adaptable enough to take on whatever we ended up doing – something with the power to give us a Rapture-level finish, but that could also work as a flexible template at a simpler level than that. Unreal can get to places Unity can’t if you are pushing up the presentational quality, but it’s still really adaptable and flexible.
Helana Santos, Technical Director
A crucial point for any game engine is to have a good support team. This involves having great communication with their customers, fast bug turnaround time and solid version releases. There is nothing worse than finding a crash bug caused by the engine when you are trying to do a release build of your game.
Documentation and learning tools are vital. Great accessibility means more time for developers to implement features instead of learning how to use the tools provided.
Luke Thompson, Co-founder
We focus heavily on prototyping and iteration of core mechanics, so our number one requirement is an engine that lets us implement ideas fast. Performance is far less important – if you can’t absolutely nail an awesome core loop, you’ll never have a game worth playing at any framerate.
Multi-platform is also important – many factors determine a game’s target platforms, but the engine shouldn’t be one.
Finally, a good editor with excellent extensibility, as custom tooling is absolutely essential in the real world.
Unity’s component model is perfect for prototyping – good use allows fast coding of new behaviours while also minimising ‘baked in’ decisions for later changes.
Katie Goode, Creative Director
I’m after an engine which allows me to create levels as quick as I can draw on paper, but then has tools to line up objects to grids or to surfaces, and move objects with millimetre accuracy.
We’ve been using Unity and there are key features that seem to be missing – which was slowing me down. Not only have we had to download a few tools off the asset store, but John has had to create quite a few tools for me. It would have been nice if these tools were part of Unity by default, but I don’t think I could manage with an engine that doesn’t allow us to fairly quickly create custom tools.
Steve Stewart, co-founder
Dreamloop chose to develop using Unity because it had a laundry list of great things going for it. If (for some horrible reason) we needed to choose another engine, we’d look for the same general factors:
1. It’s supported by both Xbox One and PlayStation 4. Most major engines are, but Unity makes it easy to build for both consoles and PC.
2. It’s well known by most developers in our scene, and finding a crew that can work magic with it was pretty easy.
3. The license agreement for indie developers is grand. It allows small teams to worry about developing first, and license fees later, after you’ve actually sold copies of your title.
Ben Waring, Technical Lead
Accessibility is key and this means user-friendly visual development tools or editor. Ease of use allows simplified, rapid development of games with fewer cross-departmental roadblocks. A low learning curve helps too, allowing newbies to get up to speed quickly.
Customisation is massive. There is no way the engine developer can supply us with everything we need, so we require the ability to personalise as we see fit.
Time is money – primarily a game engine needs to save us both. Fast engine/script compile times mean faster iteration. Cross-platform integration allows us to get our games on our platforms of choice as quickly and painlessly as possible.
Finally, we require easy integration into an automated build process to save developer time, alert the team of breakages and facilitate speedier testing.
Boomer Rogers, Director of Software
We like to see if the engine itself is future-proof – can we devote resources and develop skills without the engine becoming obsolete one year down the line? To ensure we don’t run into this trap, we check to see how active its community is, how widespread its adoption is and if it has third-party support.
Next, we typically see how ergonomic the engine is: how easily our team can pick it up and start producing something tangible. Particularly important is the maturity of out-of-the-box features the engine supplies, platform support and documentation coverage.
Finally, we look at the extendibility of the engine itself; can we create a tooling system that allows our non-programming staff the ability to create meaningful gameplay? Can our programmers get into the code to fix bugs or create new features? For us, open-source code via GitHub is huge.
Cost, control, command line.
Ashley Gwinnell, Force of Habit (@ashleygwinnell)
It has to be cross-platform, e.g. the editor has to run on Mac as well as PC.
Jonathan Dixon, independent (@itsafeature)
1. Rapid Prototyping.
2. Artist Tools.
3. Licence Cost.
Desk Dragons (@DeskDragons)
Handles all the rendering, good scene editor. Supports many file types for assets. C#/C++ support. Builds to consoles.
Alex Rose (@AlexRoseGames)
Cost, platform support, a vibrant community, regular updates, performance... jeez I’m fussy.
Rinse Wash Repeat (@RinseWashRepeat)
Low memory/CPU footprint. C/C++ lang. Cross-platform, extensible, open-source and active community.
David Amador, Upfall Studios (@DJ_Link)
Cross-platform, good editor, good multi-threaded performance, not having to write in C/C++.
Alexander Birke, Out of Bounds (@Alexander Birke)
Editor (scene & code). Everything else one can work around, but with inadequate tools, productivity suffers across the board.
Stephen Caruana, Pixie Software (@Caruanas)