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.

The Common Pickup

The development of Aimless has had a few interesting turns!

We've had a lot of discussions the past week or two and many ideas have come into play.  First and foremost at the top of our list of things to do is to squash some of the larger bugs our game had at the last testing period.  After that, though, we'll be working on concepts that should move the game forward in new and interesting ways.  Energy pickups is one of the ideas I presented.

Energy Pickups: Resource management is scheduled for implementation and it's taking the form of energy.  It has a number of values to us as designers such as way markers that show the player progress (in the form of charging points), variable challenge that can come from making charging points further away, and critical decision making.

Something that our game was lacking, however, was a low cost pickup.  You can see these in quite a few platforming games, such as the coins in Mario or the rings in Sonic.  They serve a few purposes, such as guiding the player's attention or creating challenges for the player to opt into.  With the addition of energy pickups we have a tool that can help with balance, challenge, and motivation!

Finding the Fun

Our small public testing event on October 19th went very well!  It was great to see so many people interested in our game and giving it as much time as they did!  The feedback that we got was very interesting.  From people's responses we can see that there is a strong fun factor in experimenting with Drone Abilities.  A lot of people also mentioned they enjoyed the mixing of abilities, which is something that we were aiming for.
The testing event also helped us to nail down some of our production methodology.  We'll be doing a lot more testing of level concepts before having the artists create assets for the levels.  Before the next testing event, we hope to be rid all of the bugs that were in this version.  The programmers will have to wear many hats as they'll be designing levels, creating mechanics, and removing bugs.

Efficiency and Democracy

As the software lead, I have the responsibility to concern myself over major choices in both how we design and our methods of development.  When a choice arises that has many differences it results in a swathe of positives and negatives that need to be weighed.  I must be both informed and democratic to ensure that both the decision is sound and that the members of my team are comfortable with the choice.  At times there will be a point when a team member is not in agreement, as is to be expected in any effort.  At such time I must walk the fine line between democracy and efficiency.  While the opinion may be valid and may even be the better choice, in some situations it is less efficient to keep that discussion going while other discussions are being put on hold.  Even more so when a change would require an overhaul.

This seems to be a skill that requires experience.  I expect that I'll become more comfortable with these kinds of decisions as I gain experience with them.

Giving Life to Someone Else's Imagination

It's challenging enough to try and lay out all of the systems and anticipate future challenges when working on a solo project.  It's much harder when the concept is passed down to you.  This is not the first time that I've had to take someone else's idea and make it a reality.  My duty at my summer internship was basically to make a set of tools that would expedite the team's development.  These were processes that I had never touched and knew near to nothing about.

There is a substantial difference, however, between developing from someone else's plan and planning from someone's idea.  There's much less ground to cling to.  Much more possibility that I'll wander off of the originally conceived concept and let the game fall into a new and unintended direction.

I've asked the design lead to examine my time line.  I want to be sure that everything that needs to be tested in this version makes it in, and that we're not spending time on conceptual mechanics that are conceptually already broken.

So far I'm very appreciative of the team we've gathered.  Everyone is interested and willing to put effort into the project.  I'm excitedly anticipating the progression of this game into something really amazing.