Driftonaut | Florent Bleser

Driftonaut
Design Process

Driftonaut was one of the four projects I worked on during my internship at EduGamiTech. During my time there my responsibilities included:

Conducting initial brainstorming session with the development team (project manager, two programmers, one artist and one designer)
- In these the whole team came up with ideas for different games together.
- I made sure to give everyone the opportunity to communicate their ideas while keeping the session going without dragging.
Designing a core gameplay loop from those sessions and create a preliminary design document
- Based on the ideas I collected from everyone I picked what I thought best worked together, to create a coherent and fun game design.
Presenting the refined project idea to the project manager
Leading further design sessions with the team and come up with additional mechanics and finalise the gameplay design
Creating all the game's levels
Joining client meetings and redesigning the Memomoti website and mobile interface based on their needs in collaboration with the CEO and CTO

Introduction

Imagine gliding through space, using every wall you have to navigate back to your ship, and the path ahead is full of challenges. Welcome to Driftonaut, where puzzle-solving meets playful learning!

As part of my internship at EduGamiTech, I was in charge of game and level design for a number of projects we created from scratch for a multi-platform learning application called Memomoti. The concept of Memomoti is that users can create their own quizzes that are then implemented into different games to help players memorise the answers. They can choose whatever quiz they want and use it in any of the games available using the website or app.

Concept

Driftonaut is a puzzle game inspired by the classic ice sliding puzzles often found in the Pokémon games. In them, players must navigate a frozen lake while sliding on its surface, which limits their movement until they hit an obstacle.

Image: https://unboundwiki.com/walkthrough/part-10/

Overview:

Gameplay Mechanics: Sliding through space with limited movement and using obstacles to your advantage.

Educational Element: Four-directional wheel for answering questions to personalised quizzes.

In Driftonaut the player incarnates a lost astronaut that needs to find their way back to their shuttle through an asteroid field. What makes this game special is the educational twist. Players not only solve puzzles but must also answer questions correctly to progress. Each answer directs them on their journey through the void, creating a compelling blend of fun and learning.

To this end, we added a four-directional wheel that can be turned. Each side of the wheel represents one possible answer. The player will have to find out how to reach the end of the level and correctly answer the questions, or they’ll travel in the wrong direction, namely the direction the correct answer points to. So if the player chose answer B to move to the right but the correct answer was C, they would go down instead.

This serves two purposes. First, it adds to the initial challenge of the puzzle, making each step count more. Secondly, it also communicates the correct answer to the player, which is very important since the platform is centred around a play-to-learn concept.

(Driftonaut screenshot)

Level Creation

Each level is built in a tile-based grid where different ground tiles have different effects on the player as well as different obstacles that interact in a specific manner with the player character.

Overview:

Initial Design: Start with patterns or objectives.
Guideline Implementation: Use guidelines for clarity.
Obstacle Placement: Integrate challenges for the player.
Testing and Iteration: Ensure design objectives are reached through testing.

The levels are divided into five worlds. The first world contains 4 tutorial levels; world 2 allows the player to become familiar with the basic game concept, and worlds 3, 4, and 5 each implement a new mechanic.

My role was to design these levels. I set myself the goal to not use any text to explain how the game works, as I’m a firm believer of the “show don’t tell” philosophy whenever possible. This also had the added benefit of not bloating our already short development time with unnecessary tasks for our team and avoiding further points of failure.

After a while, I had nailed down level creation to a more or less fixed process. For each “world”, I would create key levels that either introduced new mechanics or paired them with existing ones in a new way. Then I would come up with a couple of extra levels to allow the player to deepen their knowledge of existing concepts and enjoy their mastery thereof.

Here is an example of what a typical process of level creation looked like. I used an application called Tiled that allowed me to quickly generate levels and later convert them to be used by the game.

First, I would either start with a certain pattern or with a specific objective. Here I wanted to have the player use two pairs of portals to reach the end of the level. Whenever the player enters a portal, they would leave the other portal of the same colour on the other side. So if, for example, they enter a green portal from the bottom, they would slide out of the other green portal towards the top.

(white circle: start; black circle: finish; ovals: portal pairs)

Once I decided on a design objective for the level I would map out a path the player could or will have to take to finish the level. I would make sure to integrate guidelines inside of the original file. This was not included in the final level but allowed us to keep track of what is going on and root out any possible mistakes later.

(arrows: guide lines)

Next, I put up the necessary elements to allow the player to take the path I mapped out. Here I put in obstacles that block the player on contact and some walkable tiles that they can walk on instead of sliding.

(grey boxes: obstacles that stop the player; white tiles: walkable tiles)

Then I put in the boundaries so the player doesn’t slide off to infinity and tried my best to “break” the level. This means that I tried to find ways to resolve the level in a different way than planned. Where early levels have multiple ways to solve them on purpose, later levels are supposed to be harder and make the player think multiple moves in advance. The most important, however, is to not let the player find “shortcuts” that would render a big chunk of the level useless.

This step always took the longest. I would go through dozens of iterations before making a satisfying level.

(now with additional blockers)

(example of multi-path level solution)

Finally, I would fill in the grid with the appropriate missing tiles. The map was then converted to a JSON file that the game would use to generate each level.

(map completely filled, ready to transfer)

This whole process allowed me to develop a way of streamlining the production of levels. Using agile development was important for testing, as sometimes I only saw the problems in a level after playing them. Additionally, being able to quickly churn out playable levels allowed others to try them out, as not everyone would have an easy time trying out paper prototypes. Their input was sometimes invaluable to polish the level design, especially as level complexity increased.

Collaboration was key. Regular playtesting with the other team members provided great feedback, allowing me to refine level designs and enhance player experience.

Conclusion

The goal we wanted to reach with Driftonaut was to to create a puzzle that merges fun with learning. With each level designed to challenge players' minds and foster educational growth. We aimed to create a memorable experience that engages an older audience while still accomplishing the promise of learning their desired subjects.