dan pruzina

After figuring out the way that the player will unlock new abilities in The Seeker, I had to take a fresh look at my placeholder system for selecting abilities (using the d-pad to cycle through them) and due to the fast-paced ability switching that will need to happen, I landed on the idea of using a radial menu.

That was two weeks ago.

I’ve tackled some interesting geometry problems already in this project (which I’ll probably write down later just so I remember how I solved them) but this one was a doozy. After scouring the web for ready-made radial menu solutions, I found none that avoided putting a cursor on the screen and comparing its location to the center of the menu to get an angle. I wanted a “real” radial menu – like in The Witcher 3, where you move the mouse or hold a stick on the gamepad and a selector rotates. With no starting point except some working knowledge of how rotations and input work, I went through many (many, many) potential solutions that completely flopped until I arrived at this.

Its appearance will probably change a lot but I’m happy with the way that gamepad and mouse movement are apparently identical in moving the selector around. The player just holds a button, moves the selector and lets go of the button to select an ability. I’ll be going into more detail of how it works in a later devlog – for my future self and other devs. 🙂

 

This devlog is all about losing. It’s not necessary in every game, but you’ll find it in different forms almost everywhere you look. Maybe you don’t have “lives” in a game, but mistakes force you back to the beginning of the level – so you lose time. Maybe you did pretty well on a level, then a scoreboard appears revealing that thousands of players completed that level faster.

This I-could-have-done-better feeling is a vital part of providing rewarding goals in games: the presence of the risk of loss is what gives victory value. The greater the risk and/or cost of losing, the bigger the high will be when a player overcomes a challenge. But because greater risk also gives way to a higher loss rate, increasing it will inevitably frustrate players who don’t learn as quickly as expected or just aren’t good at your type of game.

Of course many games have player-controlled difficulty levels to help scale challenges to their skill level. Puzzle games present a problem in this area; without time limits, puzzles tend to have fixed difficulty levels. A more skilled player might solve one faster than another, but generally everyone should be able to figure them out – especially in games where puzzles drive the narrative. Portal is a great testimony to the fact that having loss scenarios in puzzle games can and does work – as long as challenges are paced and segmented properly.

A primary goal here is avoiding the player losing and deciding that trying again is not worth it. In The Seeker, several puzzle areas have no constraints on the player dying or “failing” (losing a resource necessary to complete the puzzle) and many of them even let the player use abilities like switching between hosts and double-jumping without consuming energy. I’m essentially trying to tell the player, “Take your time, I know you can do it!”

To mitigate frustration from the only thing the player does lose in these scenarios – time – I’m shaving the cost down as much as possible. Where it makes sense, respawn chambers are placed throughout levels and linked to checkpoints. Using respawn chambers gives a way for the player to die and reset without reloading the level, saving about 5-10 seconds – and a way to show the switch mechanic before the player has access to it, as they leave their dead body and fly into the brand new one dispensed by the chamber. This also lets the player see the strangeness of their previous bodies lying all over the place, as bodies in this game are just resources.

Where it doesn’t make sense to place respawn chambers (like in abandoned areas that haven’t been modernized or areas requiring fine-tuned configurations), the player can reload the level and be placed at the most recent checkpoint. For more skill-heavy challenges like running away from bad guys or beating a time goal, this threatens gameplay flow: if someone spends 10 seconds attempting a difficult jump, for example, only to die and spend 5+ seconds reloading… that’s a huge chunk of their playtime wasted.

Until I have a solution to the reload problem, I’m just keeping scenes that’ll need to be reloaded relatively simple. How have you approached this problem? What games have you seen that do a great job of keeping reset times low? Leave a comment or let’s chat on Twitter!

Incredible proportions. Daunting geometry. Dark, dystopian structures looming on the horizon. It’s a sci-fi game! And normally as a developer I could plaster some images of distant buildings to the edges of the world and get on with building out small-scale level geometry. But in The Seeker the player has superhuman speed and strength; they’re expected to traverse huge distances and gaps, and become more and more agile as the game progresses. A common game design question rears its head: How much freedom can the player be given before it can’t be contained? In other words, what happens if the player finds a way to those cardboard imitations of buildings in the distance – or at least close enough to see that they’re just props? The illusion of immersion can be broken and the whole game can start to feel cardboard-y.

This is why most games have “bars” in them – health, stamina, magic, experience, currency, etc. As backward as it sounds, limitations are core to having fun in games. Compare a self-made millionaire to a lottery winner. Which one would you expect to talk about their money with a greater sense of accomplishment? Plus, the boundaries of a game world – whether physical edges of the map or constraints on the player’s abilities – help to focus the player on the challenges that are intended to be central to gameplay. Ideally, the player should never “win the lottery.”

In The Seeker, swapping control over people’s bodies essentially turns them into resources. While there are no “lives” for the player to spend upon death, there’s a surefire escape from death as long as another robot is in view and close enough to use the switch ability. As such, to make the player use the switch ability and keep them from going through hosts like french fries… people have to die. A lot. It might seem dark, but it affords me plenty of design opportunities for making fast-paced, risk-oriented gameplay. For example: run into a wall doing 60 miles per hour – you’re gonna die. Run out of stamina while stringing wall jumps together and fall 100 feet – dead on impact. Sprint off a building without saving some stamina to roll after falling… not pretty. But it is pretty effective! To succeed, the player must manage health, stamina, energy for switching other abilities, and of course, people’s mortal bodies. And that’s not including running from lethal enemies!

I’m definitely considering having the bad guy yell “Just see how far you can get with ONE body!” at some point.

A big part of the inspiration for The Seeker to have a focus on freedom of movement was Mirror’s Edge. It captured the sense of “actual” first-person in a way I hadn’t seen before and the feeling of leaping over huge gaps, looking down and seeing your body and the distant street level, and having a moment of sheer panic was one of my favorite parts of the game.

But I found I wanted a little more control over movement in Mirror’s Edge – as strange as that may sound to anyone who’s played it – especially in situations where the player has to navigate several gaps and vertical paths in succession. As much as I wanted to problem-solve my way through these scenarios, my first plan (bashing the jump button and moving toward my destination) usually worked. And this makes sense: save for a few tricky escape-room-style scenarios, Mirror’s Edge is not a puzzle game. I started pondering methods to add to the player’s control of movement to incorporate situations where, for example, they might need a certain “jump strength” to make it over a gap – or be moving at a certain speed while jumping – or a combination of both variables.

Early attempts involved a bar indicating “jump charge.” Hold the jump button, watch the bar fill, release to jump with that much “charge” added to a base jump strength variable. It doesn’t make much sense for charging a jump to take very long, though, so I found myself just charging the jump for longer than I needed and only jumping with 100% charge. My eyes were also never on the actual bar; they were on wherever I wanted to go, of course! At this point the feature was useless, but I left it that way for quite a while – until a level included a gap that required a certain jump charge, and what was intended to be easy became a point of frustration for me as a player. In this instance, jumping with too much charge would cause me to hit the ceiling and lose forward momentum, and jumping with not enough charge wouldn’t provide enough momentum to clear the gap.

Even after dividing the jump bar into thirds to help make charge amount more obvious and placing it near the center of the screen, I was still struggling to hit the percentages of jump charge that I wanted. This was around the time I began working on sound design and replacing prototype sounds with ones I liked. Using short ticking sounds that play when a “cell” on the jump bar is filled and rise in pitch with overall jump charge virtually solved the problem. The goal is to train the player to get used to the connection between the blips of sound and jump charge before they need to use less than a fully-charged jump, so when the time comes they (hopefully) know what to do.