Holistic Game Production. How We Made "Heartbreaker"

“Heartbreaker” started as a job interview task I built in one weekend. 18 months later, my teammates and I won an award with “Heartbreaker” during a global gamedev conference, surpassing over a 100 professional indie teams. How did we achieve it?

Abstract

This text reflects my experience as a team coordinator for the game “Heartbreaker.” It is also a postmortem of the game. I present loosely gathered thoughts on our multielement, holistic approach to developing “Heartbreaker”. I believe that the amazing interdisciplinary team I’ve had the pleasure of working with, along with this holistic approach to the project, have been key to creating a game we are so proud of.

Murky Roles

It is five of us in “Disco Angels” team and everyone was involved into giving the “macro” direction of the game, designing “micro” elements of gameplay, or production. But some roles are indeed visible, and the key to cooperation in our tiny team is… trust!

Our team receiving “Best Gameplay” award at Game Access Conference 2024, Indie Showcase

When an important artistic decision needs to be made, Agata, our art lead, has the final word. When there’s a critical bug that needs to be fixed immediately, I know I can always trust Mikołaj. When we had to implement an emergency option as fast as possible, Mateusz programmed it in a flash. Want to capture the atmosphere of a location with sound and music? Michał Świstak for the rescue! And me, with responsibilities ranging from programming to supervising formalities around events or setting up tasks. A conclusion?

Elements of Holistic Production in “Heartbreaker”

Applying a holistic approach during the development of “Heartbreaker” was one of the aspects I loved the most about my role as a leader. It involved acknowledging every part of our creative vision and bringing it to life within a realistic timeframe. Several factors contributed to the high-quality experience we aimed to deliver, which I refer to as “elements”. For instance, knowing we would showcase our game at a professional game development conference, we wanted to ensure that none of the elements misfit or were of lower quality than the rest. Additionally, we aimed for all elements to support one another!

I encourage you to get to know “Heartbreaker.” This will help you follow the text more easily. You can even download and try the game yourself.

Gameplay

“Heartbreaker” started as a job interview task but eventually evolved into something entirely different in terms of art and gameplay. I describe it further in section The Art of Defining Scope And Cutting Things Out.

As an FPP platformer, it’s built around the idea of crashing hearts of stone through dynamic movement. This works well on the Theme & Story element but is also a core gameplay mechanic. You use a dash skill to crash into opponents’ hearts in the environment. This concept evolves to later pair your movement with trampolines or new abilities, such as a grappling hook.

It was the easiest for us to begin the development with gameplay. While a creative vision related to a specific theme, story, or art style might come first in some projects, gameplay was the foundation in ours. We wanted to kick things off with something interactive (not lore or ten pages of backstory). Rapid prototyping and the “fail fast” approach to testing gameplay were key in this process.

Of course that did not mean, for instance, our artists weren’t working on art or music elements during that time. Pure gameplay mechanics were simply what we devoted the most time to at that stage.

Let’s focus on prototyping – at the beginning it was crucial to build a testable and playable version of the most important gameplay mechanics as quickly as possible. We built a few of them and tested with players (mostly students in our gamedev club) to see what worked and what didn’t. We did this frequently, especially when we were uncertain about whether our gameplay was fun. Early playtests were essential for this. If a particular mechanic, like “constant jumping” (more on that later) disoriented our players, we tweaked it and tested again. If it remained confusing, we cut it out. When something “clicked,” even in its rough form, players confirmed that during the tests. However, it was also important to filter all feedback. We listened to our players carefully and took notes of everything they mentioned, but the final decisions were ours. We knew that playtesters often pointed us in the right direction, but their conclusions about certain aspects of gameplay might sometimes differ from the real cause of the trouble, or sometimes we might just stick to our vision.

         

When building fundamental gameplay mechanics, we prepared a comfortable space that served our needs. It was an extra scene (a level) that was mostly empty but allowed for easy enemy spawning or testing other game systems. In “Heartbreaker”, we call these levels “Labs,” as they function like a lab for experimenting with gameplay. This approach allowed us to “fail fast” and iterate quickly.

An early prototype of grappling hook skill – tested on a “Lab” level.

Art Style & Graphics

Initially, we had two ideas for the art style of “Heartbreaker”, but neither was connected to the other elements of the game. However, once the core gameplay and lore emerged, everything began to make a good match.

Those ideas were: wild west high above the ground and geometric abstraction. We chose the second option, but what we selected isn’t as important as how we connected the art style to the other elements. A relaxing nature of the setting along with holiday and party atmosphere went well with the gameplay – crashing hearts of stone. Players having traversed the luxury (but abstract) resort thought of: the story that matched the location, and gameplay. Having seen the art making up this world reminded the relaxing, slightly unreal atmosphere of the game, parallel to those “meta” gameplay mechanics.

