How we made an overscoped student project in seven weeks without destroying ourselves
Published 2 years ago
1.0 K
Reflections on the making of an ambitious 3D puzzle-platformer made by 9 students in 7 weeks
I am currently studying game design at Futuregames school in Stockholm, Sweden. As a final assignment for the first year, me and my group were tasked with making a game with Unity in 7 weeks (+ 2 weeks of preproduction). This is the big, final project - as the second year of the course doesn’t focus on game projects -, the one in which you can really try something ambitious and build a solid entry for your portfolio. With a team of three game design, four 3D graphics and two 2D graphics students, there is the capacity and time to create something interesting. But I didn’t want to just create something interesting; I wanted to test our abilities and deliver something that people couldn’t believe was made in less than two months.
This article is both a postmortem of the development process from my point of view (so, sorry but there won't be much about graphics, level design or other part of development outside game design and scripting) but also a way of reflecting about scope and how to manage it.
The task was to create a game with 3D action, playable on PC, with some element of alternative history in the theme and some form of interaction between 2D and 3D elements that wasn’t just UI. Me and the other designers, together with the 2D artists, started working on different concepts and ideas during pre-production. The idea that emerged from this 2 weeks period was about a 3D puzzle platformer with elements inspired by 90s 3D platformers, The Legend of Zelda: Breath of the Wild and Pokémon. If it sounds weird and way out of the scope of a student project it’s because it actually is. And yet, we managed to make it and we also survived the process of making it.
The final result of our effort is The Dino-tastic Adventure of Amelia Apeheart (or just Apeheart), a 40 minutes-long 3D puzzle platformer in which the player plays as aviator/explorer Amelia Apeheart. Amelia lives in a world where dinosaurs never got extinct and apes evolved instead of humans. Her plane crashes in an island populated by the successors of dinosaurs and she needs to survive the traps and puzzles among the ruins of a lost civilization. The dinosaur-like creatures in the island play a part in this: they have elemental powers such as the ability to spew fire or ice, and Amelia can pick them up and use them as some sort of weapons.

1 - The chemical engine

In this project I acted as lead designer and lead programmer, handling the large majority of scripting and designing the game’s systems. The system at the core of the game, the one that makes the foundation of all the puzzles, is the elemental system. A few months ago I watched the GDC session held by some of the lead developers of The Legend of Zelda: Breath of the Wild. Just like every other game designer who watched it, I was extremely fascinated by the description of their “chemical engine”. Breath of the Wild uses a system that allows every dynamic object in the world to have different states that interact with their properties: wood burns, food gets frozen if left in the snow, metal transmits electricity and so on. The interaction between states allows some of the most creative puzzles and situations in recent gaming history.
I wanted to see if I could do, in a microscopic way, something similar. I decided to focus on two states, burning and frozen, and one “modifier”, wind. I created a state machine script that handles the state of an object and its properties.
The diagram above shows the different states and how they interact. If an object is on fire and gets turned off, it transitions to the neutral default state, and the same applies to a frozen object that gets in contact with fire. Considering the time and resources constraints, I tried to make sure that each state would have limited effects, but these effects could create interesting gameplay and puzzle opportunities. Together with the other designers, I started thinking about how these properties could be used in environmental puzzles. One of the first puzzles, for example, requires the player to burn a wooden scaffold to retrieve a stone block to use on a nearby switch.
Later in the game, the player needs to combine effects and change state to objects in specific orders with the right timing.
An interesting thing we noticed is that designing environmental puzzles based on this system resulted in several puzzles that could be solved in different ways. For example, freezeing objects allows the player to move them more easily...
One puzzle required the player to freeze a moving wooden box mid-air to make it slippery and let it easily slide over a chasm. But we soon noticed that some players could also just use the power of the wind creature to push the box over the gap. Compared to traditional "key and lock" kind of puzzles, we were pleased to find that these puzzles gave some degree of freedom to the players.
The effect state system is one of the features I am most proud of in this project, and definitely something that I wish we had the time to further explore and expand but, even in its current state, I also just love the fact that you can pretty much burn everything down.

2 - Catch ‘em all

As I mentioned before, the dino-like creatures play an important role in Apeheart. Quite early in the concept we thought that it would be visually interesting to have our main character holding the creatures in her arms and use them as if they were guns. Like in Pikmin, we thought that having your “weapons” following you in the world would make you feel attached to them. Moreover, I wanted to learn how to use the navmesh and agent system of Unity and how to create a simple AI system and I thought this was a great opportunity to do that.
In Apeheart, Amelia start her adventure alone, but during the game she finds several dinos to follow and help her. In the game there are three dinos (with fire, ice and wind powers) that the player needs to find in order to progress and two optional ones. Everytime she finds a new creature, the dino will be added to an inventory we - very cleverly - named Dinodex. From the Dinodex, the player can assign up to four dinos to follow Amelia and be usable at any moment. The dinos follow Amelia and jump in her arms when they are selected. Making sure that the dinos would follow Amelia, trying to navigate the environment in a realistic way and, in general, add charm to the game was a pretty tough challenge. But in the end I found the agent system of Unity very flexible and quite easy to understand and I am extremely happy of how the creatures appear in the game. They truly are adorable, in no small part because of the animations created by our animator.

3 - The final result and how we managed scope

Apeheart ended up being a 40-minutes long game spanning two big levels and it’s way larger than the 20 minutes vertical slice that was the requirement of the school for the project. In order to manage the scope of the project, we tried to design our way around our time and resources limits. For example:
  • I tried to use Unity Standard Assets in the most efficient way. The main character, for example, move thanks to an adapted version of the standard third person controller. I rewrote many parts of it and adapted other parts to suit our game’s gameplay style, but it certainly saved me a good chunk of time to not have to write everything from scratch.
  • We designed every single system in the game to have the minimum amount of complexity required to fully express a feature. For example, even if in the hypothetical final game the player is supposed to find new creatures with slightly different powers all the time, we decided to just have 3 main and 2 optional hidden creatures. The effect system is also limited to the minimum amount of states to guarantee a varied gameplay.
  • We used platforming more extensively than originally planned. During development we realized that designing puzzles was time consuming, so we decided to focus on less than a dozen puzzles and use platforming sections, which are relatively easier to implement, as a way to give variety and rhythm to the experience. This proved to be a controversial choice, as the control system was not designed to be used for traditional high precision platforming. Even if I tried as much as possible to improve controls to match the platforming sections, I feel they are still not as good as they should be.
  • We prioritized and cut features as early as possible during development. We spent most time in the beginning to make sure that the core systems of the game worked and were fun and we tried really hard to reach a feature complete state three weeks before the deadline, to focus the last part of development on bug fixing and polishing.
  • We tested with new players every week to make sure we had constant feedback and we knew what to focus on and what to improve. Fortunately this meant we never had to pivot or make radical changes, as everything was tested very early.
Apart from all the concrete things I have learned during the project, I believe that the most valuable lesson was actually related to scoping. I am now firmly convinced that one of the most important skills of a game designer is the ability to plan and estimate scope. Having been in disastrous projects that initially seemed way more manageable than Apeheart made me realize that scope is much more than “the quantity of work”. Being able to set the scope of a project requires careful design early in the process. In particular, I learned to be very wary of features that are not working at a prototype stage. Thinking that a feature "is not fun now, but it will be fun once polished" can be true sometimes, but it's also something that can cause big problems along the way. An enormous quantity of time during development can be saved by limiting those kind of features already in pre-production. If I learned one thing out of these 7 weeks is that it's crucial to find the good parts early and focus on them (a truism, perhaps, but I will make sure to not forget it).
Even if it's far from perfect, Apeheart ended up being the best game I have ever worked on and one of the most pleasant game development experiences I have ever had. I had the privilege of working on a crazy ambitious student project with a group of extremely talented people. And even if we will probably won’t make a complete game out of our (large) vertical slice, there’s a good chance we will actually release Apeheart very soon. Follow us on Facebook if you want to get updates and be notified when Apeheart will be released.
Ferruccio Cinquemani
Game Designer and Developer - Student