Everent
Team Size: 18
Project Duration: 10 months
Software Used: Unreal Engine 5, Perforce
Languages Used: Blueprints, C++
Primary Role(s): Technical Designer, 3 C's (Controls, Camera, Character) Designer
Everent is an open-world hoverboarding speed-platformer set in the skies of Stratos. Take the role of Ollie, as they explore the ruins of these sky islands and destroy the machine responsible for the decay.
Tech Design Contributions
Camera
Level design by and recording courtesy of www.lanatherrien.com/
Our hoverboarding main character has 6 degrees of movement, rides walls and ceilings, and boosts through the air. I saw early on that our game would have urgent dynamic camera needs and I proactively took them on. The camera was one of my major areas of ownership. It was a major challenge, and almost all of its logic was written by me.
Process:
-
Playtesting, Playtesting, Playtesting:
-
We held playtests with other game dev students, internal playtests, and large playtesting events with high schoolers and middle schoolers
-
Camera was a major issue in every early playtest, so I showed up to as many as possible and made sure to:
-
avoid asking leading questions
-
encourage playtesters to think out loud and be candid
-
take thorough notes
-
-
-
Sometimes it was taking playtest feedback at face value and looking for common pain points in the data, other times I had to do more research and read in-between the lines
-
-
Research:
-
I had to become the expert in cameras quickly, this involved:
-
Watching GDC talks, particularly this talk on dynamic cameras by a Journey dev
-
Learning about what causes motion sickness in games, and how it can
be mitigated
-
-
My design lead, Tyler, streaming his phone camera to discord, demonstrating possible camera movements
Feedback from an early playtest shows
camera should be a top priority
Camera design and features:
-
decoupled from player in separate BP to allow greater control and freedom
-
orientation with horizon line maintained to give player their bearings even when attached to walls and ceiling
-
especially important since gravity comes back into play once player detaches from
a surface
-
-
manual control fully supported
-
manual control takes full priority over automatic camera
-
if the player is moving and they haven't exerted control over the camera in a while, the automatic camera will take over
-
option to revert to automatic control by pressing a button
-
-
procedural camera is designed so the player is never required to manually control, which can be especially difficult on a controller
-
mouse and controller default settings distinguished based on player feedback
-
enters "plane mode"to bypass problematic camera clamps that make flying up jarring
-
juggles multiple states with different priority levels
-
changes FOV based on player's speed
BP_PlayerCamera
This shows the camera at the highest level, without getting into the many functions and grouped nodes within.
All of this logic was written by me, with the exception of camera FOV contributions from programmer Joanna Mijares. Though it's mostly written by me I have to give thanks to all the programming and design team members that helped me debug and dream up solutions to our many 3-dimensional math problems.
Flying Straight Up with "Plane Mode"
Before
After
Camera Look and Recentering
Wall Riding
Player and Board Transparency
Dealing With Board Occlusion
- used material functions to easily apply to all necessary materials
Time Trials
I rapidly prototyped and supported this system as it grew more popular with playtesters and became more important. I did my best to work with other programmers as they expanded the system and communicated often with the Level Designers, who interacted with it almost every time they touched the project. I gained experience with Unreal's Sequencer, working within Level Instances, and working with Level partitioning in our open world.
Level design by and recording courtesy of www.coreyyoung.dev/
Trial design and features:
-
Pass through blue rings in the correct order
-
Rings give feedback with instant success or failure
-
Ability to instantly reset
-
Ability to hook up a sequence asset to play on the first-time start up
-
Powerup-trials created to introduce new abilities to the player
-
these trials temporarily give a player an ability to use during the trial
-
successful completion of the trial under the star time spawns in a pickup that permanently unlocks the ability
-
Bug Reporting
I'm proud to say I was the most active bug reporter on the team with 27 bugs documented over the course of
the project, more than twice as much as the next team member.
With each bug I made sure to meet the requirements which included:
-
expected behavior
-
reproduction instructions
-
video showing the bug
-
date and time
-
build number (when applicable)
-
scene name (when applicable)
Accessible Design and Programming
While my main responsibilities were technical, I also worked to move things forward on the accessible design side
of things:
-
Programmed the infinite boost assist mode feature that ended up becoming a useful dev tool
- Influenced programming workflow to include exposing relevant variables in inspector for easy editing in development and potential to expose to the player in the future
- Simplified controls and reduced unnecessary motor requirements
- ex: going max speed used to require holding the boost AND throttle buttons, I advocated for and implemented the removal of that requirement. Players only need to hold boost to go to max speed.
- Researched and implemented motion-sickness reducing features