Our art style was not just randomly placed low-poly figures. We aimed to build a world that resembled the real one using these figures. Agata, responsible for leading the art direction of “Heartbreaker”, gathered a lot of references and drew inspiration from postmodern Mediterranean architecture. We blended abstract figures to shape the environment, and emissive elements that guided players where to go (neons or the wind).

A screenshot from “Heartbreaker”	La Muralla Roja hotel, a photo I took in Calpe, Spain

Theme & Story

I wish I had known how challenging it would be to create a heavily story-driven adventure when I started my gamedev journey. This is why we decided to begin the development with gameplay. It was also much easier to build a story around existing gameplay than to do the reverse.

This is how we approached “Heartbreaker:” we established a solid gameplay foundation, developed an emerging art style, and built on simple lore and microstory. Both we and the playtesters were happy with the results! This approach also left us plenty of room to expand the story and lore later on.

We knew that this is the exact approach Valve took during the development of “Portal.” Valve was extremely impressed by the prototype developed by DigiPen students, and wanted them to finish “the portal game” on Source Engine as fast as possible. Later on playtests showed that 15-30 minutes into the game players got bored by the lack of purpose, theme, and story. This feedback led to the development of the entire concept of Aperture Science Laboratories.

Our game is quite “meta” in its narrative. In “Heartbreaker” player takes on the role of an anonymous character guided by the voice of a young woman, while visiting Elcoro – a realm inhabited by extremely wealthy individuals who achieved everything they desired in their lifes. Player then quickly realizes that this whole resort, although looking happy, is full of decadence and coldheartedness. The female narrator tells our hero to crash those hearts of stone to make the land happy again.

We weren’t afraid to reach for the story to rescue our gameplay. This is why we decided to introduce the idea of crashing hearts. We wanted to inject more context and familiarity to the mechanics we created.

Long ago, the main gameplay idea was still the same: using dash for combat. Initially, enemies had their “weak spot,” the line showing where to dash in order to defeat them. During playtests it turned out that such gameplay is fun, but understanding the idea takes too long, thus, it’s unintuitive. Story for the rescue! We redesigned the enemies and decided that hearts of stone will be their weak spots. More about how our gameplay changed over the course of the development in section The Art of Defining Scope and Cutting Things Out. 😉

Dashing over the line to defeat enemies	Crashing hearts of enemies in “Heartbreaker”

I like a similar example that Jesse Schell presents in his book “The Art of Game Design: A Book of Lenses:”

My initial design for the gameplay in "Mordak's Revenge" board game required players to collect five keys to battle the evil wizard Mordak at his stronghold. However, I realized it would be better if Mordak could come to the player instead, making the experience more immediate. So, I changed the story: what if Mordak's castle was hidden, and players needed to collect five summoning stones instead of keys? Once all five were gathered, Mordak could be summoned to battle the player in any circumstances. This simple change made the desired gameplay possible.

— Jesse Schell in his book

Jesse Schell also points out (and I agree with him) that:

Story elements can often be changed with just a few words, where changing elements of gameplay might take weeks of balancing, and changing elements of technology might take months of reprogramming.

— Jesse Schell in his book

Level Design & Level Art

In a linear game where players just traverse content it is extremely crucial that they know where to go. This was the main focus during the process of designing levels in “Heartbreaker”. To achieve this, we iterated our levels and modified them according to how they fit the gameplay (like adjusting distances between platforms). Iterating required us to keep the levels at the stage of blockout as long as possible.

Early blockout with minimal decor	Final game with enemies and level art applied

On his ArtStation, Jeff Horal, Principal Environment Artist at Mountaintop, showcases many locations from “Destiny 2” as blockouts – representing the level design phase – and their final look after adding actual models, applying materials, and including decoration. The upper image depicts the level during design iterations, while the lower image shows the finished version:

A part of “Vostok” – a “Destiny 2” map. Author: Jeff Horal.

This image was firstly presented to me during a university lecture ❤ and I wanted to reference it here too!

So during production, it was extremely important to keep our levels in the level design stage (the upper picture) when iterating. This was because reworking a blockout is generally like playing with building blocks, and reworking a decorated level is like destroying your freshly arranged house, moving all the walls, and furnishing it again. We knew that if we don’t test out the levels early, we will waste plenty of time redoing level art job unnecessarily. So we aimed to enter the level art stage after deep iterations and feedback from playtesters.

Unfortunately, “the YOLO approach” kicked in a few times in several tight corners of production. Welcome to gamedev! 🎉 I discuss this further in the “The Mess of Game Production” section.

The normal process looked like this: a part of the level was designed as a blockout and tested through multiple iterations. After making some pivots and adjustments, the location was ready for decoration. This was usually handled by Agata, our art lead, though other developers often contributed as well.

