Personal blog of Elijs 'X2Eliah' Dima

Stop forcing me to do precision jumps in first person

This is a general issue, but it was caused by one game, and one game only. A game that it pretty damn good and would have been great, if it had not insisted in making an absolute travesty into its main “puzzle-solving” mechanic. A game that is taking a brilliant, clever concept and shooting itself in the foot by making the player repeat the same sequence 10s of times. A game called Quantum Conundrum – and a game that might as well have Diablo itself laughing at player frustration behind the cheery art style. Obviously, I’m talking about jump sequences from first-person perspective. They are awful on their own, for reasons I’m about to rant about, but in this game, they are further compounded by the lack of proper savegame functionality – there are only checkpoints, and there are frequent jumping-puzzle sequences that rely on multiple successive perfectly-executed jumps to progress.

For starters, here’s why jumping in first person sucks (and don’t worry, the constructive part of this rantsy criticism comes a few paragraphs downwards).

First off – there’s no sense of your own (your character’s) dimensions. What the player has is just a camera viewport set at a fixed height above the surface level. There are no real arms – even the first person games that do model arms or weapons held by arms don’t actually let those arms influence movement or collision – try face-grinding a wall or hooking an arm around a corner in any fps – it won’t work, the arms are purely visual overlays. There are no real legs – more often than not, looking downwards you won’t see anything but the ground itself; and even if the legs were visible, on normal gameplay – looking up/sideways/forwards, the legs would not be visible anyway, leaving the issue of determining “how close to the edge am I? / how far can I do a run-up? / am I standing on this bit or that bit?”. There is absolutely no visual representation of what the game has for the player’s “collision box” (a frame around where the player model would be, responsible for detecting and responding to collisions with level geometry), so – is it even there? Is it a narrow cylinder just below the camera? Is it a box, how wide is it? All of that is rather important when the player is forced to make precision jumps, and it just isn’t there.

Next, there is little indication of character motion trajectory. Yes, by pressing W plus the jump button, you will “jump forwards”. … How can you know the distance you will jump? How can you know how high you will be at any given point of the jump? How can you know that you have used the optimum amount of run-up / starting point for that jump? All that is kinetic feedback information that is inherently missing from the display. At best, the player can learn to get a sense of how it may work, after repeated trial-and-error jumping. Problem being, by forcing the player to go through an adjustment period to get a feel for movement mechanics, most games also inadvertently force player to fail and redo tricky sequences, which – well, I don’t know about you, but for me, it is bloody annoying. That’s further compounded if the game includes an inertia of sorts. If the trajectory is dependent on initial speed, or run-up length, then that’s a whole another factor which needs to be ‘felt’ more than seen. What about allowing the wasd keys also influence the motion mid-air? And by how much? Yeah, more invisible stuff to get used to.

Another issue is the way games deal with perspective. I hope that you know the general principles of what FOV – field of view – means in videogames, and how it is pretty much unique for different combinations of monitor sizes and their distances from player’s eyes. A suboptimal field of view + monitor size-distance measure directly leads to the game’s representation of perspective and object distances at an angle being perceived as ‘unnatural’. Not wrong, and not obviously off, but just subtly different from what you’d see in real world. Normally, that is not a problem in most cases. When it comes to making millisecond-precision platforming jumps though, it is a rather prevalent issue. The less time the players have to think, to plan the jump, the more they will rely on instincts and habits of object motion – after all, there are certain assumptions everyone makes when throwing something in real-world, right? There is certain expectation about the resulting angle, speed and direction. If the game’s representation of perspective, angles and depth is different from real-world (and it frankly is), then those expectations will not prove themselves accurate in-game. Which is a long-winded way of saying that you thought you would jump to one place, but fell short / overshot in game.

And finally, and this only affects puzzle-type games, precision jumping is not in any way a puzzle mechanic! Puzzles are inherently something that you need to mentally solve, to imagine a solution for. A brain tease, if you will. Precision jumping is not that. That is purely a matter of reflex-based execution, a matter of following through an idea that has already been imagined and mentally solved. Countless times the failure to progress in Quantum Conundrum was caused not by complex design or smart tricks, but solely by failing to mechanically execute a perfectly valid solution. Over and over. At such a point, the actual puzzle has already been solved – the solution path has been thought of, the steps to fulfil it are logically known, so keeping the players locked into still trying to actually ‘do’ it is not rewarding or mentally challenging, it’s frustrating and dull. Time spent on trying to do a perfect sequence of jumps is not time spent solving a puzzle, it’s time spent struggling with controls & mechanics.

