Character editor is done.

I used some of the screens from the level editor to create a character editor. Basically every character is an object, and thus created in the same way. They have some special properties like the ability to grab stuff, or to have an IK mover icon at the end, but these were minor modifications.


I've working on a level editor.
A simpler version of this editor will be included in the final game so people can create and share their challenges.

It took me a lot longer that I estimated, but I have everything in place now so hopefully I can start focusing on level design.

It is divided in several "screens". The Image Editor lets you load files, set their UV coords, set origin, and if they are animated sprites you can attach them animations.

After an image is prepared, you can load them on the back/fore ground, or use them in the Part Editor to create a box2d part:

The Part Editor asigns physical parts to an image. Basically 1 image = 1 object. You can also add shapes by using circles, rectangles and polygons; each with their own physical properties.

Then come the Object Editor which puts together the parts to create links/trees of physical parts joined by revolute/prismatic joints.

And there's also de physics editor which, after loading a background image, let's you draw the global static physics of the level for the character to collide with:

Extra screens:

Character positioner (lets you decide where is there character going to start and in the initial position).
Sensor Editor (lets you put sensor all around the level that trigger events)
Victory editor (lets you choose the victory conditions for the level)


Finally an early build is now available and I'm encouraging anyone to send me feedback on reddit/r/gamedev!

Remember to follow me on twitter @stochasticlints for updates.


An alpha demo is on the way!
Before the end of the month I will publish a demo for you to try out.

Remember to follow me on twitter @stochasticlints for updates.


I've been working on adding physical projections of what is going to happen.

In the previous version of The Most Poser Heroes, there was a lot of "guessing" of what was going to happen. You had to really understand the behavior of the physical bodies to move your character in a coherent way. This was something that even professional animators had problems with (since they were not used to physics interfering in their work).

This used to be the game cycle:

  1. Move one or more limbs (one by one).
  2. Press play to see the results of your changes.
  3. Stop the movie.
  4. Go back to the frame you were working on.
  5. Back to step (1).
All these steps made the game VERY tedious. There were so many places you could go wrong: wrong movement (very common), forget to press play to actually see the simulation, forgetting to go back to the frame you were working on (this was very common when all the last frames look the same, for example, when the character is stucked; so the player assumes he is working at the right time, but actually he is at the end of the animation).

And considering that most players completely failed at Step (1), this cycle repeated a lot of times.

So here come the changes I've made so far:

These changes prevent some mistakes, but the cycle was only slightly smaller. That is, step (4) was eliminated and step (1) was simplified. Nothing else.

So here comes the most drastic change ever. Physical projections:

You can see that every time you move a limb, the simulation is run behind and a silhouette shows you what will happen!
So now, even if you have no idea what you are doing, you can see if it's working, and retry very easily.

So the current cycle is:
  1. Move the entire limb using the IK.
  2. Go back to (1)

Much better**! Right? Are you happy? Because I AM! Time for chocolate.

** I haven't tested this with actual users yet... so maybe I'm celebrating too early.

Cross-posted on my GameDev journal.


I'm currently trying things to make the game easier on the new player, without sacrificing the original vision.
Besides modifying the first levels, I have added a few control related improvements.

Inverse kinematics:

I slowed it down on purpose to give the user more control.

This is something that several people asked me to add. So now you can control the whole arm through IK, or control each individual part as before if you want more control.
IK is usually not an easy subject, but for my case I was able to approach it in the simplest way, using Cyclic Coordinate Descent. Using this awesome article by Ryan Juckett (includes explanation, drawing, math and code!) it took me very few adjustments to make it work.

The only thing I had to add was restrictions to the joints, since the wrist of my character is not supposed to do a 360 rotation.

To make it work, I modified Juckets' Bone_2D_CCD struct to:

struct Bone_2D_CCD
	double x;     
	double y;     
	double angle; 
	bool hasLimits;  // new
	double minAngle; // new
	double maxAngle; // new
And fed this new information to the algorithm.
Inside the IK function, after these rotAng variable is computed (these lines):

double rotAng = acos( max(-1.0, min(1.0,cosRotAng) ) );
if( sinRotAng < 0.0 )
	rotAng = -rotAng;
I added a code to truncate the rotAng variable:

if (bones[boneIdx].hasLimits)
	bool limitExceeded = false;
	if (rotAng > 0 && bones[boneIdx].angle + rotAng > bones[boneIdx].maxAngle) // truncate if exceeds maxAngle
		rotAng = bones[boneIdx].maxAngle - bones[boneIdx].angle;
		limitExceeded = true;
	else if (rotAng < 0 && bones[boneIdx].angle + rotAng < bones[boneIdx].minAngle) // truncate if exceeds minAngle
		rotAng = bones[boneIdx].minAngle - bones[boneIdx].angle;
		limitExceeded = true;

	if (limitExceeded) // Recompute the newly truncated angle.
		cosRotAng = cos(rotAng);
		sinRotAng = sin(rotAng);
And although I'm not super proud to bring trigonometric functions to an "all linear algebra" solution, I don't know enough math to do it properly, and this was a case of not needing to optimize things that do not slow down your game (this code follows the action of the much-slower user).

Cross-posted on my GameDev journal.


It has come to my attention that the first level is still too hard.
This is the current first level:

So I've been trying to come up with a way to ease the mechanics to the player. One suggestion I've got is to reduce the number of limbs/joints, so it is easier to control with less degrees of freedom.
That is actually an idea I liked, so I came up with three introductory scenes, in which your character is fixed to a position, and you only control the arm, then the arm and the leg, and finally the arm and the leg with a loose body.

(programmer art)

To give context to the inability to move, the character begins the game strapped on a helicopter sit, before being dropped to the mission. The character has to push some buttons, let itself free, and later jump into the void.

Cross-posted on my GameDev journal.


So... about my hud. This is my current hud design (graphics not final).

I made it based on YouTube's control bar...

mixed with Adobe Flash's time line...

Although functional, a lot of people are having trouble grasping it. Programmers and animators have very little issues, but "common" people do not understand it easily, making the game pretty much impossible for them.

These are the main problems with the hud that I have seen when playtesting with strangers:

1. The concept of timeline is not intuitive:
1.1 People have problems going backwards and forwards in the animation
1.2 They can't realize that more space = more time.
1.3 They make their changes in a wrong place, when they try to add new keyframes.

2. The concept of interpolating between keyframes is definetely not understood.
2.1 People want their pose at this moment, and don't change the past!
2.2 Adding a frame to preserve the past is not understood.

So this is the idea i'm playing with right now:

The idea:
- I think users will be more familiar with a "film" concept, than a timeline.
- When you press play, the film slowly rolls to the left as the movie progresses.
- Every pose (frame) is held for X miliseconds and changes (almost) inmediately to the next.
- So no interpolation concept.
- The film starts very small (one or two poses) and the user can add poses as he needs them, so he knows how big it is.
- The frames are added only to the back, inmediately next to the last frame.
- They incrementally create the film form start to finish.
- No mistakes on where to add a frame. You are always working on the final part of the movie...

It becomes closer to a "list of instructions" that the character will try to imitate.

In theory:

Easier to visualize.
Easier to teach.
Harder to make mistakes.
No interpolation required.

Loses control and granularity. Since now each frame is bigger, you will not have as much control as you would with individual frames on a timeline.
More rigid, less liberties.

I realize that this approach take away A LOT of liberties from the player. I am not convinced if it's worth it. I have to implement it, and see if it works as i hope it will. I have to think if i like to play it this way.

I'll report again when i have results.

Cross-posted on my GameDev journal.

View older entries >>