Partners in Slime

An exploration-based puzzle game where you can interact with the world around you to cause chaos and solve puzzles.

Play it here!

Partners in Slime One Minute Footage - Made with Clipchamp.mp4

Project Summary

Partners in Slime was created for Abertay's DARE Academy. We, along with 5 other teams, were given 4 weeks of hot housing and industry mentorship to develop prototype demos of our pitched game concepts. Through DARE Academy, we were able to attend many events with industry experts who gave us guidance and advice that helped shape the direction of our game. In October, we showed off the demo at EGX where we got lots of great feedback from the public and our industry mentors - we ended up winning the DARE Academy runner-up prize, which was an amazing surprise too! 

My role in this project was as a designer where I spent a lot of time designing puzzles and interactions. Additionally, I helped out with some minor production and admin tasks including budget management, and I also helped with sourcing and writing marketing materials too. 

The Initial Pitch

In coming up with the idea for this game, I wanted to keep our audience in mind. We knew that our intention with this game was to apply to DARE Academy, and so we wanted to make sure to create a concept that would appeal to the DARE programme, and also potential players at EGX. We also established early on that we wanted to focus on creating an accessible experience too.

I pitched an idea where you are a slime in a human world, and you girlfriend (also a slime) just left for the airport. But then shortly after she leaves, you realise that she forgot her passport. The game would then be split into a series of levels, in which you have to get to the airport in time by navigating public transportation to give your girlfriend her passport, eventually catching up to her at the airport gate.

This is the basic level loop for the initial concept, with an example level given in the red text.

The team really liked this concept, so we decided to push forward with this idea for our application and pitch for DARE Academy. In doing so, the rest of the team started work on some prototyping and concept art, whilst I spent some time coming up with a plan for what our first level would be. Our plan was to create a proof-of-concept for the idea in time for DARE applications, so we started some early development which included some art tests, moodboards, mechanic prototypes, and level greyboxing.

Early Development

First, I started by defining our design pillars and inspirations/references to ensure the whole team was on the same page:

Design Pillars:

Inspirations/References:

Initial Level Greybox:

I created this basic greybox of our level using pre-made assets. This level was inspired by Scottish Harbour towns like Arbroath or Elie, and this level would be the first level of our game and where our demo would take place.

At this point in development, we had one main puzzle in the level. This puzzle started with the player leaving there house which is on the far-right of the level. They would then find the passport stuck in the seagulls nest atop the lamp post in the center. They would then go to the chip shop, get some fish & chips, and use this to lure the seagull (and passport) down from the lamp post. 

This was quite a basic level, but the plan was that we could use this simple quest as our prototype to test the player experience of the game.

Level Layout Iteration

After making the initial prototype, we were able to test it ourselves, and this is also when we applied to the DARE Academy competition. Through our application and subsequent pitch, we got some really valuable feedback early on from the judging panel, and combined with out own testing observations, we made some changes.

DARE Judges Feedback

First of all, the big piece of feedback we got from the DARE panel was that the narrative did not fit the gameplay. The story makes the player feel quite rushed - they're chasing someone down with something really important, and they need it before their flight leaves - there is an obvious time pressure here. Yet, the game itself is reliant on the player taking their time to explore. These two things are inherently contradictory. We changed the overall narrative (and also the game loop slightly), to put the player in less of a time crunch and to encourage exploration. The new story, is that your slime girlfriend is proposing and she has set up a scavenger hunt for you to follow - this will tell the story of your relationship together, taking you through important locations in your relationship, and ultimately ending at the final proposal location. As it is a scavenger hunt, the whole point is to be inquisitive, so the hope was that this would put players in the correct mindset for this game. The new game loop for this concept is below:

Prototype Testing

Additionally, we changed the level layout, and changed the existing puzzle. We removed the chip shop to lower the scope, as this is quite a unique environment that would need a lot of unique assets and textures. Additionally, we added a pier to add more movement on the z axis so that the world feels more 3D, and we made sure the houses were in a straight row to remove any "dead sight" areas (to help with accessibility).

The revised blockout is shown below on the left. This was made in UE5, and all main quest points are coloured in blue to ensure that they are highlighted to viewers. Additionally, I created a simple fly-through video which can be seen below on the right.

Level Iteration Screenshot

Level Iteration Fly-Through

Communicating Designs

One of the main issues we ran into during development was communicating designs with the programmers so that they knew exactly what to implement. As this was a small project with a small team and small time frame, we did not have the time for programmers to constantly refer to convoluted and long documentation, so I had to get creative with this. 