We also wanted to make every location you visit in “Heartbreaker” distinct and memorable. There’s a patio with a garden party, swimming baths, a nightclub, jungle, housing district, atrium, casino, bowling alley, library, rooftop pool, mini-golf course, and a shopping mall… and that’s just the first 20 minutes of the game! (Yes, I’m so excited about our locations).

Music & SFX

Sound and music are also something that holded our game together. They were important for many reasons. Some more obvious, like being an integral part of the antourage around the game’s setting, just like visuals. Less obvious reasons include being a major UX component – sound can be (and should be!) used as something that gives players feedback just as user interface, particles, or other visuals.

In “Heartbreaker”, sound effects are everywhere – they accompany every action players take, every piece of it, to fully notify the players about what is happening right now. The main goal our sound designer and composer, Michał, had was delivering the feeling of being immersed into the world we have created.

Soundtrack is also built around the party and holiday theme with a nostalgic addition to it. Players traverse the levels listening to chill & beach house music. What is more, the music reflects the atmosphere of the story we discover and locations we visit. When we arrive at the garden party at the very beginning of the game, we can hear a lively dance track. When we reach darker but much more magical jungle, the music changes to more nostalgic. You can listen to the full soundtrack below:

Please also note that our game contains full voice acting. This was extremely important in terms of delivering our simple story. I’ve also had plenty of fun with the whole entourage around producing high-quality voiceover, as a team coordinator. We rented a recording studio and Michał, our sound designer, supervised the process of recording voicelines with Ola, our narrator. We could together analyze the voicelines on the fly and guide Ola what do say differently or with different emotions. I absolutely loved the process.

UI & UX

Another consequential element of the holistic approach is the general user experience (UX). This is the overall feeling a user has while interacting with the product (game). We of course strived to bring it to a higher level and that, again, happened by massive iterations, tests, and observing players while asking “What do the players do?”, “Why do they do it?”, or “How do they do it?”.

There were also thousands of ways to show what’s going on in our game, and to let players interact with the game – and that’s where UI comes in. User interface. We knew that interface is not only things you see on your screen in an overlay manner. It’s the totality of things that communicate information to the players and let them interact with your game.

And now I’d like to throw a shout-out to my teacher, Jarosław Andrzejczak, PhD, a UX researcher, who has vastly improved the general user experience and clarity of many systems and mechanics we have included in our game.

The main conclusion I have in reference to working on UI/UX of “Heartbreaker” is:

Let’s take this example: In the second level we introduce the grappling hook. During playtests it turned out that this skill is massively overpowered. Grappling could get us literally everywhere. We came to a conclusion that grappling needs nerfing, although in a way that doesn’t make the players feel weakened. So we decided that there will be only one use of the grappling hook but the players will earn it back with each heartbreak. So how did we show that rule to the player?

Well obviously we could come up with an on-screen icon depicting a grappling hook. For instance, if it’s full, we can use the grappling, if it’s empty – we can’t. That’s the most brute-force thing one can potentially come up with. It can be done in a more natural and understandable way for the player – take a look at this idea of our teacher:

Grappling is a heart fragment – you take it by breaking a heart.

Why clutter the interface with additional icons just because that was the first idea that came to our minds? We had hand animations, so we decided to use them! It’s as simple as that: grappling is a piece of a heart. If you have this piece in your hand, obvoiusly you can use it and you see your character throw it. It’s logical. A “side-effect” of it is that it limits the use of grappling, so this is the exact nerf of this gameplay aspect we aimed to achieve.

Tutoring

Players needed to learn how to play “Heartbreaker”. So how did we teach them rules and mechanics? A tutorial? Or maybe by throwing the players into deep water and letting them figure out gameplay on their own? We decided to apply a seamless approach. This means that, instead of a “traditional” tutorial we embedded the process of teaching players how to play into main levels of the game. The main goal of this was to not let the players realize that they are being taught how to play.

And much more. Now I want to convey that bad tutoring in this game could put off players massively. And I found this topic so important that I even wrote a separate article about that. Designing tutoring was a complex topic in every game I coworked on. I encourage you to visit this separate text about it. But to not leave you with nothing at this point, I would like to highlight a “megaconclusion” here: Paying attention to teaching players how to play paid off. We didn’t leave it at the last moment of production, we didn’t go for a short brief of controls or gameplay, deciding it’s enough. We decided that embedding tutoring in gameplay is the most elegant solution here. We also made other elements, especially UI & UX support the tutoring.

“Guiding Light”, another game I worked on, attempts to apply seamless tutoring too. You can read more about it in this article.

The Mess of Game Production

