Creative Vision
-
Adventure Plot
-
Main character is an explorer/treasure hunter.
-
Driven by adventure and the promise of valuable treasures, he is always out risking his life while searching remote locations for priceless objects. Often he will receive a tip to search areas, and he is known to accept the occasional contract to recover lost items for others.
-
-
Adventure Genre
-
Genre
-
Third-Person Perspective
-
Adventure/Exploration
-
Puzzle Solving
-
-
Time Period
-
Near Future
-
Minimal Sci-Fi Technology
-
-
Location
-
Takes Place on Earth
-
-
-
Design Pillars
-
Exploration
-
Driven by adventure and the promise of valuable treasure.
-
-
Platforming
-
Simple platforming built into the environment.
-
-
Puzzle Solving
-
Simple puzzle solving using environmental interactions.
-
-
Design Restrictions
-
Do Not Deviate from the Plot
-
Designing a level that must fit into the Adventure Game. Not allowed to alter the game's plot, character, or any other narrative elements.
-
Must not include any major plot points in level narrative that would affect the entire game world (i.e. apocalypse, alien invasion, etc.).
-
The Adventure Game is grounded in reality. All narrative and gameplay elements must be realistic or believable to exist in real life.
-
-
Do Not Edit the Player Character
-
Cannot edit the player character blueprint at all.
-
Cannot add new gear to the player character or make gear a collectible (i.e. collect hazmat suit to be able to enter hazardous areas).
-
Cannot give the character any new abilities.
-
Cannot add new animations to the player character.
-
Cannot add new inputs to the character or game overall.
-
-
Do Not Add/Edit Game Systems or UI
-
Cannot edit any of the core systems (i.e. interaction, collectibles, checkpoints, etc.).
-
Cannot add any new systems to the game (i.e. health, climbing, etc.).
-
Must utilize the provided core systems. Cannot create a custom version of a system that is already in the project.
-
All interactions must use the provided interaction system.
-
All items that can be picked up must be the provided collectible.
-
-
Cannot add any new user interface elements.
-
-
Do Not Use Game Systems for Unintended Use
-
Cannot use the checkpoint system for,
-
Dialog
-
Inner Thoughts
-
Any Means of Messaging
-
-
Cannot use the ledge grab system to,
-
Create ladders
-
Any continuous climbing
-
-
-
Do Not Add Enemies, Combat or Stealth
-
Cannot add enemies of any kind.
-
Cannot add combat gameplay.
-
Cannot add stealth gameplay.
-
Cannot add weapons to the player character or use mounted weapons for combat.
-
Mounted weapons are acceptable if used for level interactions only.
-
-
-
Do Not Create New Controllers
-
Cannot unposses the main player character or give control to another actor.
-
Cannot add any controllable actors/systems.
-
Drivable Vehicles
-
Mini-Games
-
Aimable Weapons
-
-
Temporarily disabling the character's input is acceptable.
-
-
Do Not Add AI or Interactive NPCs
-
Cannot add AI to the game.
-
Able to add people/animals to the level, but they must be placeholders and are not allowed to be interactive
-
Single animations are acceptable. Example: A fish jumping out of water or a bird flying off in a direction to catch the player's attention.
-
-
Do Not Include Fantasy or Magical Elements
-
Must stay grounded in reality.
-
Cannot include any fantasy elements. (i.e. monsters).
-
Cannot include any magical elements (i.e. floating platforms).
-
Cannot include aliens or alien technology.
-
Cannot include any paranormal activity or entities (i.e. ghosts).
-
-
Science fiction technology is acceptable. Avoid science fantasy.
-
Sci-fi elements must be kept to a minimum.
-
-
Do Not Include Political or Religious References
-
A made-up cult is acceptable.
-
What Went Right
Water Level Control Mechanic
We had to design and implement a mechanic to feature in our level for this Adventure project. I chose to create a water level control mechanic, but I wanted to incorporate it into the platforming aspect of the project. So, I made a water tube that would take input from an interactable wheel and adjust to varying heights, allowing the player to reach a goal that was at a higher elevation. Additionally, I used the introduction action block of the mechanic to demonstrate the minimum and maximum heights the tubes could reach and to show the player that they are climbable objects; attempting to raise or lower the tubes past the threshold resulted in a stern "NO" from an otherwordly voice. Furthermore, an aspect of the mechanic was the ability to control multiple water tubes with a single valve, also demonstrated during the introduction action block.
Unfortunately, I had trouble getting it to function correctly during the creation stage. I successfully mapped multiple water tubes to a single valve, but if one of the partnered tubes was at its minimum or maximum value, the other could still be adjusted, something I didn't want to happen. So, I dove back into my blueprints and created a check, which took me way longer than it should have, that successfully denied input if either tube was at a threshold.
Platform Pathway Puzzles
.png)
The practice and master action block sections of my level required the player to adjust the height of the water tubes in a room to create a pathway to reach a button that would allow them to progress, both in the level and towards the exit. The first part of the practice action block had one valve controlling one tube, then escalated to two valves controlling a pair, while a third valve influenced one water tube. In this action block, the player needed to make two sections of straight walkways, which allowed them to explore the level mechanic further. In the master action block, I wanted to keep the same three-valve system as the latter part of the practice section; two valves controlled a pair while one managed a singular tube. However, for the mechanic conclusion, I wanted the player to create an ascending path that led them to the final button and the level exit. Overall, I was happy with how each action block came out; they provided a challenge, didn't punish the player for performing them incorrectly, and didn't rely on trial and error to overcome.
A Clean Getaway
While designing the level-end section of my project, I didn't know how I wanted the player to escape the underwater lab. I thought about having them flee in a boat in a secret cave or a submarine tucked away in a launch bay. Ultimately, I decided that those options didn't reflect my personality and chose the only suitable option I could think of. After completing their bounty by freeing a mysterious specimen, the player must navigate a short series of rooms requiring minor platforming. The final area has an elevator that, when the player boards, slowly returns them to the surface. When the player sees daylight again, they'll find themselves making a clean getaway as they emerge from a shower in the house above the laboratory. This ending sequence reflected my personality the best; it was a bit silly but fit the whole water aspect of the level.
What Went Wrong
Environmental Blockmesh
The design idea for my level started as a single island but evolved into a Sea of Thieves-inspired dual island before the actual blockmesh began. I wanted multiple pathways that crossed over and under each other but still led the player to their goal. Additionally, I wanted to use this project to practice framing; initially, the player was supposed to see the island house from the starting area. However, as I began laying down blocks and constructing the pathways, I felt that I wasn't capturing the island aspect adequately, besides the fact that there were no trees or shrubbery of any kind. To make the island feel less block-like, I began using geometry brushes to create formations that felt more like rocks, but I bit off more than I could chew and ended up rushing the second half of the overworld to make the deadline. I need to practice my blockmesh more in the future; I feel somewhere between doing too much and too little to give and deny affordance to objects and the environment. Some greenery wouldn't hurt.
A Hop Too High
Although there was no health system for the player character, this project had a fall damage mechanic; if the player character falls over 950 Unreal Units, they reset to the previous checkpoint. The secret elevator that lowers the player character into the underwater lab drops 5000 Unreal Units. For reasons I cannot explain, after the player exits the elevator and begins making their way through the introduction action block of the level mechanic. If they were to input a minor jump and leave the floor for even the briefest of seconds, they would whisk back to the checkpoint at the beginning of the level; I'm still digging around the blueprints trying to figure this one out. The conclusion I've reached is the elevator travels too fast, and the player character is perceived to have "fallen" a great distance, but since they never actually leave the floor, the check isn't run until their next jump.
I Need Some Tension
.png)
I wanted the level escape to be a tense sequence. The player would free the specimen, it would break through a wall and begin flooding the lab; that was the idea. However, I spent more time getting my mechanic to function correctly than I had planned, which led me to rush the creation of some areas, namely the latter half of the overworld and the level end section. So instead of being a nail-biting race to the exit, the player traverses through a couple of rooms that feel empty and do not build tension by any means until they reach their evacuation. I'm particularly disappointed because I didn't give myself enough time to properly design and layout this level section. I hit my deadline for the level completion, but I could have spent more time in this area and polished it up. It didn't communicate that this section was the level's climax and the player needed to make haste to the exit; it felt more like a pathway connecting to another part of the level.