When Ulas Karademir last worked at IO Interactive, it was a Square Enix-owned, Danish game developer that made Hitman.
He left in 2014, and has since held numerous senior roles at Unity, before joining Crytek co-founder Cevat Yerli to build an engine for distributed development (RealityOS).
Now he’s back at IO as the firm’s chief technology officer, and he’s walked into a very different company. It’s now independent, with studios in Malmo, Barcelona, Istanbul, Brighton and Copenhagen, and working on numerous projects, including Hitman, a fantasy game and a James Bond title.
Yet equally Karademir isn’t the same. He has learnt a lot over the ten years since he was last at the studio, and is now tasked with looking at the developer’s technology to help its teams be more efficient.
“What I am looking at is mostly around production-related things,” he says. “Mostly around dev ops, trying to change some of that infrastructure and modernise our software development capabilities. This is currently my interest. And I am also looking at the tools we can make to make the production cheaper, faster and better.”
‘Cheaper, faster, better’ is basically the tagline for our new GI Sprint editorial series. And for Karademir, a lot of this is about being able to iterate quickly, test it and try again.
“When you look at any kind of game development, we still have very classical pipelines that we’ve been using for the last 20 years,” he explains. “We have digital content creation tools that we export to engine, we edit in composite and then we build for a platform. And that pipeline takes time, because iteration speeds can vary a lot depending on what you’re working on. So I am looking at how can we bring the content quicker to the end, and how can we iterate faster in production so that we can get feedback.
“In games, you are just trying to build fun. And fun is kind of unmeasurable. It’s telling a joke and you don’t know if people will laugh. The best way to do it is to iterate faster, test it, make it happen and then this is fun. That iteration speed has to be really, really fast.”
“Fun is kind of unmeasurable. It’s telling a joke and you don’t know if people will laugh. The best way to do it is to iterate faster and test it”
A big part of this is creating tools that can speed up and automate part of the process.
“[Think of it like you] had a screwdriver, and now you have a drill machine,” he explains. “If you’re a carpenter, you buy a really good tool that’s reliable and durable for your craft. But if it’s a hobby, you won’t do that. From the tools perspective, once you start doing the same thing again and again, you start investing in the tools so you can get a better quality. It is not cheaper, necessarily, but it is faster because you create this expertise in the production pipelines.
“IO has been doing this for 25 years. There is a lot of learnings here. What makes the production effective is how much you learn from your past and your failures.”
He adds: “It’s the Boyd’s principle: speed of iteration beats quality of iteration.”
Karademir says that the idea of automating entire parts of game development is unrealistic, because without interacting with the people who use the tools, how can you possibly know what’s needed and what needs improving?
“There are two paths with automation,” he says. “First, you build tools to replace humans. The second path is you make tools to make the human go faster and the work easier.
“If you go down the first path and try to automate humans, you are building a system that you will need to test. But you don’t have human interaction, so that’s going to be hard to do because you’re not learning from the people who will use the tool. That doesn’t tend to end up so good. If you’re just trying to get rid of this and automate everything, when the world changes, the requirements change and new things come in… well, now you need to automate something else that you don’t know. And you end up in a cycle of automation for automation’s sake, and if things change, you need to rebuild the systems.
“The second path, where you build tools that people can use, you’re always interacting with your level designers, your environment artists, your animators, and they’re constantly telling you what they’re missing and what you can build for them. And as an engine team within a company, you need to have a product mindset. You need to treat your colleagues like paying customers. Once you have this kind of relationship, it’s very easy to build tools that matter and have an impact.”
This takes us to the advantage that IO Interactive has, which is its Glacier engine, an engine that Karademir helped develop during his first stint at IO. The firm can be very focused on building an engine and tools specific to its individual needs.
“There are so many advantages to using your own tech,” he explains. “You can make quick decisions. You can change the direction of the technology. The feedback cycle of user to developer is very tight.
“One of the biggest things with Unity and Unreal is that they’re constantly trying to grow. And to grow means they’re constantly adding new features because they want to add more user types. That ends in a polluted engine in terms of features. If you go to the bar at the top, you will see a lot of features and they have so many use cases. And now they’re also building for industrial digitisation, so they need to support that. So suddenly you have this large code, and maybe somebody is only using just 40% or 30% of it, but you need to make sure it’s stable and doesn’t crash.
“For us, it’s a games engine. We’re just making games. So we can narrow our focus on that and create great tools that have impact on the production. We can also measure that very quickly in terms of how much time it saves. And that data-orientated approach with technology, with the user interaction overlapping that, is how you make great tools”.
Of course, building your own technology and tools takes time and investment. IO Interactive has been doing this for decades, and it’s not something Karademir would recommend for studios that are earlier in their journey.
“I would not recommend it from the get-go,” he says. “There are lots of games that [follow] the trends and create mechanics like other games, and I don’t see any reason why they should make their own tech.
“When you should make your own tech is when you’re trying to do something unique. Where there’s some innovative new gameplay that hasn’t been done before.
“IO has done a lot of great things, like our crowd systems… there are no engines that can support these kind of things, and we already have it. Hitman is a very complex game. In traditional games you might have an NPC where if it has a bigger gun it runs after you, but with a smaller gun it runs away. Hitman is not a game like that. It has very complicated AI, with disguises, level set-up, and the gameplay loops can take up to 90 minutes sometimes. For games, it’s usually a case of press a button and something happens, but with Hitman you go in, infiltrate, change costumes, set it up, listen to people, learn the AI and how they behave… that’s quite complex. And when you do these novelty-high games, you need special things.”
For some studios, it might make sense to use an existing technology such as Unity and Unreal, and then build on top of it. But there are drawbacks to that approach.
“What often people do is take a Unity or Unreal engine and make plug-ins and build on-top of those. They make a lot of changes to the editor or engine. But that means they’re stuck on older versions of the engine in the production. We don’t have any older versions. We have one engine. We don’t have a 2.0 release, we just update our engine every day based on the needs we have.”
“I am trying to reduce the rework. New work is energising. It is fun. But when I have something and I have to do it again or fix a bug, that’s boring”
Going back to our conversation on the need for faster iteration, this is not just about lowering the cost of development, but also reacting to the rise in live service games. If you’re building a live game, you need to be user-centric and reactive, and this fundamentally changes how engineering teams need to think.
“We have to be more platform-engineering, dev ops minded,” he explains. “So we need to adapt to new tools, like new AI tools, to help us automate the work that is repetitive. I want to work in bringing AI in writing test, for example. It’s annoying to write tests for a game development company, because it’s always changing. It is 100% necessary for software-as-a-service company, and now we’re pivoting to live service, we need to learn how to work with an SaaS mindset on the engineering side, too.”
Indeed, Karademir concludes by saying that there is clearly opportunity with AI in terms of its ability to remove unnecessary repetitive work from development.
“Things like study analysis, code analysis, automation testing… there are a lot of things that can happen with AI,” he tells us. “And there are a lot of start-ups around that. That’s a very interesting area.
“Generally, I am trying to reduce the rework. New work is energising. Doing new things is fun. But when I have something and I have to do it again or fix a bug, that’s rework, that’s boring. It happens because we misunderstand something, or it wasn’t managed right, or a competency was not there. But once you’ve learned it, you know what to expect and that can be automated. AI can be used a lot, I think, in this area.”