28.jul.2016


Demo version 0.6.5.7 is out: download here.


Lately I've been working on the enemies AI. It's a simple state machine and the enemy is able to punch, jump and stand up.
A hit to the head, if strong enough, is enough to knock them out.


This is my first fight againt the AI.

28.jan.2016


Demo version 0.6.4 is out: download here.



15.jan.2016


I think I have a new philosophy: If it takes me more than 30 seconds, it's too hard

The logic for this is very simple. I've been playing this game for 2 years now, if i'm having troubles making the character do some action, how are new players goign to manage at all!

Level 5 was a big problem. Too much to do, you need very good control, and to be honest not a very good incentive (clean a kitchen). So yeah, it had to go. Now it's just 2 challenges, one very easy, the other one medium; that once you know the solution it's gonna take some fiddling but you should feel good when solved.


Demo version 0.6.2 is out: download here.

14.jan.2016


I'm not completely sure about today's changes. Testing with the new demo (v0.6.2) will have to show the final conclusion.

The problem with level 4 was mainly that it was hard to move around, since this was the first time the player has to move their character, so:

* Tutorial was slightly improved.

* A vacuum tunnel was added to avoid the player the trouble of too much displacement.

* Teh entrance to the "pro" area was widened, and the room shrank to make movement easier.




Remember that you can download the v0.6.1 demo at: here.

12.jan.2016


Today it was the level's 3 turn to get some small polishing to make the objetive and control clearer.

The main idea is that you should be able to look at the picture a tell how the machine works. So:

* A red cable links the button to the marker.

* The marker is now bigger and clearer to point out the current active color.

* The arrows were made bigger to tell the player what each pedal does.




Remember that you can download the new demo: here.

11.jan.2016


Level design progress:


Based on some feedback, I've been working on the first and second level.
The second level had a few problems:

* The wording of the mission briefing made people believe that they had to get out of the pod. This was fixed not only by rewriting it but by attaching the character with a seat bealt to the pod.

* The pod was simplified by removing the controls from the outside of the pod, into a separate deattached panel. Since the original configuration seemed like the pod was actually closing rather than opening.

* Some coloring relations were set up to let the player know what controls work together.

* The pedal use to be too close to the hand, and somewhat pushable by it. Now was moved to the bottom of the pod, the hand can no longer reached it (by a significant distant) and the fact that you have to use your foot should be pretty obvious now.




Remember that you can download the new demo: here.

07.jan.2016


Happy new Year!

I've been working on a new demo, with 6 new levels.
Actually the first two are pretty much the same in a new setting, but the other 4 are new based on some feedback I've received from testers.
The biggest difference right now is that the game begins in space, which means that gravity is no longer an issue as the user in getting used to player control.
I truly believe this will make the player more comfortable with how the character moves before the complicated levels come.

On a different note, I've added a few details, like "Pro tokens", which are placed in difficult locations and are optional for the players that want to show how well they can manoeuvre in the levels. Before there was no motivation to take the high road.

You can download the new demo: here.



26.sep.2015


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.



21.sep.2015


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)

06.ago.2015


The early build is now available and I'm encouraging anyone to send me feedback!

You can download the demo: here.


Remember to follow me on twitter @stochasticlints for updates.



11.jul.2015


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.



13.jun.2015


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.

23.may.2015


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.

09.may.2015


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.

01.apr.2015

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:

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

Cons:
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.

13.oct.2014

This is the evolution of my character, from the beginning of the project to its current state.



Cross-posted on my GameDev journal.

10.oct.2014

The evolution of level 1.



Cross-posted on my GameDev journal.