Attempt 1: Labelled Greybox Paired with Documentation

The image to the left shows a greybox that I made in UE5 for our tutorial level. This was quite a simple level, so I was able to just annotate over the screenshot and then provide a step-by-step walk through in a separate document.

This was sufficient for this specific case because the interactions are linear - there is one solution, objects are static, and all players will follow a similar path. 

After sending this over to the programming team to be implemented, I  quickly learned that this was not an effective method of communication for this team. I found things had been implemented incorrectly or missed completely, and this was because they were relying almost exclusively on the annotated image - the documentation was very text-heavy, which made it intimidating and no one wanted to read it. I needed to find another way to communicate to the team that was more suitable for everyone.

Attempt 2: Comprehensive Labelled Greybox

The image to the left shows an updated greybox of the main level (this time with some basic assets in) and with labels and step-by-step annotations included in the image.

The biggest struggle with this level is it has a lot of moving parts, and the NPCs have quite a few different states that are all dependent on external factors (the player location, player state, other NPC locations, other NPC states, etc). Communicating this through one static image was difficult, and required a lot of supporting text that ended up being even convoluted than before.

This method just did not work. It was a pain to write up, it was confusing to read, no one was happy with this. I found that the biggest issue here was that I was trying to rely on one image, so I tried a storyboard next.

Attempt 3: Storyboards

The image to the left shows my attempt at a storyboard for a different quest. I stuck with simple 2D diagrams here, using colour and key to distinguish important elements.

I found that this was very time consuming. I still had to write up the step-by-step documentation for my own reference when making these storyboards, and then that text wasn't even being used in the final presentation. I basically doing the work twice by doing it this way.

However, this was a lot more useful for the team. They understood this format much better, and less errors were being made in implementation. I realised I needed something that worked for both - how could I present my step-by-step documentation in a way that is visually focused and dynamic?

*To view the Figma demo, click here. 

Attempt 4: Interactive Figma Map

The image to the left shows an interactive map of the final level that I made using Figma. I found myself really wanting to be able to have something that collects all of the interaction instructions in one place (without being one long document), and would allow the viewer to easily see how each NPC/object interacts with the other NPCs/Objects. When you have a web of interactions, this is really hard to communicate if each interaction is one individual image/chart.

This map was much more effective, and led to the entire team having a much greater understanding of the game and all of the interactions available to the player.

Post-Hot-Housing Iteration

Following the initial 4-week hot housing, we took our initial demo and gathered much feedback as we could. This feedback resulted in a major overhaul to the level design and main quests, which made my Figma map obsolete.

I had planned to make a new one for this new plan, however, I found that our new design just had too many moving parts, and unfortunately, the free plan in Figma did not have the capabilites to support what I needed it to do with this new level.

So, I made a prototype in Unity. Visually and mechanically, this is nothing like our actual game, however, the focus with this prototype was on the quest structure and understanding if this was intuitive or not. All that mattered was the basic layout of the map, and the positions and roles of all the interaction points. I felt that doing this in 2D would allow it to be done quicker as this where I'm most comfortable, and there was no real need for this to be a 3D prototype.

The playthrough video of this prototype is shown to the left, and you can also download the build here (download the parent folder named "Prototype Build"). This is very much a no-frills prototype, so it has no real UI or functionality beyond basic movement and interaction, but we were able to use this to test our new level layout and quest structure before implementing it.

Reflection/Next Steps

Our final demo for EGX can be played here. Overall, I am happy with the final product of the game, although there is a lot of things that we ran out of time to implement. Firstly, I would like to implement a proper interactive tutorial, as I believe this is a lot more effective in teaching controls. Secondly, I think the level is lacking in quite a few ways - I think it needs a lot more simple, silly interactions to enhance the experience overall (e.g., a life size floor piano like in Elf, or random bouncy parkour objects to help with game feel). Many of these were things that were designed but unfortunately not included in the final demo due to a lack of time to implement. I think ultimately, had we gotten the chance to make more concrete plans earlier (e.g., if i had made that unity prototype in week 1), we would have spent a lot less time deliberating and making big changes.

I learned from this project - mostly about prototyping, but I also learned a lot about making game demos, and truly how much time it can take to polish a build. Going forward, I will be making it much more of a habit to prototype as early as possible, and focus on prototyping individual mechanics/features, rather than prototyping an entirely fulfilling experience all at once.