From Prototype to Hellraiser: What It Takes to Turn a Game Idea Into a Real Game

The finished game is the part players see.

The prototypes, evolving ideas, technical decisions, temporary assets and thousands of small decisions that shaped it are almost invisible.

So what happens between the first playable idea and the finished game?

For Mad Head Games, Clive Barker’s Hellraiser: Revival began as something much less defined than the game players will experience when it launches. And like most ambitious software projects, it didn't move in a perfectly straight line from idea to finished product.

It changed.

The early playable version was more focused on combat and action. As the team explored the experience further, the balance shifted toward narrative, tension and the particular kind of discomfort that defines Hellraiser.

“When we first had something playable, we were exploring different ways the game could work, and combat and the level of action were more prominent at that stage,” says Aleksandra Pelivanović, Associate Game Designer.

But one thing stayed surprisingly consistent: the atmosphere.

“Even very early on, I think we had a pretty clear shared vision of how we wanted to portray the Hellraiser universe in the game. The way we got there changed quite a lot, but that core intention stayed surprisingly consistent.”

At this point, Clive Barker’s Hellraiser: Revival is almost a finished thing: a game that will be in players’ hands on October 8, 2026. But for the people who made it, it was never just the finished product. It was a long series of questions, experiments, compromises and moments when something finally clicked.

The game is being developed by Mad Head Games (a Saber Interactive studio), with teams in Belgrade, Novi Sad and Sarajevo, alongside remote colleagues around the world. So rather than asking what the finished game looks like from the outside, we wanted to go back to the parts players don't have a chance to see: the prototypes, the creative and technology decisions, the production process and the many small steps that gradually shaped Hellraiser: Revival.

When the prototype starts looking real

There wasn't one single moment when Hellraiser: Revival suddenly became the finished game. There were milestones.

For Pelivanović, one of the most important was the vertical slice: a small, highly developed section designed to demonstrate how the different pieces of the game would work together.

“We were focusing on one portion of the game, and for the first time I could see all the different pieces coming together and starting to make sense as one experience.”

Another milestone came with the team's first Labyrinth experience.

These milestones are a standard part of game production. A vertical slice gives the team a focused, representative section of the game that can be used to validate the direction, align developers and stakeholders, and establish a reference for the rest of the production.

Importantly, that doesn't mean every part of the game is already produced or polished at this stage. A vertical slice can still contain placeholder dialogue, temporary audio, unfinished animation or VFX. The point is to prove that the intended experience works and, once the team knows it has “hit the nail on the head,” use that foundation to guide the production and refinement of the rest of the game.

For Pelivanović, the team's first Labyrinth experience was another important confirmation that they were heading in the right direction.

“I was very happy with how it turned out, and it gave me a lot of confidence that we were heading in the right direction.”

But while the creative vision was becoming clearer, another problem was getting more complicated. The technology underneath it was moving too.

Building on technology that won't stand still

New features appear. Engines evolve. Old features disappear. Tools improve, and sometimes introduce completely new problems.

Hellraiser: Revival is built on Unreal Engine, so the studio's technology team has to constantly balance two competing priorities: staying current and staying stable.

“This is quite a challenge in the game dev industry,” says Luka Bilić, Lead Technology Programmer. “We have to balance being ‘up to date’ with being stable.”

The team maintains its own fork of Unreal Engine, evaluating changes from Epic and pulling in the ones that make sense for the project.

The important part is that “new” doesn't automatically mean “better.”

“We have to weigh the pros and cons of every technology,” Bilić explains. “Will it save us production time? How much will it benefit the game visually/gameplay wise? How much time will it take us to implement it?”

The team learned that upgrades can create their own problems. During development, a newer version of Unreal removed a feature they had previously relied on. Suddenly, the challenge wasn't adding something new, it was finding an alternative for something that already worked.

“You want to benefit from newer technology, but you also have to consider how the change will affect several years of existing work,” says Danira Lačević Karović, Associate Lead Producer.

“Getting closer to the end of the project means we’re more likely to reject implementing something new,” Bilić says.

That's a familiar problem for any large software project: sometimes the biggest engineering decision isn't what to adopt, but what not to change.

When everything starts costing something

Eventually, every ambitious game runs into a simple reality. Everything costs performance. The team initially expected graphics to be one of its biggest optimization challenges, particularly global illumination and shadows on lower-end hardware. It turned out to be relatively manageable.

“We did of course have to sacrifice some visual quality, but we’ve gotten to the point where we’re satisfied with the tradeoff we made,” Bilić says.

The harder problem was gameplay.

More specifically, scenes containing large numbers of enemies.

“And that is something that happens quite often in our game,” he says.

The challenge was to make those scenes cheaper to run without making the player feel like anything had been taken away.

“We had to get creative with the way we would solve that, while still keeping the combat unchanged from the player’s perspective.”

That's what makes optimization in games particularly interesting. The goal isn't simply to make the code faster. It's to make the underlying technology cheaper without making the experience worse. And eventually, optimization stops being a programmer-only problem.