Now, I think I’ve covered the main issues of why first person platforming is an awful curse upon the world, so now we can call this post finished, and NOPE, WE ARE GOING TO BE CONSTRUCTIVE FOR A CHANGE.

Let’s consider a few amendments / propositions to the issue of fpj’s (first-person jumps). I won’t claim that they will be perfect, I won’t claim that they will seem easy to implement. Heck, maybe they won’t even stand up to scrutiny at all. But I feel that if one wants to keep using fpj’s, then these are at least stepping stones on the path of making them less bloody annoying.

Welp, for one, how about an optional third-person camera for the jumps? That way, the player could see the character model and it’s exact position in the game world. No more guessing of how far to run and how close to an edge, as it will be immediately visible. Now, of course, a third person view is not an easy thing to add – there need to be new models, new animations, and so on. But at least give the players some visibility of their legs! Okay, looking down is very suboptimal in a first-person game, but at least let there be that little concession, so that there is at least some way of knowing how far an edge can be stood on.

Which leads directly onto the next point, make the collision boxes/frames/cylinders accurate and obvious. How to do it without any character-identifying features such as legs and arms? Well that’s the thing, there should be some for exactly that reason. This also applies to level geometry – if it is modelled in 3d space, and is more than a simple bumpmapped-detail than can afford to be non-physical, then it needs to have accurate physical collision. If there is a hole, then it should not be standable-upon. If it is the top of a 10-foot pole, with about an inch’s worth of upper surface, then the player should not be able to use it as a standing-point (and nothing should use it as an intended jump-point!) if the left foot is somewhere within the closest metre, but not even actually on that inch-wide circle.

Now, how to deal with representing motion trajectories. For one, well.. there could be a very faint arc, starting right from the character always shown on the display, telling what the expected trajectory would be if the player jumped. Of course, it would have to be disable-able, for when players do get the sense of how motions work in this particular game. Alternatively, a ‘draw a solution’ mechanic that allows the players to plot out a plan of their solution as a full progression trajectory – the game evaluates it, and if it is correct, then it’s accepted and automatically corrected, smoothed for the game’s own mechanics, and the player can use that as a kinetic assistance reference (even better if the game auto-fixed the player’s moves whilst doing that trajectory to avoid the still-present problem of actually executing a finished plan). Again, should be optional, and only present as a mechanic for aiding the execution of the solution, not the creation of solution. Or, heck, just have the solution paths already in the game – invisible, of course – and if the player seems to be following them (which is likely if the puzzle design is one that only really has one way of solving it, as is the case with most jump-precision-dependent puzzles), then silently and slightly aid the jumps to land on viable surface targets – not so much to ruin the feel of player control, but just enough to avoid pixel-precision mistakes.

Or, finally, and this is the hardest potential solution to implement at all, just plain don’t use precision jumps as your puzzle mechanic. I know that Quantum Conundrum’s developer left the Portal team to work on something different, and that Portal had much more playtesting and dev resource time, but even so, the fact is, Portal was better in the sense that it had something else to avoid many cases of precision jumps. Large jump-like motions were handled by automatic trampoline-like devices (aerial faith plates for those who’ve played Portal 2), that launched the player across a known trajectory with a fixed end-point. The portal-placing ability meant that instead of jumping, one could go around. And most importantly, puzzles did not rely on pure jumping precision so much – it was much more about creating a path in concept, not in execution. It didn’t matter how precisely one landed the actual portal on a surface – for tricky areas, the portals aligned and straightened themselves. For cases with insta-death endless pits (or acid pools, take your pick), there was a reasonable leeway in terms of stand-able surface size to just allow for imprecise player inputs. For cases where precise jumping was needed, there was either an alternate way or at the very least a safe nonlethal fail-case, in addition to which there was a proper savegame mechanic that allowed players to save after each successful jump fragment they accomplished, instead of being locked to arbitrary checkpoints that are of no help in really lengthy sequences.

I know that this is not as constructive as it should have been. I did intend to come up with better ideas when I started to write down my thoughts. However, if I’ve realized anything by writing all of this, it’s that first-person precision jumping really is an abominable, horrible, awful puzzle mechanic that by all rights should never be even thought of as a valid puzzle mechanic – because it isn’t and it doesn’t work in first person at all. Want jumping “puzzles”? Great – a third person platformer it is. Want a first-person puzzler? Also great – design puzzles and mechanics that don’t rely on precision jumps. But do NOT mix the two – it will only make your players frustrated and annoying while they would be supposed to enjoy your game.

~X2-Eliah would have taken some pictures to break up the text, but is utterly sick of games not having a reasonably findable screenshot folder. And no, pics on steam cloud do not bloody count. Also, he promises to make the next post something less rant-like.

Post yer opinions

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s