KEEPERS OF THE TREES
TYPE: Team Project | Studio Chili
STATUS: Under Development | December '19 - Present
SOFTWARE USED: UE4, Blueprints, Maya, Photoshop
Designing, Implementing and documenting action blocks that integrate the mechanics of the game in different combinations.
Responsible for the first level of the game through all the stages, from concept to completion.
Creating diagrams to better illustrate the plan for the level and achieve better communication with other team members.
Bug tracking and reporting.
Documenting playtesting feedback and iterating on the level.
Keepers of the Trees is a local co-op puzzle-platformer. Each player controls a Keeper, a curious little creature. As the Keepers, players solve puzzles by utilizing a variety of plant life to traverse their magical forest magical forest home. Only be learning the unique properties of these plants - and by working together - can players succeed!
GAMEPLAY VIDEO AND IMAGE GALLERY
THE DESIGN OF THE GAME
Here are listed the basic mechanics and interactions of the game that take place in the level. They are displayed in order to gain a better understanding of the main idea behind the first level of the game, and the action blocks designed.
Growth Zone: Specific areas in the level. Only there players can grow plants
Mushroom: Used as bounce pads.
Beanstalk: Used to climb up to higher areas, or across gaps. By leveraging the tendency of plants to grow towards light sources, beanstalks can be made to grow in any direction, not just straight up
Leaves: Players can grab the tip of the leaves, creating platforms for their each other.
Dandelion: Players can use it to traverse large gaps.
Wind Volumes: They push players with dandelions even further. Players cannot climb beanstalks if a wind volume overlaps with the beanstalk.
Bramble: Environmental hazard. When enemies touch it, they lose health and are launched backwards.
PREPRODUCTION AND EARLY PRODUCTION: ACTION BLOCKS
During preproduction and through the early stages of production, one of my main responsibilities was to implement different in-engine action blocks that combined the game's mechanics in different ways and create different traversal puzzles for the players. From a design perspective, the main challenge of this process was designing puzzles that required players to work together towards finding the solution and avoid having one of the players staying idle for a long period of time.
Clear documentation of each action block was also a very important part of the process and helped the entire team better understand the intent behind each design. In this way it was easier for the leads to better decide which action blocks should be further explored as potentially being in-game.
Documentation: The initial shortlist of action blocks involved vastly different designs, as well as different iterations of the same idea. Each different idea has a different column and all the elements in the same column are iterations or improvements of the initial design intent.
Different Combinations: Below, are displayed different action blocks as well as the game mechanics they combine.
Players have to jump from one beanstalk to the others, while avoiding the brambles in between.
One player plants the starflower in different positions each time, in order to create the proper shape for the beanstalk to pass through the brambles
One player grabs the leaf to block the wind volume so that the other player can climb the beanstalk
Upping up the scale: A small level designed to be experienced as a big traversal puzzle where players have to utilize the majority of game's mechanics.
PRODUCTION: FROM CONCEPT TO WHITEBOX
Step 1: Progression, Flow and Conveyance Diagram
During this phase I took responsibility of the first level of the game. Having in mind the special requirements a first level in a puzzle platformer must fulfill, my main objective was to make sure that the level will convey properly the majority of the mechanics to the players. Consequently, my first action was to create a holistic diagram that encompasses level's Progression, Flow and also when and how each plant is going to be introduced to the players. Basic principle was to give players the time and space to familiarize with many different layers of each mechanic rather than presenting a variety of interactions that exploited numerous mechanics in very superficial ways. In order to view a larger version of the image below, please click here.
Mechanics: In what sequence they will be introduced to players.
Progression and Flow: Keeping player's interest by either escalating difficulty, introducing new mechanics, scripting in-game events or delivering "wow" moments.
Action Blocks: Transferring certain ideas from early production into the actual level and use them to convey mechanics or design platfroming challenges
Art Style Guide: References from team's art style guide, function both as inspiration for me as well as a means to better communicate the general idea to the rest of team members.
Another consideration I made sure to incorporate in this diagram was the fact that the first level should, from a design perspective, hook the players in the game and keep them engaged to stay for the ride and experience the levels to come. For that reason I also noted down the "wow" moments of the levels, areas where the layout on its own should be visually appealing and keep players interested. Finally, to ensure better communication with the leads and the artists of the team, I put in sequential order both the action blocks that I was intending to use as well as reference images from our art style guide to better convey the look and aesthetic of each area of the level.
Step 2: Layout and Whitebox
Next step was to create a basic layout of the level and start blocking out the level. Given the nature of the game and the importance of playtesting, my teammates and I were frequently playtesting and iterating on every part of the level, to make sure that each area met the criteria set by the leads and the holistic diagram displayed above. Scope was another very important factor that I was taking into account. I wanted to be as agile and proactive to tackle scope issues so I was more than open to limit the entire length. This turned out to be a great opportunity for me to try to be more efficient as to how I was designing specific interactions and how much time I was dedicating for each mechanic
On the left image, the initial whiteboxed level; on the right, the final version after playtesting and incorporating scope restrictions.
Introducing players to growth zones and mushroom mechanic. Basic platforming section for players to get comfortable with jump heights, distances, use of mushroom
1st and 2nd puzzles that require cooperation: players are introduced to the grabbable leaf mechanic. As a means to create a platform and as a way to let the light in dark areas, dynamically creating growth zones.
1st "wow" moment and encounter with beanstalk: players use the mechanic to get out of the cave and see the world for the first time.
Platforming section with beanstalks: Players are introduced to the fact that they can catch a beanstalk mid-air.
3rd puzzle that requires cooperation. A different iteration on the two previous puzzles.
By the time we started moving into full production, around early March, the COVID-19 pandemic affected the entire planet. From the very first moment, the entire team was very dedicated and showed admirable drive to continue the development of the game uninterrupted. Surely, it is not as easy developing a game during these unprecedented times but we transitioned to working remotely quite smoothly. Things we did as a team included:
Held online stand ups twice a week, keeping everyone updated as to how things are improving.
Held "Core Hours" during workdays - hours where everyone would be available to each other to help answer questions or troubleshoot potential issues.
Got even more familiar with JIRA and Confluence bug tracking tools.
Held online team bonding activities to help everyone stay in touch for not work-related issues as well.