No matter how well production is managed, unpredictable issues may arise. This could be an unexpected engine bug that prevents crucial systems from functioning, problems with outsourcing, or even hardware malfunctions. This is why we decided to allocate a reasonable amount of time as a safety buffer. And when you’re concerned that certain tasks may take longer than anticipated, remember what happened to us:

An example from the production of “Heartbreaker” is fog. During the development of the second level, we began using a different type of fog to cover the depths of the level. It turned out that this fog caused a memory leak in the engine’s rendering module, resulting in slower performance and eventually crashing the engine. We discovered that this bug was fixed in the next Unreal Engine hotfix. However, several factors prevented us from migrating to the new version. While this problem slowed us down to some extent, we came up with a temporary solution. We concluded that the memory leak did not occur in the built game, so we created a simple script that deactivated all the fog in the editor and reactivated it just before building the game. Emergencies like this happen.

To address “the YOLO approach” I mentioned earlier, there were significant untested sections of the blockout. Unfortunately, due to time constraints in a few tight corners of production, we had to finish the levels with very little player feedback regarding some parts. So we polished those parts, decorated them, and didn’t look back. In several cases we were lucky and the reception of those level sections was satisfactory. However, some parts turned out to be too frustrating or difficult. The same with a few UI & UX aspects – they could have been better, but we couldn’t manage some obstacles that arised every time. And even Scrum, Trello, TO-DO lists, or feedback-based rapid prototyping fell short in a few cases because certain obstacles were simply not predicted.

The Art of Defining Scope And Cutting Things Out

I mentioned that “Heartbreaker” went through a lot before its gameplay crystalized. It started with a simple recruitment task I finished in one weekend (built with Blueprints and Unreal’s LearningKit assets). It was a completely different game which trick was jumping and moving forward constantly. This trick was blended with basic puzzles and arcade character of the game, shooting, in addition. It looked like this:

Of course it resembles more of a gamejam prototype than an actual game, but me and my team started to build upon this prototype, test other camera perspectives and the idea in general. But then, a real gamejam happened!

In 48 hours we created a game called “The Power of Four Leaves”, in which you played as a black cat staging a heist on a four-leaf clover storage. Players could fight lepricorns and, as the players embodied a black cat, the combat was designed as dashing in front of the lepricorns, so they are unlucky and disappear. And this is when we introduced the idea of using your movement as combat. You had to use a dash skill to make the lepricorn disappear. Pretty similar to dashing into hearts of the enemies, isn’t it? Well, it’s almost the same!

Gamejam projects often have twisted gameplay, but GIFs you’ve already seen explain it quite well:

Dashing in front of lepricorns to defeat them	Crashing hearts of stone in “Heartbreaker”

We decided to blend the “constant jumping” idea (the one from the recruitment task) with using dash for combat and the results were… disappointing. One day I showed a prototype to some experienced devs during a local gamedev beer meeting and their feedback made us realize that this gameplay needs cuts.

The problem was that our gameplay consisted of too many dynamic, difficult to master mechanics that were just random things put together. Then we were standing in front of a difficult choice – what to remove?

We removed the whole “constant jumping” stuff and decided to master the dash combat. And the rest of it is “Heartbreaker” you can play today. We focused on this one thing, the unique selling point and aimed to master it. Every next gameplay aspect that was in the game to serve this idea and make it deeper. And we are proud of how it developed.

The main conclusion here is: we shouldn’t have been afraid to “kill our child”. That means no hesitation to cut out a thing we spent time working on, if it doesn’t work, or doesn’t serve any real purpose in our game. We learned it the hard way, but the outcome of making such difficult decisions might be indeed lifesaving. In “Heartbreaker” often “less” meant “better” because of clarity, consistency, simplicity, and elegance of gameplay.

Summary

Woah! That was a lot of insight into “Heartbreaker”. I hope that I managed to show what challenges we, as a team, needed to tackle during the development and how we tied the game together using the holistic approach. This article is also my personal point of view with this “aspiring producer/director” mindset. Elements uncover obstacles a producer needs to be aware of, and needs to remove, so the development team can finish the game. And I love working with obstacles and restrictions.

Sources & Additional Materials

• “How to become a Game Producer #1” – partly a promotion for the Futuregames game producer course, but this webinar offers valuable info about being a producer. Part #1.
• “How to become a Game Producer #2” – and part #2 here.
• “The Strange and Unseen History of Portal” – a video about the development of “Portal”. It mentions how the gameplay was built and polished first and the story got built upon it.
• “Narbacular Drop” gameplay – a game made by DigiPen Institute of Technology students that became a foundation of the original “Portal.”
• “The Art of Game Design: A Book of Lenses, Third Edition” – the bible of game design by Jesse Schell.
• Jeff Horal ArtStation
• “Designing a Seamless Tutorial. Case Study of “Guiding Light” – my another article about seamless tutorials.