Translating Velocity Vectors

One of the interesting concepts we've had to play with is translating motion from one direction to another.  We've used this for a couple of different concepts, such as rotating a glider or allowing for midair adjustments.

The basic premise is that velocity should be maintained through the movement while allowing it to be affected by outside forces such as gravity and collision.  The equation is pretty interesting.

Take your current velocity vector and add to that the vector that you're moving towards, then normalize it.  This will give you a normalized vector that is between the two original vectors.  After that, multiply the new vector by the old velocity vector's magnitude, so that no velocity is lost.  This results in very satisfactory gliding physics, as when you pull up on the glider, you only lose velocity due to gravity and air drag.

Heuristics in Puzzle Games

One of the issues plaguing our Aim< is telling the player how close they are, or have gotten, to the goal.  With linear map design this is pretty easy.  How far from the start am I?  How close is the goal?  If the player can see those things, then they have both a direction and a measure.  The problem comes in if you have an open level design.

If the player is given a wide area and made to search for progress, they may not know what progress even looks like.  If they can see a path but not the result of that path, they'd be wary about wasting their time.  The player might then choose instead to look around for a more defined path, resulting in frustration if one can't be found.

The player is also faced with solving a puzzle to progress.  The problem with this is that attempts to solve the puzzle will currently cost the player resources.  These resources can be found throughout the map, which we've conceived of for a bread-crumb concept, but they are finite.  This results in a negative experience for players who are experimenting or who are trying to solve the puzzle in a way that we might not be allowing.  Earlier in our play-testing, we found that experimentation was a key source of fun for the players.  If it's fun to experiment, then it shouldn't be punished.

Aim< is a puzzle-platform game, and we're dealing with opposing concepts.  The game cannot easily be made explorative in movement if getting to a location is the primary heuristic.  The game cannot easily be made explorative in puzzle-solving if the player is punished for conducting experiments.

To solve the platforming problem either:
1) Make the maps linear
-OR-
2) Change the goal from movement to some other heuristic

To solve the puzzle-solving problem we could:
1) Remove the punishment while retaining sensible limitations
-OR-
2) Remove puzzle-solving near completely turning the game into more of a platformer
-OR-
3) Make it quick and easy for the player to fail and get back into the game (Example: Super Meat Boy)

There may be other solutions to these problems.  These are what I've come up with.

My personal preference after consideration is for linear maps and limited, but not punishing, puzzle-solving capabilities as these have the least amount of pivot for our game.

Making failure quick and easy would also help with our game's pace, which is currently too slow and methodical, so that might be the better choice as it has multiple positives.