Spark & Kling started off as a school project that would last 4 weeks. During development, we got incredible feedback from peers and mentors. The team also saw the potential in the game so we decided to continue working on it as a side project.
Released on Steam 2024
Length
Genre
3rd Person
Couch Co-op Puzzle Platformer
Team
10 People
Contributions
Concept
Spark & Kling is a stylized couch co-op puzzle platformer for all ages, you and your friend play as:
-
Spark, the electric bug, who can possess different electronics, she also carries baby sparklings to shoot at generators and magnets!
-
Kling, the metal gel blob, who shoots the metal gel to put weight on objects in order to make them heavy!
Cooperation is key, you will need to work together and use their abilities to progress
through the level:
-
Kling can shoot metal gels in a line which Spark can jump into and travel through the level!
-
Spark can shoot sparklings at Kling for him to do his double jump!
Game Pillars
Symbiosis
The characters are designed with symbiosis in mind regarding the different mechanics and how they interact with each other
Co-op Puzzles
Co-operation is needed to complete the puzzles
Goofy
A goofy and fun feeling is instrumental to our game
Core Loop
Analyse
Check the interactable elements in the level
Act
Use the two character's abilities to solve the puzzles
Test
Understand what the different elements in the level do
Level Design Process
Moodboard
I researched similar games with small characters in a big world. As the game takes place in a home grown laboratory I also found a lot of inspiration from various art.
Level Map & Overview of Blockout
I designed the level where verticality is important. The players were to solve puzzles in 3D-space so I wanted to utilize as much space as possible.
Initial Design, Issues, Redesign
Initial Design;
The players were divided in two separate cages when they began playing. They would learn their abilities and how it helped the other player before meeting up with each other.
The redesign:
The solution was to redesign the cages to have both players start in the same cage. This time they were more connected as they could see each other through a glass wall. The players also have more room and have their own interactive objects for themselves to learn their own abilities. The players would then meet up and then use their abilities to help each other.
The issue:
The players felt disconnected from each other. Even though the characters had an outline that was shown through walls, the players did not feel they were close together. It did not feel intuitive to use their own ability to help the other player.
The cages were also cramped and the players felt claustrophobic.
Playtesting is crucial to the game and the level. The order of which mechanic was taught was changed a few times for the flow of the game to feel better. This meant that the level had to change as each mechanic would affect the player's progression in different ways.
Teaching Mechanics
In the first picture, Spark was taught Spark Dash. Spark would be able to jump a longer distance from a metal gel to be able to get to the other side. However, it was decided to scrap Spark Dash as it did not fit the gameplay nor the level. Thus, I had to change how to progress in this section. Spark would be able to travel through metal gel that Kling had placed. As such, the level was changed to accommodate the gameplay.
We also added hints to the level so players would have an easier time understanding how to use their newly taught mechanics.
Level Blockout, Initial Design & End Result Comparison
The players started in the separate cages during the initial design. Players would start in the same cage after the redesign. It was also scaled up to give players more space and not feel claustrophobic.
The different puzzles were moved around to give a better pacing to the players. The Robot Dog was also changed from being activated by Spark shooting generators to Spark possessing it. I moved where the Robot Dog was introduced to give the players a better pacing on when they would learn the mechanic.
The upper shelves were also replaced by a vent that the players would traverse in. During playtests it was noticed that players would greatly appreciate the change of scenery.
This area was the most difficult part of the level for the players to understand. Players were expected to look straight up and down to find the different elements of the puzzle. However, due to the area being near a wall and not having a clear goal of the section, players got easily confused. Thus, this section was completely redesigned. Many of the objects were removed to give a clearer space and interactives were changed to the possessable Robot Arms.
For the final section, I also added another vent in order to change the scenery. The players would do puzzles and traverse in them. Again, it was greatly appreciated by playtesters. The puzzles were redesigned in this section as mechanics were changed. I.e. Spark would only have two sparklings in most of this section instead of three. Kling was also taught triple jump and needed to use it.
Possession-Camera Position
Whenever Spark possesses an object, the camera switches to another static camera relative to the object possessed. I used this to my advantage for the level and positioned the camera in a way that shows or hints the next step or key objects to the players.
When Spark possesses the robot dog, the camera pans further out for the Spark player. They are shown the way forward whilst moving the robot dog. The Kling player is also able to stand on the robot dog whilst it was moving to get a better perspective.
Another important factor was how the camera pans in when the player exits the possessed object. The panning depends on the angle of the possessed camera. When Spark exits the robot arm, the camera pans in towards the other platform and reveals the second robot arm.
The Up & Down Problem
When I started to redesign the level, there was one huge problem I couldn't pinpoint that I knew was there. After several playtests, I came to the realization.
Players do not look up or down.
And the level was designed with verticality playing an important role. How did I solve this?
In the first iteration, the magnet was placed higher up causing both players to often miss it. To solve this, I moved the magnet down which would make the players see the magnet and have an easier time solving the puzzle.
I also used the possessed cameras to frame the level and key objects. When Spark moves forward with this robot dog, the scale and the next area gets framed in their camera.
The important lesson was to make sure that each key object or area gets framed in either of the players camera without ever expecting the players to look up or down.
Puzzle Design
Designing the puzzles was a fun and interesting challenge especially as the characters had asymmetric abilities. They would have to work together in order to solve the puzzles. I would take the systems that were build by the programmers and prototype different ideas that could either work or not. Many of the puzzles that are used in the game went through many different iterations.
Kling could shoot metal gel that had weight on it. I could manipulate how the objects behave when Kling shot on them using animations. In this example, Kling would have to shoot the object twice to make it go all the way down. In later iterations, we would have the object go up if Kling would recall the metal gel.
Spark had three Sparklings that she could shoot out and recall. The Sparklings would activate generators to make objects move or open. Spark's recall worked in a specific way, the last sparkling shot would be the one that was first recalled. Thus, I designed puzzles in a way that Spark had to figure out in which order they need to activate and deactivate the objects.
I also designed objects that behaved the same way but had different objects attached to them. Making them familiar to the players but also changing what they need to do. In this example, I added a timed platforming. Spark could activate the robot arm to move it, but had to jump in the middle of the animation in order to make it to the other side.
Scrum Master
I was in charge of the daily stand ups and holding the team meetings. The team used Jira and I regurlarly checked the tasks and could get a good understanding of what tasks were being done. I would take note of tasks that took longer time and approach the person working on it to see the progress. If the task deemed too difficult or time consuming, I would bring it up to either the product owner or the team (art, design or programmer) to see what could be done. I held what we called a "set expecation day" every Thursday to see if we could meet our expectations or go beyond it, or if we needed to scrap certain tasks.
What I Learned
Being a co-op game, all the consideration you need for a single player game amplifies more than two-fold.
-
How to guide the players
-
How to teach the players mechanics
-
In which order the player should learn their mechanics
-
Framing the level and key objects
The design relied on the players communicating with each other and showing each other the way. That is why playtesting was key.
Players don't look up and down. There were some puzzles in the initial design that players were expected to look straight up and down. As players don't, they would not figure out the puzzle and would quickly become frustrated. This was an incredible insight to learn. When I redesigned the level, this was one of the most important aspects to keep in mind.
I also learned the value of rapid prototyping, and not perfectly in order to find what puzzles would make the players most engaged and have fun. With playtesting, I could quickly iterate on them before finalizing the puzzles.