— PLATFORM
Oculus/Meta Quest 2
— ENGINE
Unity
— TARGET DEMOGRAPHIC
The Last Garden is a call to action for everyone
— ROLES:
Producer, Designer, Programmer
— KEY DESIGN REQUIREMENTS:
1a: Educate players on British Wildlife and Hedgehogs
1b: In doing so, be engaging and interactive
2: Be accessible to audiences of all skill levels.
This page focuses on the Gameplay Design for The Last Garden. For a page focusing on its Narrative Design, please click here. To view the gameplay, please see the video below.
Overview
The Last Garden is a VR Docu-Game about protecting and preserving British Wildlife, with a focus on hedgehogs. The Information in the game is publicly available from The Woodland Trust and Gardeners' World.
The player takes on two roles: one of an ‘overseer’ and one of Spiky the hedgehog, looking for a place to hibernate for the winter. The game is designed as an interactive and engaging way to educate players on how to prepare their gardens to be suitable for hedgehogs. It also raises awareness of the current state of British woodlands and Wildlife.
The Last Garden was built for the Oculus/Meta Quest 2 (shown running, left).
Game Design
A large portion of The Last Garden’s gameplay is kinaesthetic – the player must pick up, move and place down objects using their hands. In this game, the player is carrying out activities that will make a garden more suitable for hedgehog habitation. By using this style of gameplay – a unique selling point of the Quest 2 – the player is actively and physically engaging in the lessons they are being taught.
For example: in Level 3, the player encounters a vegetable patch in which the gardener has used slug pellets (above, left). By turning the job of collecting and binning the pellets into interactive gameplay and physical engagement, the task should be retained in the player’s mind more effectively.
One of my inspirations for creating this game came from talking to The Woodland Trust at EGX 2021. Because of this, the game was designed with the potential to be used at conventions. Therefore I designed it (and confirmed with playtesting) to be easy to interact with even for users who were unfamiliar with video games. At the core of the game, the only two things players have to do is pick up / put down objects and move Spiky. My Nan, who has never had any experience with using a game controller, found the controls easy once she took a couple of minutes to experiment and understand how they worked.
At times, I needed to be more considerate with the level design to keep Spiky’s traversal engaging. I made sure the levels had some form of verticality, although this had its own set of considerations due to the small scale of the worlds and the fact that Spiky can’t jump. In the first level, the player has to navigate over a river and has the option to move Spiky through burrows (above, middle) whilst listening to the narration. Then in the second level the player can arrange some props in order to traverse and reach one of the game’s collectible hats. In later levels, there was more interaction involved on a kinaesthetic level so this took main focus in the game design.
Part of the game’s development took place over the Christmas period and, for fun, I added a party hat to Spiky during development. Playtesters loved this element of the game and felt it added even more to the ‘cuteness factor’. Subsequently, I implemented more hats and made them optional collectibles in the levels (above, right). The hats used were: a party hat, a magician’s hat, a mining helmet and a Viking helmet. In each level, the player has the option to complete a different side-objective in order to obtain the hats. My personal favourite is the Viking helmet – the player needs to water a pile of dirt lined up amongst some other plants using a watering can. It can be found in the same place as the level’s other objective props. Once the plant grows, the hat appears.
Creative Agenda
The Last Garden was made over three months, working on it part-time. I decided on the scope of the project and designed the game to be completely functional and free of bugs before working on the environment art and any other business. My priority was to make sure the game functioned cleanly, so I tested the design and programming with as close to a blank canvas as possible before swapping out assets and materials, set dressing, adding quality of life and adding collectibles. Pictured above (left) is how the game looked for most of the production process (With the exception that it also had a less detailed terrain at the time).
When developing the gameplay concepts for The Last Garden, I realised its similarity to Polyarc’s ‘Moss’ (above, right). Whilst The Last Garden was going to be much smaller in scale and use a character with limited mechanics, the core gameplay idea was very similar in that the player would control both an in-world character and themselves as an overseer. This allowed Moss to act as the lead gameplay reference. The Last Garden’s simple movement system worked well for a game of its size and agenda. It was also a learning experience for me to work on a ‘character-based’ game where the character couldn’t jump, sprint or interact with the environment. Spiky’s movement was kept as simple as possible due to the need for the game to be accessible to audiences with all levels of experience. This didn’t affect the engagement factor of the game as I balanced the gameplay with the ‘overseer’ perspective. In the future, I would like to look at the possibility of adding subtitles to the game – considering accessibility was one of the project’s focus points, it is likely to be difficult to follow for those who are hard of hearing.
The Character / Overseer combination works by using the face buttons on the Quest 2 controllers to control the character and the movement sensors and trigger buttons to control the overseer. This system worked intuitively in Moss so I was confident the same would be true for The Last Garden.
Technical Challenges
As mentioned above, the only way the player can control Spiky is by making him walk around. Because of this, I wanted to make sure his movement was as polished and fluid as possible. Because Spiky would be moving on sloped ground, I made sure the character’s rotation would accurately match the slope he was on (above, left). To do this, I used a raycast to find the surface normal where Spiky was standing and then used the ProjectOnPlane function to redirect Spiky’s movement direction and used that to drive his rotation. This movement system works well for a game of this duration but a longer game would have suited at least a slightly more diverse movement system. The hedgehog asset used in this game was downloaded from the Unity Asset Store, but for a larger game I would get a custom character made. The model I used was limited in its available animations.
Another challenge I faced greatly emphasised the importance not only of playtesting, but also of closely analysing how bugs happen in the tests. Early in development, I came across a peculiar issue where, for no immediately obvious reason, sometimes placing one of the first level’s bridges (planks (above, middle)) would cause the player to not be able to pick up another object. The bug turned out to be an issue where ‘placing’ the plank by holding it until it was in place (instead of ‘dropping’ it into place) would cause the hand’s code to still think it was holding something that it could no longer drop. I therefore changed the code to force the hand to release the plank before swapping it out for the static version. This is something I wouldn’t have noticed without closely observing how the playtesters were interacting with the levels.
Another bug I encountered is still unexplainable at the date of writing. The trees and foliage all worked fine in the Unity Editor, but when building for Android (the platform the Quest 2 runs on) all the foliage that was directly in front of the skybox (with no meshes in-between) would show up black. I tested settings and searched for solutions to no avail: most forum posts described issues where the transparent areas of the textures were showing up as black, but my issue was essentially the reverse of this. Areas of the texture that were meant to be coloured would be pitch black. Solving this required creative thinking – the solution I found came from noticing the issue wasn’t present when the camera was fading in and out at the beginning and end of levels. Deductively, I made a box that surrounded the entire level (above, right) and set the alpha very low. For some reason this fixed the issue and the foliage textures started rendering correctly. On top of this, because the box surrounding the level had such a low alpha, players can still see the skybox, which adds to the mood of the game.