Luciano van Waas
Level Designer
For Starters...
Project Roles and Responsibilities
Game Description
General Information
“An infection was cast across the forest, slowly killing Mother Tree and everything in its path. Mushroom Boy, otherwise known as Mushi, sets out on a quest traversing the unruly forest to collect enough magical flowers to heal Mother Tree and restore balance to the forest.”
Mushroom Boy is a 3D platformer inspired by games such as Banjo-Kazooie, Super Mario Odyssey and Donkey Kong 64. The project took a total of 6 weeks to develop and was made by a team of 11.
I only worked on Mushroom Boy for the duration of its concept and pre-production phase. This version of the game was never officially released. It was, however, continued into production by a different team. This version of the game was later released on Itch.
11 Developers
6 Weeks
Developed in Unreal Engine 4 Released on Itch
As for my personal roles and responsibilities within the team, i was one of the level designers as well as the main qa tester. due to the nature of the project however, with it only being 6 weeks long, everyone essentially did a little bit of everything, myself included.
I was actually the one that pitched the original concept of mushroom boy, or mush grove at the time. The main idea behind the concept was to combine smooth movement such as that of Super Mario Odyssey with collect-a-thon-like features such as that of Banjo-Kazooie and/or Donkey Kong 64. This really resonated with the team. This initial concept was then pitched to the stakeholders and greenlit into the remainder of the concepting and pre-production phases.
One of my biggest contributions to this project was the non-linear prototype. let me explain. Because the team couldn’t decide whether to go with linear, semi-linear or non-linear progression, I stepped up and offered to make a prototype/small player experience of what the game would be like were we to go for non-linear progression. This led me to do a bit of research into the world of progression…
Research: Semi-Linear Progression
Research Document
Having a clear understanding of your tasks and the expected deliverables is a crucial aspect of being a game developer. Engaging in thorough research plays a significant role in achieving this clarity. By working alongside the research document over the course of about a week, I was able to create a ‘semi-linear’ prototype. This prototype played a key role in guiding the team’s decision on whether to pursue this direction or not.
The full research document is embedded below and goes over the following research question: “What constitutes a non-linear level structure?”
Level Planning, Prototyping and Iteration
The Rational Breakdown
Example Challenge
3cs and Metrics
First Playable
Blockout/greybox
final deliverable
Initial Sketch
Planning out a level can be hard at first, especially when you open the editor and you’re met with an empty level. That’s why I always like to sketch out a rough top-down map before I do anything in-engine. These kinds of rough sketches may not make sense to anyone else, but that’s also not what they were meant for. Form follows function. Form will come once I have a better idea of what I’m actually making.
Throughout the years, I’ve come to understand that the worst thing you can when starting something from scratch is spend hours trying to get all the details right; trying to make it presentable for others. Get your ideas out there first. Details change.
The prototype is divided up into four sections. These sections each represent a different challenge and thus a different type of gameplay. For instance, the red section is all about timing and tight platforming, whereas the yellow and purple sections are more about exploration and figuring out how to get to certain collectibles.
one of the most important aspects of this prototype was its non-linearity. having researched non-linearity, however, i concluded that both this prototype as well as the ‘linear’ prototype were, in fact, semi-linear. as mentioned in the research document, this is because the prototype is split up into a handful of linear sections, as each challenge by itself is a linear experience. on the other hand, each collectible is available right from the start. This allows the player to pick which ones they’d like to tackle first. so, while non-linear in structure, it is linear in its challenges and thus, semi-linear.
This is the previously mentioned timing/platforming challenge being developed. It features some tight platforming and requires the player to have a fairly good feel for the controls, as it combines bounce jumps with gliding whilst balancing on these see-saw-like lily pads.
It also contains a shortcut for the more technically advanced players.
Before starting my work on the non-linear prototype, I was tasked with figuring out the 3Cs. This essentially boiled down to number crunching, playtesting and iterating until things felt right to the majority of testers (as well as complying with our game pillars).
This is the second iteration of the 3cs model (with the video to the left being the first). Multiple iterations followed after this. Over time, playtesters had fewer and fewer comments on the feel of the character.
Using excel, I kept track of the character’s/ camera’s metrics.
This is Mushroom Boy’s first playable. It follows about a week of individual feature development and contains small challenges and proof of concepts in order to be able to pitch and sell the concept of the game to the stakeholders. This was more of a collaborative effort than it was my doing.
This blockout (and all of its features) was a collaborative effort between myself and couple artists/programmers. The individual features such as the wind streams were not developed by me; they were requested by me. the set-dressing and texturing that followed was done by one of the artists. the both of us were in a hurry to deliver the product on time, so the detailing and overall framing of things is lacking. the same can be said for things such as the edge of world and sound design. however, as a prototype, it serves its purpose.
The final product.
Concepting: Sketching
Concepted Features
Initial Concept
This sketch presents a potential 3cs model, similar to that of Super Mario Odyssey. From Bounce Jumps to Double Jumps to rolls.
This sketch showcases the many ways of getting on a ledge using the previously mentioned 3cs model. It is meant to convey Mushi’s versatility as a character.
This sketch shows Mushi hanging from a glider, similar to how toad uses his ‘hat’ as a parachute in the super Mario bros. super show. The mechanic itself was mainly inspired by the Legend of Zelda: the wind Waker, however.
how does one distinguish between a regular ol’ jump and a bounce jump in terms of animation? Making Mushi do a front flip every time he jumps seems excessive. maybe make each jump into a skill-check, similar to triple jumping in Mario? Maybe only make him do a front flip last second if the skill check is successful? These kinds of discussions are good to have with your artists.
This sketch introduces the concept of a long-range enemy. it effectively functions the same way a fire piranha plant would. This concept made it into the production phase.
This sketch introduces the concept of, essentially, times jumps and falling obstacles. This tests the player’s timing. This concept did not make it into the production phase.
This sketch introduces the concept of a bouncy enemy. It would allow Mushi to reaches higher highs and thus new areas. This concept made it into the production phase.
This sketch, although perhaps a bit hard to see, introduces the concept of a catapult. This concept was prototyped but proved itself unfun and thus, ended up being scrapped.
This sketch introduces the concept of timed jumps in the form of timed platforms rather than obstacles. Keeps the player on their toes. This concept did not make it into the production phase.
This sketch shows a more elaborative sketch of the previously mentioned bouncy enemy and how it can be used to cross large distances by chaining moves together.
Takeaways
Takeaways
Although easily dismissible, research is vital to the development process. Make time for it. Instead of dismissing it because you feel you have other things to do, postpone those other things until you’ve researched. It might not be the most engaging thing in the world, but you will need to get into the habit of researching before actually designing anything.
Prototyping is about conveying your ideas with as little effort as possible. It is a representation of your design before a final solution has been decided upon. Don’t be overly perfectionistic.
Leave room for iteration. Prototyping is iterating. If you’re simply making a prototype for the sake of making a prototype, don’t. Take it seriously. Iterate on your prototype as often as you feel is necessary. Ask for feedback. Try different things.
Keep it simple, stupid. Simplicity should be a key goal in design, and unnecessary complexity should be avoided; I tend to get lost in detail, making it difficult for me to see the bigger picture at times. Keep things as simple as possible. Don’t overdo it. You don’t need to build an entire level to show off a single mechanic; you’re making a proof of concept, not a game.
Find a process that works for you. Research is ambiguous; everyone has a different way of going about it. You need to find your own way within the system. The system is too general to service you, or anyone for that matter, to their full potential. This can be said for game/level design principles as well. Know the rules before you break them, but make sure you find a pipeline that works for you.
Contact
© 2024 Luciano van Waas. All rights reserved.