Kinetic Driver Manticore

Narrative/Level Designer

A VR mecha game where you play as a mercenary pilot inside a Kinetic Driver cockpit. Learn the challenging and tactile controls and maneuver your way through a destroyed moon colony to steal data and eliminate your enemies.

  • Unreal

  • 12 Person Team

  • Fall 2024 - Spring 2025

  • Releasing soon

The Game

Design Pillars:

  • Believable and physical

    • Challenging controls that make you feel like a pilot in a jury-rigged mech cockpit

  • Weighty and impactful

    • The mech and its controls feel heavy and slow, but have a huge impact on the environment

  • Deliberate and methodical

    • The player makes moment-to-moment choices that need to be thought through for best effect

  • Rewarding for effort

    • If the player takes the time to learn the controls and their timing, they can do especially well in the game.

Kinetic Driver Manticore was my final student project at DigiPen, made with my fellow students in team Powered Hippo Industries. We wanted to learn VR development, a skill that none of us had any experience in. While I don’t believe the final product lived up to my initial hopes due to several different factors, I’m proud of the game we made.

  • Our tech team was incredible and achieved great things during this project, but unfortunately they were fighting an uphill battle against the triple threat of Unreal, VR, and Perforce.

    We spent much more of our development time working on the game’s core mechanics, which we expected would be quick and easy, and this slowed the project down much more than we would have liked.

  • Because this was a VR-only game, we ran into the issue of limited VR hardware to test on as well as VR-capable computers to develop with. Many of us had no way to playtest in VR, which meant a lot of bottlenecking during development.

    We ended up partially solving this problem by adding some debug controls to play the game directly in the Unreal editor, although a recurring question we asked each other was “Is this not working because it’s not in VR or because it just doesn’t work?”

My Role

Responsibilities:

  • Wrote an initial world bible to inform the theming and visual design of the level

  • Mapped the level overview and built several chunks of the main level districts

  • Sourced and chose game assets for visual and narrative consistency

  • Implemented core gameplay loop with data terminals and hacking interaction

I filled the role of Narrative and Level Designer on the team, along with one other Narrative Designer and two other Level Designers. I took more of a lead role on the game’s narrative, drafting a lot of the early concepts for the game’s story as well as the visual identity and thematic elements of the world. I also chose and sourced many of the game’s models out of available items from the Fab marketplace and other free sources online.

  • Many of our team are huge fans of the mecha genre, myself included, so naturally we all had a lot of thoughts about what kind of mech we would be building for the game. We filled a Discord channel with reference images taken from our favorite media, and spend way too many hours debating what kinds of weapons we should include and how screens would work.

    I was more of a fan of more humanoid and agile mechs such as ones from the Gundam and Zone of the Enders series, but admitted that these would be much harder to recreate in game. Eventually we settled on a look and feel inspired by Steel Battalion, one of the game’s original inspirations, and many early BattleTech designs.

  • As something akin to the game’s narrative lead, one of the most disheartening pieces of feedback I heard over and over again was that the game’s story didn’t matter and the only thing players wanted to do was blow stuff up. This, combined with our constant need to reduce scope, meant that almost all of my narrative design ended up being cut from the game.

    I tried to keep as much of the original plans in tact, at least in thematic ways, but this project was a real lesson in team priorities and the needs of different projects.

  • Our team had many designers, almost all of which overlapped in specialties, and I primarily worked with other level and narrative designers who all wanted to leave their mark on the game. We had to figure out how to divide the work in ways where we wouldn’t be fighting over who got to do what.

    For the final form of our game’s level, we settled on a solution that involved us each claiming a chunk of the level for ourselves to do with as we wanted. We then split up the additional work based on our personal interests, with me taking ownership of the set dressing the other two level designers taking on the blockouts and enemy placements respectively.

  • World Bible

    At the beginning of this project, I wrote an extensive world bible containing information about the game environment, history, and culture. The original intention was for this to inform the story of the game and be incorporated in many ways directly into gameplay. Sadly, this was a mostly unrealized dream and very overscoped.

    Regardless, the layout of the Luna IV environment and the overall tone and visual style of the game were still based on my descriptions. The world bible, while not fully implemented, was still the biggest influence on what the final game looked and felt like.

    View World Bible

  • Narrative Encounters

    In addition to the world bible itself, I wrote a list of what I alled “narrative encounters” for the game’s original three act mission structure: locations or zones designed to communicate the game world’s history and culture through environmental storytelling. These narrative encounters were meant to be carefully placed between combat encounters to ensure the player had time to actually look at the environment without needing to focus on enemies or controls.

    These encounters were largely scrapped in our attempts to scope down the game, which included removing the linear mission structure entirely in favor of a simpler extraction-style sandbox. However, several of them ended up remaining in the new level.

    View Narrative Encounters

  • Blueprints and Version Control

    Because our team was made up of a mix of programmers and designers with different levels of experience with coding, we worked largely in Unreal blueprints. This proved a challenge with the limitations of Perforce, our version control of choice, as a lot of code was contained in single blueprints such as the Manticore mech itself that could only be checked out by one person at a time.

    For the parts of the game that I implemented such as the terminal objectives and the hacking computer, I tried to separate as much as I could from the large central blueprints and work in self contained actors. This ended up working quite well, and I was able to avoid stepping on anyone’s toes while working.

  • Cockpit Layout

    Our team decided from the start of the project that the player experience of being in a mech cockpit was the most important aspect of our game, so a lot of work went into the design of the cockpit itself. Being the player’s only means of interfacing with the game, many different controls were within arms reach. I also wanted to tell a story about the pilot and the mech themselves, so I added some characterizing decorations to the cockpit in places that wouldn’t interfere with the controls.

    To facilitate our discussions about how to layout the cockpit controls, we constructed a paper prototype out of cardboard and office supplies. We could then move elements around in this makeshift cockpit to see how they felt to reach for, and had a lot of fun acting out our ideal mech control scenarios.