Unreal Engine 5
10 weeks
Group project (12)
Winter 2023/2024
Licenses/People played: 210K+/70K+ (2024-08-07)
WINNER of Gamer's Choice 2024 - presented by SGA.
Sonder is a narrative 2.5D co-operative puzzle platformer with combat elements, for two players. Working together, both when faced with tricky puzzles or battling waves of enemies, is the key to success. This game was our final game project at university. I was the Game Designer, and focused on creating an enjoyable experience for the player and tying the product together.
"This game is like if Portal 2 and Inside had a baby" - Steam review
INITIAL GOAL & CONCEPT
My first time as a dedicated Game Designer. I was excited to completely focus on a role that interested me so, and my goal was to do what was best for the game. It's difficult to describe the goal we as a group had when we started. With many strong wills in our group, we made sure to take time to find common ground before beginning development. Couch co-op, 2.5D, narrative, and a darker atmosphere were early suggestions for pillars.
IMBALANCES
Our group consisted of 6 programmers and 6 designers. The skewed group distribution required us to create something that allowed the programmers to have enough to do whilst not overloading the designers. This turned every decision into a game design challenge, where the player, the narrative, the group's composition and knowledge, and time had to be balanced at every step on the way.
WHAT DID I DO?
Many things. A lesson that I learned was that as game designer, I had the possibility to step in and help wherever it was needed.
First of all, I was responsible for the design of the game. When creating the outline of the game, this was a group effort where we brainstormed ideas together. I strived to create an open space where everyone could share their thoughts, while documenting everything of importance. When these sessions were finished, I summarized all notes and presented what it seemed like the group had decided on. If this was approved, we proceeded.
After this initial phase, decisions about the game's design were more on me. When a problem (or simply an inspiration) was discovered, I brought it up with those affected. Together, we discussed possible solutions and presented the idea to the rest of the group. I often collaborated with our level designer, Hannes Lemberg. It is difficult to point at one specific thing in the game and say "I did that thing", instead my role as a game designer was often having lots of meetings, lots of ideas, and doing lots of thinking.
DOCUMENTATION - BETTER FLOW WITH CHARTS
Writing great documentation saves you a lot of headache. During the first week, where the programmers mainly tackled how to do online gameplay and the designers made concept art, my focus was the GDD (Game Design Document). The first draft, roughly 40 pages, contained most information needed for everyone to be on the same page when implementing something.
The GDD can be read in full here:
Graphs were very helpful to concisely present information. One example is that we decided early on that we wanted every mechanic to have several interactions, most importantly with the other character, enemies and the environment. To see where this thinking was lacking, this combination graph was created to get an overview of the possible interactions.
Flowcharts were appreciated by the programmers to have a clear picture of how they could translate the design into code. These were mainly used when describing the behavior of the enemy AI, but also for the UI in the game.
The important takeaway from these are that one of my most important tasks in this project was to:
Create excitement, space and time for brainstorming
Help pick out the ideas that work well within the given context
Interpret what feeling we are trying to create into practical design
Prototype primitive versions of intended behavior
Communicate how that design can be implemented
We decided from the beginning that we wanted as much testing of our game as possible. In addition to the scheduled tests hosted by the university, we hosted our own tests every Friday. We also utilized the fact that our group was big enough that if 3-4 people worked on a mechanic, we could test it on other project members.
Testing was my responsibility, and included tasks such as deciding what needed to be tested, writing scripts, finding playtesters, hosting tests, analyzing feedback and communicating that to the group. To save time, I partitioned feedback per role. Minor issues could then be brought up only to those it concerned.
THE LITTLE THINGS
From testing we discovered that there was a lack of feedback from the game to the players. In a game with puzzles in focus I felt it especially important that other (mechanical) game elements should not require as involved thinking to understand.
Combat in Sonder is wave-based. After each wave of enemies, events can trigger. This allowed us to use the combat arena in "stages", where the same space could provide different challenges. However, players showed difficulty in understanding this, with reactions in the like of: "Oh, that thing happened again, I don't understand why" or "Can we skip these enemies?". Sometimes they defeated enemies on the far end of the map, and the event that triggered was out of view. Somehow we needed to convey that defeating enemies = progression.
"Oh, that thing happened again, I don't understand why" - Play tester
We had glass tubes as a decorative mesh. I used these to create a progression meter that could be placed in the world. Then I added a "soul" that spawned from enemies when they died, and traveled to the assigned progression meter. Now, when an enemy was defeated, players could see that "Oh, we need to fill that bar", and the soul traveling turned their attention to where the event would happen. This mechanic is introduced in Level 1 in a very small space, and then progressively gets slightly more complex. Below you can see in the final battle, where there are three tubes on the map, how it could be used. Player confusion was no longer a problem.
Some improvements seem like a given in retrospect. We had three types of buttons in the game, one that was a one-shot (once the player had pressed it, it stayed pressed indefinitely), one that was pressed whenever the player actively stood on it and one that was timer-based (stayed pressed down for a certain amount of time after the player had activated it). However, there was no way to tell these buttons apart, and they didn't physically react when the player interacted with them. I made sure that they were color-coded, and that they became pressed down to allow the player to see how they worked and know when they could be activated again.
To increase readability and alleviate our VFX artist, I made some VFX for the game. These were mostly in areas where there was a need to communicate an event to the player which we discovered during testing. Examples are when enemies are charging their attacks, when enemies are stunned and when players or enemies take damage. When Soul dashes through Robot, Robot becomes buffed (increased movement speed and damage) for a short duration. VFX helped players notice that something happened when this occurred.
To keep in line with the "Show, don't tell"-aspect of our game, we wanted to avoid having text-based tutorials explaining how to play the game. This also added the bonus of making the game more available globally, since translation would not be an issue. I whiteboxed a pop-up that appeared to the players when they entered an area where a mechanic was introduced, which proved quite effective during testing. I then worked together with our 3D artist and level designer to make it as much a part of the world as possible.
THE LEVEL SEQUENCER SEQUENCE
Initially, there were not supposed to be any cutscenes, everything was supposed to be told during the game in the world through level art and visual design. After feedback from the narrative week's testing, we realized that the story was not perceived. The narrative team was lost, and we realized that implementing our initial idea would not be possible. Cutscenes came in as a way to better connect all the levels in the game and make the overall story more cohesive. As I was prototyping a lot of the features, I found some time to prototype a cutscene that we could test on audiences, to see if that was a possible route to pursue.
The cutscene was well received, and we decided to make more. Since I had already familiarized myself with Unreal Engine's Level Sequencer, I kept on and did the rest of the cutscenes. For the planned cutscenes, I received mo-cap animations from our animator Sarah Abbas. This was the first time any of us worked with mo-cap so I had to patch up some issues that appeared along the way, mainly related to the translation of space. The rest, more "unplanned", cutscenes, I made use of the animations already present in the game, to not put more work on our animator.
SPOILER ALERT: All cutscenes can be seen in this full playthrough, at the time stamps 0:00, 1:37, 2:02, 8:45, 12:12, 12:30, 14:24 and 15:05.
ARENAS
In Sonder, there are combat-focused levels where the players are faced with swarms of enemies, called Arenas. During development, the level designer was under a lot of pressure to create engaging puzzle experiences to test each major deadline, and there wasn't room to also develop these combat levels. Since I have some minor experience with level design, I stepped in to help. When the core layout and mechanics were in place, our level artist could take over and bring it from its whitebox stage to its final appearance.
ARENA 1
Combat was more or less untested when we had our first major deadline: Alpha. I was in charge of designing and implementing a prototype for an Arena. My goal was to in some way connect the two quite different experiences (slow-paced puzzling vs. fast-paced combat), and wanted to bring some kind of collaborative puzzle experience into the Arena as well. This would obviously have to be very simple, since the players also have to deal with enemies simultaneously.
At this point, we wanted to try a resurrection system where if one player died, a "soul" would spawn that the other player could run to and touch to save their partner (as in Cuphead or Super Mario Bros. Wonder). I prototyped this mechanic to test during Alpha. It proved to be problematic in a few ways:
It became confusing that deaths in Arenas did not work in the same way as deaths in puzzle levels, and there was no space beforehand where we could teach this mechanic
Platforming wasn't "smooth" enough for it to be satisfying to try to reach the other player's "soul"
Most deaths were because of the lava, which made it impossible for the other player to save them anyway
It would require work from the visual team that didn't have a lot of time
Therefore, we scrapped the system and tried to think of another way. We instead decided to use what we already had, buttons and moving platforms. With these, we created "prisons", where a character spawned if they died. A button could be pressed by the player who was still alive that would open the prison and let the "dead" player return. If both players ended up in prison, that counted as a fail and the level restarted.
For the level itself, my idea was to have "lava" that moved up and down at intervals, with a safe space for each character. When the lava was moving up, one player had to be boosted up, enter their safe space, and activate a switch to allow the other player to reach theirs.
After testing, we realized that this was too much to handle at once. There was generally a lack of feedback to the players, since the game was in such an early stage, but we realized that even for players who understood it, the mechanics seemed more annoying than fun. We then simplified it a lot.
The safe spaces were reduced to one, in which there was a button that activated a platform that was safe for both players
The safe platform stayed out indefinitely instead of disappearing after a few seconds
The lava only moves up and down once, after the first wave of enemies are defeated
ARENA 2
Creating the second Arena was a more collaborative process between me and our level designer. We had always wanted to create a scripted boss fight, an epic finale where the players overcome the darkness within them, but realized that time was not on our side. Yet again we needed to use the tools already in the game. The solution we came up with was a bit inspired by Little Big Planet, where "bosses" often were in the background whilst the players dealt with obstacles they were already familiar with. He sketched an idea for the layout on paper and sent it over for me to prototype and implement.
There wasn't time to create special animations or VFX for the boss fight, so I instead created a system to spawn multiple particle systems in a given space. When the players survive a wave of enemies, a button is presented that when pressed spawns particle systems on one of the bosses. This gave the players the feeling of "damaging" the bosses.
SURVIVAL ARENA
Towards the end of the project, we realized that we had a really powerful foundation to build a more advanced combat experience. Our system designer, AI programmer and level designer (Jonathan Rubensson, Isabel Diaz Johansson and Hannes Lemberg) and I put in extra work to see if we could make this experience a reality.
We designed and implemented an endless mode, where the players try to survive as long as possible against endless waves of enemies. Unfortunately, there just wasn't enough time to make this a polished experience before release. We still decided to include it in the game, with the tag "Beta" to inform the players about its state.
Here again, our level designer presented me with a sketch that I prototyped and implemented in the game. We adjusted some platforms and added two new mechanics, a health pickup and an environmental hazard, and let the players play around with the combat mechanics in total chaos. The mode is unlocked after having completed the main story, and can be accessed through the chapter selection.
WHAT I WOULD HAVE DONE DIFFERENTLY
There are lessons about the game itself and lessons about the project itself. Some I simply lacked knowledge about, others were foreseeable and good reminders to trust oneself.
THE STORY OF THE STORY
We didn't have knowledge of how to create a "Show, don't tell"-narrative. With the given timespan and experience, none of us knew if it was possible to make a narrative game longer than 20-30 minutes. It's very difficult to convey a story in such a short time while still allowing the player to play a game. Many of us had the suspicion that it would be too great a challenge, and we strayed from making a completely narrative game, but it remained as a core pillar. I have a newfound respect for the amount of planning and pre-work that is required to make narrative games.
CUT THE CUTSCENES
In retrospect, taking on the responsibility for cutscenes was too much. Working overtime was already a reality, and this brought that to such a level that I had to deprioritize other tasks that were more in line with my role as game designer. Because of my role being a sort of central point, this also trickled downwards since I had less time to be structured and communicate well.
The problem could be exemplified as:
"Is there any documentation on how to implement this mechanic?"
"No sorry, I haven't had time to do that yet."
"How is it supposed to work?"
"I don't know one hundred percent, I haven't thought it through."
"Can we have a meeting about it?"
"Yes, if we can keep it under ten minutes."
When taking on the task, I did not know how much time it would consume. And when I had started, I couldn't leave the work half-finished. Because of this being kind of an ad-hoc solution to the narration problem, there wasn't a clear plan on exactly how many cutscenes were needed and how they should look. We did have a meeting where we tried to settle this, but ultimately it kind of became "Just one cutscene more" over and over again.
I do not know in what way this should have been handled. There wasn't really anyone else that had time or was interested in the task. I do think it made the game better, which is always what I strive for. Would it have been better if we accepted that we needed to drop the narrative, and instead focus on making the rest of the game as good as possible? We will never know.
TRUST THE TESTS
During testing, we noticed that players primarily enjoyed playing with the mechanics and the cooperative puzzles that existed. However, there was a bunch of content that remained untested for a long time during development. We had the attitude of "they'll like it, it's just not finished yet".
I didn't feel good about that attitude, as I was the one analyzing all the feedback and responsible for the testing. There were things that obviously worked well, and instead of focusing on further developing them, time was spent on expanding the game more and more. There was too much focus on breadth and too little on depth.
SUMMARY & SONDER
I am proud of Sonder. One of my goals with the course was to create something that I could show others and feel proud of. I can say that I have achieved that. It was the first time I had the explicit role of Game Designer, and with the challenges in the project, I feel like I did a good job. Above all, I have learned incredibly much, and look forward to continuing to design games in the future.
It's been a great pleasure to see how well received the game got on Steam. You can read more about Sonder and download it here (Steam):
Comments