“There is usually no single moment when feature development completely stops and optimization begins,” Lačević Karović explains.

As the game becomes more complete, programmers, artists, designers, audio, QA and production all become involved in identifying expensive content, testing scenarios, prioritizing problems and deciding where compromises make sense.

At that stage, every new feature carries another cost.

“Every addition can affect performance, stability and the amount of testing still required.”

The invisible tools behind a large game

Not every important piece of technology ends up inside the game. Some of the most useful tools are almost boring.

“Honestly, the tools that saved us the most time were often very simple,” Lačević Karović says.

Trackers. Forms. Automations. Views.

Small systems that help hundreds of people understand what is happening across a complex project.

“These improvements may each save only a few minutes at a time, but when hundreds of people use them over several years, that becomes a huge amount of time.”

More importantly, they solve a problem that has nothing to do with graphics or frame rates.

“They prevent things from quietly falling between departments.”

And that becomes increasingly important as the game grows.

How programmers, artists and designers build a game together

The stereotype of game development is straightforward: programmers write code, artists create assets, designers define the experience, and eventually everything comes together.

“That is definitely not how it works,” Lačević Karović says.

“A lot of day-to-day development is exactly that: people constantly sharing unfinished work, testing how it behaves when combined with everything else and then adjusting their own work based on what they learn.”

A cinematic might begin while dialogue is still being finalized. Animation may use temporary audio. Programmers may be implementing functionality while design is still changing the sequence. QA is already testing it and finding situations nobody anticipated.

Even a seemingly simple request can become a multidisciplinary problem.

“If we decide that a cutscene needs to be skippable, for example, that is not simply one programming task. We need to consider what happens to gameplay states, audio, checkpoints and anything the cutscene was supposed to trigger.”

That interconnectedness is one of the defining characteristics of large-scale game development. The game isn't a collection of finished parts handed from one department to another. It's a constantly moving system where unfinished pieces have to work together long before they're actually finished.

How do you make a new Hellraiser game feel authentic?

Then there is the creative constraint that technology alone can't solve.

But it also has to be something new.

The team wanted the familiar elements - the Cenobites, the Configuration, the Labyrinth and the unsettling atmosphere - but didn't want to simply recreate stories fans had already experienced.

“We wanted to tell a new story with new characters, but have them feel like they naturally belong in the Hellraiser universe,” Pelivanović says.

The balance was authenticity without imitation.

“Fans should recognize the Hellraiser they love, but also feel like they're experiencing something they haven't seen before.”

The team worked closely with the IP holders during the early stages, particularly around the high-level story and core gameplay loop. And then came one particularly meaningful piece of feedback.

For Pelivanović, that confirmation mattered.

“Having that confirmation from someone so closely connected to the franchise gave us a lot of confidence in the direction we were taking.”

Once that foundation was established, the focus shifted toward execution and refinement.

Even fear has a frame budget

Horror creates some unusual engineering constraints. It needs atmosphere and visual fidelity, but it also relies heavily on controlling what the player sees.

For Hellraiser, body horror makes that particularly demanding.

“Horror is definitely a hard genre for the technical side of game development,” Bilić says.

“Getting to the level of fidelity our artists can be satisfied with, means sacrificing a big chunk of our performance budget.”

But darkness provides an interesting counterbalance.

“Seeing as it is quite dark throughout the game, we can skimp on those dark areas when it comes to quality and use the machine’s power for something that’s in the player’s view.”

It's a perfect example of how technical decisions and creative decisions become inseparable in game development. The team isn't simply optimizing a rendering pipeline.

The machine has a limited performance budget. The player has limited attention. Good game technology makes those two realities work together.

When is a game actually finished?

Eventually, there comes a point when the question changes from What can we improve? to Should we still change it?

For Pelivanović, that moment wasn't defined by a checklist.

There were still ideas after that. There always are. But eventually, further changes risk becoming changes for their own sake.

“At some point you have to recognize that the experience is working and that further changes aren't necessarily going to make the game better, they might just make it different.”

And then comes the part no development team can fully control. The players.

“You spend so much time working on something, making decisions and trying to create the experience you have in your head, that seeing it finally reach players is both exciting and nerve-wracking.”

The team can test. It can optimize. It can polish. It can prepare. But once the game reaches the audience, the controlled environment disappears.

As Lačević Karović puts it, launch is the moment when the team starts seeing the game “through the experience of the actual audience.”

The prototype was never supposed to be the finished game. The technology was never going to stand still. The performance problems weren't always where the team expected them to be. And no department could build the game alone. What eventually emerges is the result of all those decisions: creative, technical and organizational. A game idea becomes a prototype.

The prototype becomes a vertical slice. The vertical slice becomes a production game. And, eventually, the production game becomes Hellraiser: Revival.

The interesting part is that building the game is only half the story.

Because behind Hellraiser: Revival is also a studio that has grown from a small regional developer into a team working on globally recognized game projects from Serbia, and that story raises a very different question:

That's the story we'll explore in Part 2.