Entropy is a dark, atmospheric exploration game where the player navigates a surreal environment and uncovers its secrets through traversal, pacing, and environmental storytelling.
The project won Swedish Game Awards 2025 — Game of the Year and Best Visuals (New Talent).
Built in Unreal Engine 5 on a PlayStation 5 production branch, Entropy was a 9-week PlaygroundSquad student project developed by a multi-discipline team under a tight deadline.
During development, I focused on exploration level design and level integration: building the foundation of the playable spaces, refining moment-to-moment flow, and supporting mechanic iteration to keep the experience coherent and shippable.
Alongside level design, I also stepped into a leadership / production support role when needed, helping stabilize decisions, align the team, and keep production moving.
Major Contributions
Level Design:
Designed and iterated several exploration floors, from early blockouts to playtest fixes. My focus was route clarity, pacing, landmarks, sightlines, and helping players feel lost in the world, not lost in the level.Leadership & Production Support:
Stepped into more of a leadership role during production, helping the team make clearer decisions, stay aligned, and keep the project moving toward a finished build.Mechanics and Systems Design:
Helped shape how core mechanics worked in real gameplay spaces, especially the orb, sockets, switches, platforms, magnets, and portals. My focus was making the rules readable, fair, and useful for puzzles and traversal.
World Flow and Integration:
Helped connect the hub, floors, spawns, return gates, and level transitions so the game felt more like one connected experience instead of separate rooms.Collaboration with Art and Programming:
Worked closely with environment artists and programmers to keep gameplay, mood, readability, and technical limits moving in the same direction.
Challenges & takeaways
Entropy’s biggest challenge was making a dark game feel fair. The player needed to feel tense, curious, and unsure, but not lost because the level was unclear.A lot of my work became about protecting that balance. When playtests showed confusion, I tried to solve it through level design first: clearer routes, better sightlines, stronger landmarks, cleaner switch feedback, and simpler pacing where needed.I also learned how important it is to stabilize decisions during production. When the team was unsure about a feature or direction, the fastest way forward was usually a playable proof-of-concept, quick testing, and then committing to clear rules.The biggest takeaway was that in a dark exploration game, readability is not just lighting. It is level design, system design, feedback, and team alignment working together.
Level Design
Entropy started as a playable prototype, but it still needed a clear structure for a full game. My role was to help turn that prototype into a readable exploration experience with connected floors, stronger pacing, and clearer progression.The main design problem was visibility. The game needed to stay dark and atmospheric, but players still had to understand where to go, what changed, and why a puzzle worked.My work focused on blockouts, playtests, and iteration. I adjusted routes, sightlines, landmarks, puzzle beats, and level connections so players could feel lost in the world, not lost in the level.
Existing Prototype
I started by playing the existing prototype to understand what already worked. The mood and core mechanics were strong, but the opening did not yet teach players how to read the game.The biggest issue was not the mechanics themselves. It was that players needed a clearer first experience with darkness, light, and navigation before the game could ask more from them.
Intentional First Exploration Slice
I rebuilt the opening into a more controlled first exploration slice. The goal was to teach players that light is not just atmosphere. It is information.The route gives players small, safe moments to shoot into darkness, reveal a path, spot a landmark, and move forward. This helped introduce the core loop without relying on heavy tutorial text.
An elevator hub anchors orientation between floors, while the Return Gate (portal) keeps backtracking readable in a dark environment.
Hub Structure
To keep navigation readable in a very dark game, we structured Entropy around a simple loop: each floor is a self-contained exploration/puzzle space, and a central hub elevator acts as the consistent anchor point.After completing a floor, players return through a Return Gate (portal), regroup in the hub, and then descend to the next stop, keeping progression clear even when visibility is limited.
Below, I break down my level design work floor-by-floor. For each floor, I’ll highlight the key goal, the main readability risk (in a dark game), and the iteration that made the route clearer through playtests.
⦿ Floor 1
Learning to Read the Dark
Introducing light as the player’s main navigation tool
Floor 1 (Part 1) — onboarding route. Gun pickup → first traversal beats → first direction anchor.
Floor 1 had to teach the player how to explore with limited visibility. The main risk was that players could miss the route, rush past important reveals, or blame the darkness instead of understanding how to use light.
I kept the opening controlled and readable, with short navigation beats that reward the player for shooting into the dark. Each light shot reveals something useful: a path, a landmark, an interactable, or the next direction.
The level also shifts from tight, claustrophobic navigation into a wider temple reveal. That contrast gives the player a breathing moment and makes the world feel larger before they enter the structure.
Floor 1 (Part 2) — transition toward the temple.
Blockout → Final Readability
I kept backups of my blockouts so I could show the level before and after production, not just the clean final result. This one started as a simple layout pass where I tested the first route through darkness, focusing on path shape, sightlines, and how the player would start reading the space with the orb.
After iteration and a lot of communication with the environment artists, the same layout started to feel much closer to the mood we wanted. This is usually how I like to work.Staying close to the artists, talking through ideas, and making sure the level still supports gameplay while the environment gets dressed.
Reward For Curiosity
At the midpoint of Floor 1, I wanted the player to feel the scale of the world for the first time. The problem was that the reveal sat in darkness, so some players could rush past it without understanding what they were seeing.
Instead of making the whole space brighter, I treated the light orb as a curiosity tool. If the player shoots into the void and waits, the space slowly answers back. The temple silhouette appears as a payoff, making the player feel small without breaking the mood.We iterated on the orb behavior with programmers and artists so distant shapes stayed readable for longer. This kept the darkness intact, but made the reveal more consistent and harder to miss.
⦿ Floor 2Timing in the Dark
Floor 2 was the first full temple floor, so it needed to feel more puzzle-focused without overwhelming the player too early.
I designed it as a contained loop around a central void. This gave players a simple mental map of the space, even when visibility was limited. The pacing follows a clear rhythm: explore, interact, platform, then reset before the next beat.
This floor teaches sequencing and timing while keeping navigation simple, one readable loop, with each beat pointing to the next.
The final platforming section was originally more complex, but playtests showed it was too punishing this early. I simplified the sequence by reducing the amount of chained precision and making the setup easier to read.After the change, players reached the end more consistently and entered the next floor with more confidence.
L2 Blockout Screenshot
Blockout → Final Readability
For Floor 2, I wanted the temple route to feel readable, but not like a simple closed puzzle room. We liked the idea that the corridor could feel like it keeps going deeper into the temple.A small fun detail is that we extended parts of it with modular pieces more than we technically needed, just in case a curious player looked further. It helped the space feel bigger and more real, even though the main route stayed focused.
⦿ Floor 4Climbing Through Scale
Floor 4 was the first large-scale temple space, so the challenge was making it feel massive without becoming hard to read.I broke the level into smaller design beats.So first establishing the climb, then adding a switch-based platform run, and finally escalating into a magnet climb where progress costs resources.
Floor 4A
Establishing the Climb
The opening of Floor 4 needed to communicate scale without confusing the player. I wanted the player to immediately understand that this was a larger, more vertical space, but still have a clear first goal.I used the opening view to frame the climb early. The player can see future spaces before reaching them, which helps them build a mental map as they move upward.The section is built around short traversal beats: push forward, gain height, reframe the space, then continue. This kept the level feeling large without turning it into a messy open space.
Floor 4BThe Switch Run
This section was built around a small twist on existing mechanics. Instead of only reacting to moving platforms, the player uses switches to control freezing platforms and plan their route.
The design goal was to make the player feel like they were setting up the path themselves. They shoot the switch, read the platform state, commit to the run, and move across the hazard.The floor hazard adds pressure, but the route stays direct. I wanted the tension to come from execution and timing, not from players being unsure about where to go.
Floor 4C
The Magnet Climb
This section combines switches and magnets into a vertical climb where progress costs resources. The player has to sacrifice orbs to unlock the next step, which makes each action feel more committed.
The main design challenge was clarity. Magnet traversal can easily feel random if the player does not understand when it activates, where it pulls them, or what they are meant to do next.I focused on making the climb readable through clear activation moments, strong audio and visual feedback, and a route that keeps pushing the player upward. After iteration, the section became much easier for players to trust, while still feeling risky and escalating.
Blockout → Final Readability
This blockout was super rough at first, but it already had the scale and vertical flow I wanted. When the environment artists first saw it, I think it looked a bit scary because of how much work it could become.But we talked through it, found a plan, and even expanded parts of it more than originally expected. Now it became one of our favorite moments in the game, especially when players finally reach it and the scale pays off.
Mechanics / Systems Design
This section covers how we turned the prototype mechanics into systems that could support puzzles, traversal, and level progression.My work here was not only about placing mechanics in levels. I also helped think through how they should behave, how players would understand them, and what rules we needed so the team could build consistent spaces around them.Because Entropy is played mostly in darkness, every mechanic needed clear cause and effect. When the player shoots the orb into a socket, hits a switch, or gets pulled by a magnet, the result needs to feel readable and fair.The main goal was to keep the systems simple enough to understand, but flexible enough to create interesting level design.
The orb
The orb became the main interaction language of the game. It was not just a light source, but the thing the player used to power, trigger, and understand the world.A big part of the design was making sure the orb felt consistent. If the player sends it into a socket, something reacts. If they recall it, temporary systems reset. This gave us a simple rule that could support many different puzzle setups.For me, the orb was also important for level design because it connected navigation, puzzle solving, and readability into one tool.
Moving & Freezing Platforms
Platforms were one of the main ways we turned the orb system into traversal gameplay. The challenge was making them feel predictable, especially when the player had to use them in dark spaces.I focused on how these platforms were used in real level situations. The player needed to understand what changed, when it changed, and how long they had to react.Keeping the platform rules consistent helped us build harder rooms without making the mechanics feel random.
Moving Platform (Blue)A powered platform used for traversal.
Freezing Platform (Orange)moves continuously; shooting/freezing changes its state to create safe timing windows.
Magnets
The challenge was making them feel powerful without feeling random. If the player did not understand when a magnet activated or where it would pull them, the mechanic quickly became confusing.My focus was on making the magnet rules easier to read in real levels. The activation needed to be clear, the pull needed to feel predictable, and the feedback had to tell the player when the magnet was working.This helped turn magnets into a real traversal and puzzle tool, not just a cool prototype feature.
Magnet traversal started as a raw prototype feature. Well it proved the idea, but it was hard to read and easy to lose control.Players often couldn’t tell when a magnet would grab them, or where the pull would place them, so failures felt random instead of earned.
Early on, magnets were still a rough prototype idea, powerful but hard to read and easy to misunderstand. In our first design discussions, we kept coming back to the same question...How do we make this feel intentional instead of random?I brought up the need for magnets to communicate their rules clearly (when they activate, what they pull, and what the player can expect), especially in a game built around darkness.That became the starting point for refining them into something we could actually build levels around.
To shape the feel, I referenced two systems that make pull-based traversal readable:
Tears of the Kingdom’s orb-like movement language and Super Mario Galaxy’s Pull Star.Not to copy them but to match the clarity! You aim, you commit, and the result is easy to predict on the first try.
Weak Magnet
The weak magnet was the more controlled version of the mechanic. It worked best when the player was close enough to understand the pull and connect it to the object.This made it useful for smaller puzzle spaces, where the player could discover the mechanic without being thrown across the level too suddenly.
Strong Magnet
The strong magnet was used for bigger gaps and larger spaces. It needed to feel more committed once the player activated it.The main thing was making the pull direction and result easy to trust. If the player understood where the magnet would take them, we could use it for more dramatic traversal without making it feel unfair.
Two Weak Magnets Combo
Using two weak magnets together gave us more interesting routing possibilities. Instead of only being pulled to one point, the player could chain movement and think more about positioning.This helped make the magnet system feel more flexible. It could support small puzzle moments, but also bigger traversal setups where the player had to plan the route.
Switches & Sockets
Switches and sockets became the basic grammar of our puzzles. A socket usually meant the orb powers something. A switch meant the player changes the state of the room.The important design work was making those rules feel clear and consistent. In a dark game, the player cannot always see the whole room at once, so the connection between action and result had to be easy to understand.I helped use these systems in level situations where the player could test, read the result, and build confidence with the rules.
Sockets
Sockets were used to show where the orb could power the world. They gave the player a clear target and helped connect the orb to doors, platforms, magnets, and other level systems.
The main design goal was clarity. When the player sees a socket, they should understand that the orb belongs there and that something in the level will react.This made sockets useful both as puzzle tools and as visual guidance.
Switch
Permanent switches were used when we wanted the player to commit to an action. These were not just quick interactions, but moments where the player gives up an orb to unlock progress.This helped create stronger decisions in the level. The player understands that they are spending a resource, and the level reacts in a more permanent way.It also reinforced the main rule of the game: the orb powers the world.
Permanent Switch
Permanent switches are about tension and commitment.
You’re not just activating something you’re sacrificing an orb to permanently open a path or unlock a gate.I used these as “decision points” inside levels: moments where the player understands
“I’m choosing progression over keeping tools.”And again: because this happens in darkness, I treated readability as part of the design, giving switches extra attention with visibility and feedback so the player doesn’t miss the purpose of the moment.
Portal
After each floor, the game needed a “return beat” back to the hub. I wanted that moment to feel like re-entering something unknown, not just a simple fade-to-black teleport. The portal became a small reward and a strong punctuation mark:
“floor complete → regroup → go deeper.”
Inspiration and target feeling
I looked for a reference that felt unsettling and physical, like stepping into a machine that shouldn’t exist.Event Horizon had exactly that:
a gate that feels alive, with a rotating/vortex effect that sells danger + curiosity. The goal wasn’t to copy the movie just to match the vibe.Commit to the gate, lose your bearings for a second, then snap back into the hub.
Proof of concept
Production was already moving fast, so instead of debating forever, I built a quick proof of concept on my own time.The first version was intentionally rough.
Just enough to prove the illusion works in-engine and that the gate can become a real gameplay endpoint, not a cutscene.
From prototype to final
I tied the portal to a simple rule:
It opens only after the player deposits three orbs, so the return feels earned and reinforces the game’s “orbs power systems” language.Once the concept was proven, I requested an early art task for the gate silhouette and kept iterating until it matched Entropy’s tone.It took some convincing to ship this instead of a basic teleport, but it ended up adding a strong identity moment at the end of every floor.
Lighting & Readability
Entropy lives and dies by what the player can barely see. The orb isn’t just a flashlight, it’s the game’s navigation language, pacing tool, and mood controller at the same time.My responsibility here was protecting the core promise:
Oppressive darkness that still feels fair. Players should feel tense and curious, not confused, not punished by the screen.
Clarity without breaking the darkness
Early in development, the lighting kept swinging between two extremes in clarity:Too dim → spaces felt flat, distance was unreadable, and mistakes felt random instead of earned.Too bright / too flashy → players could “solve” navigation by spamming shots and the atmosphere collapsed.
The hardest part wasn’t making it “look good.” It was building a consistent readability language that works in a game where visibility is intentionally limited.
Visibility Iteration
The core challenge
A big part of my work was keeping the original prototype vibe as the project became more complex. Mid-production we hit a messy phase where every change affected readability, and readability changed again depending on screen brightness, room lighting, and testing setups.To stop chasing our own tail, I started treating visibility like a design system: test the same situations repeatedly, lock the mood rules, then tune values until it was readable without becoming comfortable.
Shooting to navigate
This was my main stress test: can players move forward confidently by firing orbs without over-brightening the level?• My target wasn’t “more light.” It was usable information:• Enough to read the next route + hazards• Not enough to kill the mysteryI iterated values here until the orb felt like a controlled tool, not a screen-filling flashbang.
Orb-only readability
Fun (and very real) testing insight: depending on your room lighting and screen brightness, you might not even see the final shot in the clip, and that’s intended.The game was meant to be played in a darker environment. Later, once we saw how much setups vary, we pushed for a gamma slider so players could calibrate without destroying the intended mood.
I learned that lighting in a dark game isn’t decoration, it’s level design. The goal is not visibility, it’s trust... The player should believe the game is fair even when it refuses to show everything.
The bugs
Early on, my readability relied more on direct markers
(decals / “painted” guidance).It worked, but it felt too artificial for Entropy’s tone like the level was labelled instead of discovered.
The goal became: keep guidance, remove signage.I wanted players to feel guided without noticing the guiding.
A teammate originally pitched the bugs as atmosphere + threat, but we realized they could also become a diegetic navigation language.
My contribution was using them intentionally as soft landmarks:
The hard part was balancing mood vs clarity.
If bugs were too strong or too consistent, they became obvious arrows. If they were too subtle, they didn’t help at all.The Bugs should support decisions, not replace them, players still explore, but they stop getting lost for the wrong reasons.
Swedish Game Awards
Swedish Game Awards 2025 was the moment Entropy stopped being “just a school project” and became something real.In 9 weeks, our team shipped a complete game and it ended up winning Game of the Year (New Talent) and
Best Visuals (New Talent).For me, it’s proof that a team can turn a prototype into a finished, presentable experience through collaboration, feedback, and hard work.
The team behind Entropy
Nine weeks of chaos, testing, and finishing together.
The Lightkeepers
What mattered most for me was seeing people play the build live.Where they got stuck, what they noticed instantly, and what moments landed without explanation.It was a strong proof that the game’s dark readability + navigation language worked outside our dev setup.
DESIGN
Ami Ellqvist
Anton Lundgren
Karl Berglund
Nikolaos Georgios JoukowskiPROGRAMMING
Adrian Gårdestig
Cae Borén
Caspian Silvan
Felix Tabar
Tomas Wallin
ART
Alexandra Lindell
Han Ljungberg
Mattias Jansson
Paola Villegas Diaz
Petru Marinoiu
Simon Andersson DelinSOUND
Alexander Romero
Alicia Fasen
Oliver Lidström
Philip Olsén
