K E L V I N

T U

A third-person-shooter, rogue, tower-defence game set on the back of a giant sea turtle.

Quiver Game Developer’s Guild - A Game Dev Incubator (2024)
Role: Lead Technical/Systems Designer
Engine: Unreal

Video produced by Liam Chen, one of our Unreal devs

For personal reasons, I've decided to step away from this project. However, the rest of the team is still moving forward with it!
Check them out at Rise and Brine Games !

STARTING WITH RESTRICTIONS

Quivers incubator was the first game dev event that I had spent money on other than Global Game Jams and Full indie summit. I was in a situation where I had to be fairly careful about my finances, but Dotty, a new friend that I had made at GGJ that year, was organizing teams for it and I was feeling in a rut and had a craving for something different.

I had a chance to meet most of my teammates before the official start of the incubator. I was already in designer mode. I started by asking everyone about their deepest desires in life, hoping to derive some core values that I can use to align the team and design with. This unfortunately didn’t yield anything too useful…

maybe it’s the time…
or perhaps I could change how I word my questions next time?...

We did, however, also talk about what skills were on the team and what kind of games would be practical. We had two programmers who were really strong in Unreal so that was set. For art we had one 2D Artist and one 3D artist but both were fairly inexperienced in and unenthused about the prospect of doing animation. With that in mind I steered the team towards an ocean theme. Sea critters like fish had less complicated limbs and they wouldn’t need to make contact with the ground, making them easier to animate and made it easier to fudge in case we needed to make adjustments to game mechanics.

Animation and model samples prepared by Ker Hu

A DESIGNER'S CONFLICT

After a few brainstorming sessions the team settled on having a third-person-shooter(TPS), tower-defence(TD) game set on the back of a giant turtle. I had some serious reservations, finding it difficult to see how the setting would support the expected features of a TPS or TD game. After some conversations with individual team members I came to realize that they saw the setting as mostly ornamental, which troubled me because it directly conflicts with some of my core design values. The feeling of unease was compounded as game mechanics were decided without a design strategy in place. For example, it was decided that the game would take place on a hex grid because it's a shape associated with turtle shells. This was fine for aesthetics, but from a games mechanics perspective this decision felt arbitrary and unjustified.

ADAPTING

The whole point of being a context-driven designer is the ability to design anything. I also don’t believe in “bad” ideas. With the generous support from my team and the guidance of some very kind mentors, I worked through most of my feelings for week two and made a significant shift in how I approached the project. I abandoned the setting as a mechanical constraint altogether and focused instead on the relationship between TPS and TD systems. I made lists of all the elements in a TPS game, all the elements in a TD game, and all the mechanics that already existed in the prototype, then systematically looked for ways they could fit together.

INTRODUCING ROGUE ELEMENTS

A recurring concern was that TD players often fell into repetitive strategic patterns and there was a desire on the team to try and break them out of it. I started to consider roguelike elements, but I was a little hesitant at first because I could still remember a time when rogue-like was the first thing on the board at every game dev brainstorm. There were some pretty compelling opportunities though. TD and Rogue share a similar action-buy phase structure so there are some synergies there. Rogue elements could also affect the playable character’s attributes, indirectly bridging some of the more abstract elements between TPS and TD parts. That’s three decent opportunities to exploit, which was enough to move forward with.

Animation and model samples prepared by Ker Hu

DESIGNING ASPER

When it came to designing the playable character I outlined some specific design goals to help ensure synergy with the TD ,TPS, and Rogue elements of the project. My initial inspiration was a nostalgia of playing the ranger class in the original Phantasy Star Online (PSO), recalling the heavy and rhythmic feel of the attacking mechanics and deliberate movement to corral monsters to maximize area of effect damage.

1. Dynamic Primary Ability:
   Design the primary ability with adjustable attributes that significantly impact playstyles, giving more weight to decisions made during the rogue-style buy phases.
2. Mob management:
   Ensure players can influence monster positions relative to tower locations.
3. Stimulate Flow:
   Design actions that promote a sense of rhythm and allow for skillful, moment-to-moment decision-making. This will be important because players will be using the same actions over and over again, albeit a little different between waves.
4. Risk and Reward
   Allow for oscillations between safety and danger, enabling players to push their luck, this being a critical characteristic of rogue-style games.

To manifest the feel of PSO combat flow in a TPS format I looked to Splatoon’s Blaster weapon type, as many of its built in characteristics were congruent to what was needed.

1. The AoE-sweet spot dynamics give players interesting moment-to-moment decision-making and allow them to build their skills in ways that can be more or less dependent on aim.
2. The distant radial AOE allows players to push monsters in various directions from a distance.
3. Its slow fire rate promotes a natural rhythm of shots and recovery time.
4. The addition of a mana/stamina system and a sprint mechanic:
   1. Connects attacks and movement, further pushing the danger-safety dynamic while introducing complexities to the skill tree.
   2. Creates an opportunity for a non-combat tower that provides stamina and a static support points on the map, creating topological interest.
   3. Adds an additional skill line for players to upgrade.

UNFINISHED IDEAS FOR TOWER DYNAMICS

When I stepped away from the project, I felt the interaction between the player character and towers was underdeveloped. Some ideas from the original draft, such as giving each tower a unique interaction with the player's main attack, might have worked, but the UI/UX wasn’t advanced enough to confirm them either way. I had considered introducing a command ray mechanic (inspired by Zelda: Wind Waker and Twilight Princess) to let players control towers, turning it into a core mechanic rather than isolated actions. This could also allow for future expansions, like controlling monsters or combining player attributes with towers. However, this is now up to the next designer, and I wish them the best of luck!