• entries
33
64
• views
46121

## Replicating a simulation with Box2d, part 3.

In the last post, I explained how to solve the box2d issue about cloning a world. It's pretty simple, fairly fast and reliable in its results.

I didn't use it. Why? Because there are some cases (like my game) that it doesn't work. And those cases happen when the game has two+ characters and one can go back to change their behaviour but the other one does exactly the same.

Let me put it in pictures.

If you have one character going back in time:

The mechanic is straight forward. If the character goes back in time and does the same movements, the result will be exactly the same, because the copied world will be the same as before.

If the character goes back in time and does something different, well, the result will be different, but that makes total sense, if you change the past you cannot expect the future to be exactly the same.

But, if you have 2 characters, let's see what happens:

Let's say character pink stays still while character blue jumps around. A possible future is generated and the pink character observes it. This is the critical part, somebody that is not causing the events but is able to see the possible future.

Now, when everything is rewound, and the pink character decides to move around, the copies will not be the same as before. Thus, the future of the blue player (that was originally observed) might change, even if the pink player never touches the blue player or its surroundings. This makes no sense in the eyes of the second player.

This is a huge issue! Imagine in Posable Heroes doing some tasks with the blue character, and then coming back to work with the pink character only to realise your blue characters timeline is altered. Since the game requires precision, this is unacceptable.

On the 4th and final post, I'll explain what I did to finally solve this issue (spoiler alert: thank you open source).

If you are interested in Posable Heroes, you can wishlist it on steam.

## Replicating a simulation with Box2d, part 2.

So, in the previous post I said the main problem about duplicating a box2d world. The worlds differ.

### Why would you want to duplicate a box2d world?

There are several reasons:

1. To replay a cool sequence.
2. To predict the future.
3. To go back in time.
4. To save the current game.
5. To send the current world to another player.

### How do you solve this?

There is a very simple way of going around the box2d issue. Instead of trying to make a copy of the original world, and hope for the best, you make two copies, and then destroy the original.

So instead of running the original world and save the copy...

You make two copies, run one and save the second one. That way, the second copy will be identical to the first one.

So the solution is: everytime you want to save the current world, you are actually destroying it and making two copies. The players will continue to play on copy number #1 (they will not realise the change) and you store copy number 2, in case you ever need to get back to that instant.

This is a very simple solution that can be applied to almost every case. My game turned out to be one of those special cases that required dipping into the source code. I'll talk about it in the next post.

If you want to know more about my game and why I had to dance around box2d cloning issues: Posable Heroes now has a steam store page.

## Replicating a simulation with Box2d, part 1.

Today I was working with a real buggy bug that has been bugging me since pretty much the beginning of development.

You see, I choose to use box2d c++ version for Posable Heroes. It's open source and pretty solid. And the best of all, it's deterministic. That is, there is no "random" on the simulated work. If you have a square and a triangle, in exaclty the same starting position, with exactly the same linear and rotation speed, then when you simulate the world, you are always going to get the same result.

Which is good! Specially for me in a game where I have to go back in time all the time.

BUT... (a big but!)... if you try to duplicate an existing world (already running), then the two worlds will not behave the same.

Here's a picture for you to understand...

If you copy from the beginning, everything works:

But if you copy once the world is already running:

This is for a very simple reason: Box2d classes do not expose everything in public. There are several values, arrays and optimizations that lie under the hood, inside the b2World and the b2Bodies. So when you grab an existing world, and try to duplicate all the elements from the value they have public, there are several things you are missing.

I found a temporal solution that I will talk about next post and that might solve this problem for some users, but that wasn't a forever solution in my case either.

If you want to know more about my game: Posable Heroes now has a steam store page.

## I'm back, and now with a Steam Store page.

Alright, I took a long hiatus because I was tired and starting to feel burnout. Now I'm back and ready to give this final push that is needed.

First thing first, I have a steam store page set up!

Which is good, now people can wishlist the game. Currently I'm at 69 whislist which is too low. I need at least x100 that, so a lot of promotion needs to happen.

The other thing that comes with the site is that now I have a shipping date: February 22nd.

It might change based on toehr releases, but I think it's a pretty good estimation for realease, and I definitely need to have finished by that date.

I thought having a site would bring a good ammount of people to visit my site, but that was not what happend (at least in my experience). I had a lot of exposure the first couple of days (around 400+ people per day) but then it fell to around 10 to 20 per day. Which is very little. Here's the graph:

The 2 spikes that you can see are some flux I managed to bring based on some reddit comments, but the wishlist number did not increase those days, so basically I didn't bring customer's eyes to the site.

Anyway. Currently I'm working on a couple of game breaking bugs that have been bothering me for years but I haven't had the chance to fix them. Wish me luck.

## Greenlight continues... and so does development.

Alright! 11 days on greenlight, and work must go on.

Today I show you a couple of characters that you will find on you animated adventure.

This is some sort of goliat/brutus minion that will get in your way. There's no way to defeat him by punching him so you better use your head in this confrontation.

This is some old master. Kill Bill style.

Yes, that's a pinpogn paddle. Yes, you will have to play ping pong against him.

[color=rgb(29,33,41)][font='Helvetica Neue']And if you would like to check the game, here the [/font][/color]greenlight link[color=rgb(29,33,41)][font='Helvetica Neue'].[/font][/color]

## First day of Greenlight

So, finally, Posable Heroes got into greenlight on monday morning.

Preparation:

I prepared my 512x512 logo, which has to be less that 1mb so some optimization had to be done. I decided on an animated logo for extra attention. But the animated portion was small (like 30%) so the weight would not be as high.
Tip: This website was very helpful to reduce the last 100kb.

I prepared my trailer:

The artist had a personal problem the last couple of weeks. I could not wait any longer for the extra levels we wanted to include, so I made them myself with parts I could pickup from other levels, and from free textures found online.

I got the soundtrack from audiojungle for 15 dollars.

I prepared the description:

Trying to use a short description at the beginning, and a main body to describe gameplay and show how the game works.

I can translate to spanish myself, and a kind person translated to russian for me. So 3 languages were supported.

And then I pressed PUBLISH.

Inmediately after submitting, (like 30 minutes after), Posable Heroes was already 6th on the recent releases list. Damn! Want an advice? Don't publish on monday mornings. Compared to it, tuesday morning has been much slower as far as new submissions goes. I had manually tracked some values on thursday and friday, and everything pointed to 1.5 new games per hour. So this was a big bump I didn't expect.

But then again, I have no idea how Grenlight's algorithm works to show the game on people's queues. Is there a fixed number of impressions? Does yes/no ratio make you game more visible? Does falling to second page matters? I don't know.

26 hours later, I'm still on first page though, on slot 29th. By the time I finish writing this entry I probably have fallen into greenlight oblivion of the second page. Traffic has already slowed down and new votes (either 'yes' or 'no') have already stopped coming in. And I'm getting around 1 vote every 30 minutes... yikes.

How is it going so far?

I had a good run on monday afternoon, reaching around 55% yes votes. But today I woke up to a very low 40% approval.
This was not unexpected, as the game is not really mainstream (nor a "gamer's game"). But I guess I did have a little bit of hope of getting a better approval ratio. Don't we all?

But I'm not down about the ratio, I am worried about how few votes (overall) I'm getting. So I need to find a way to pump those numbers up. How do games in the top 100 do it? They have like 6,000 votes! Is that organic?

I have been offered some promotion by shady marketing groups/companies. I don't want to go that route.

One curious thing: In the first 20hrs+ I had zero "Ask me later". Then, all of a sudden, 9 votes appear there in like 15 minutes. What was that about?

Anyway, on the good side, I had a good laugh with this comment:

I'm thinking what other things I could do to get attention. I saw some groups on facebook but it just seems developers voting each others project, no matter the quality of the submissions. I'm not fond of that. Is that the game we are supposed to play?.

Right now I'm preparing something and see if any website wants to say a few words about the game, although everyone says that getting greenlight coverage is very hard.

Feel free to leave me suggestion in the comments!

And if you like the game, here the greenlight link.

## Programer art vs Artist art

The last month I've been putting the new artwork into the game. Still lots of work, but it's nice to see it come together.

Last entry I was wondering about two diferent artwork style and trying to decide which one to keep. I decided to go with the cleaner looking one. The paper borders were just too much and made a mess. Although I did like the unique style it created, I decided to simplify. They say that perfection is reached when there's nothing else to take away... and those borders were something that the game could do without.

This is the progress on some of the level I've been sharing:

Level 2, before and after:

Level 12, before and after:

Level 13, before and after:

Level 3, before and after:

I'm also preparing for greenlight! Very exciting times.

## With... or without borders

Since the beginning I wanted to add clear borders to all my characters and levels. This was mainly due to this being a physics game, and I wanted no doubt about which object can collided with which object.

Since the characters takes a lot of effort to move, then the player should find no surprises about what is a floor/wall, and what is just decoration.

Unfortunately, today, assembling some new art, I realized that the white borders were just too much noise.

So I made a fast mockup to test how it would look without the borders...

What do you think? Should I keep the paper white borders... or should I delete them?

## After 3 years, an artist has joined me.

After 3 years of working alone, I have hired an artist to work with me on the game.

The pros:
- I was able to work the game at my own pace (i. e. very slow) and just focus on programming, without being distracted/worried about leading an entire team.
- I could change, scratch and toss away work. Redo entire levels without worrying of wasting someone else's time and my money. The first level's background actually changed 4 times.
- After 3 years of working on it, I have all the levels and assets (programmer art) ready to be transformed and replaced on the game.
- The artist can see if the project is worth it, as it is "almost finished" (tm). Also they can see that your are for real, and can actually finish a game.
- They can estimate much better the ammount of work and budget required to make it work.

The cons:
- The loneliness. Sucks to work all by myself. Even having someone on the side, working on their own things is a morale booster. If I eve do it again I would like to have partners from the beginning, or at least go to one of these open offices where other people work on their own stuff. Motivation is also very hard to keep is you don't have a strong will to just "sit and work".
- The tunnel view. You are working alone and its hard to challenge yourself to view things different, your vision will be blurred ond so focus. You don't have brain storming sessions with different brains chipping in a coming up with good ideas.
- The project as it is engraves on your brain, and changing it after so much time requires that you break your conception of it, and accept that a new person has joined and you have to compromise. ("But that was red...", "Yeah, but this color works much better don't you think...", "but... that's always been red").

We started just doing some proof of concept to find the art style for the game.
I provided references of work I liked. The artist presented me with their point of view and we worked from there, iterating a few times, finally we arrived to something we were both happy with:

Then some doodles and sketches came trying to find what clothes, color and hair I wanted for the main character:

Number 11 was chosen as a starting point.

And then several iterations came (left to right, top to bottom).

We took a worng turn at some point (blue glasses). There were too many details on the face and when shrinked to gameplay size they would clutter and make a mess. I was worried that we may never find it, but we decided to simplify and were soon on track. I was really happy with the final product.

One of the levels I've been working on requires you to use a skateboard.

Allthough in the level you just have to ride the skate through ramps and jumps (hard enough), for this screenshot saturday I decided to invest a little bit of time trying to see if I could make the character perform an ollie on the flat ground.

It took quite some time (30 minutes?), its not the most technical ollie you will see... but hey, the wheels are on the air and the character lands it. I'm happy =).

Edit: does somebody know why is my .gif not showing in this post? It shows correctly and animated in the editor, but not when I click "Publish Now".

themostposerheroes.com

There are three heroes in my game. They all move the same. Move the limbs -> thus the torso moves. Enter the robotic companion.

The Robot idea came from the observation that sometimes you need a little push to make your character go through some obstacle or reach a destination. I consider the idea of having an almighty hand available for "cheating", ala deus ex machina, that you could summon arbitrarily and it would come and push your little paper doll. But having a robot companion not only was better suited, it could also add an extra dimension for the game.

So here is the little robot:

As you can see, the robot floats around. Thus it's much easier to control, just drag it wherever you want it to go.

This little robot can be used for several purposes:

Pushing your heroes around is one of the best uses for the robot. When you are stucked, or can't reach something, or you start falling to the wrong side and are afraid to move.

The robot is not so strong though, so don't expect it to be able to lift you off very high and just fly you through the level. It can help, but don't push it.

The robot is not only useful, but needed in some puzzles. Its small size, flying abilities and full control are perfect in some scenarios.

## Even more changes to first 6 levels.

I made several small changes to all levels, trying to smooth any rough edges the testers find.

One problem with this approach: The games are going to be painted (as in, no tiles or reusable pieces). That means everytime I change a level, a (theoretical) artist should change their drawings and reexport them, which is not good. Not only that, since the game is so sensible to sizes and positions, the artist is not going to have as much freedom as I would like to give them, since they have to respect proportions and positions of several objects in the levels.

The changes:

Level 1: use to have a button, now has a lever. Several people struggle with the fact that buttons need to be push from the top.

In fact every button now can be pushed from any direction. Instead of having a square shape, now they are round shape.

Level 2:
Not changed.

Level 3:
Now the arrow lighten up to clearly show how they change directions.

Level 4:
Replaced a hallway with a vacuum tunel, to make it easier for the player to move around. Made the pro token easier to grab.

Level 5:
50% remade. Replace a bunch of repetitive easy-to-guess task with only one hard task that should take a few tries to get right.

Level 6:
not changed.

Demo 0.6.4 is available for you to try. Feedback welcomed!

## Smoothing out level 2 and 3.

Today there was some level design progress!

[color=#000000][font=Verdana]

### Based on some feedback, I've been working on the levels to solve details that players are striggling with.

[/font][/color]

[color=#000000][font=Verdana]

### The second level had a few problems:

[/font][/color]

[color=#000000][font=Verdana]

### * 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.

[/font][/color]

[color=#000000][font=Verdana]

### * 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.

[/font][/color]

[color=#000000][font=Verdana]

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

[/font][/color]

[color=#000000][font=Verdana]

### * 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.

[/font][/color]

The third level required some changes too:

[color=rgb(0,0,0)][font=Verdana]

[/font][/color]

[color=rgb(0,0,0)][font=Verdana]

### [background=rgb(252,252,252)]* A red cable links the button to the marker.[/background]

[/font][/color]
[color=rgb(0,0,0)][font=Verdana]

### [background=rgb(252,252,252)]* The marker is now bigger and clearer to point out the current color.[/background]

[/font][/color]
[color=rgb(0,0,0)][font=Verdana]

### [background=rgb(252,252,252)]* The arrows were made bigger to tell the player what each pedal does.[/background]

[/font][/color]

I could really use some feedback =), specially in level design.

## New Demo out.

It's been a long time since I posted. I've been making significant changes based on some feedback received.

There's a new alpha demo out in case you want to try it: www.themostposerheroes.com (<-- do you have some spare time? feedback will be really appreciated!!)

The big main difference is that now the story starts out in space.

Why? Because without gravity a lot of issues are resolved. Movement is much easier, and I'm guessing that without gravity players will realise a few things about physics (mainly, that you need to push yourself away from stuff in order to move).

I will introduce gravity in small steps, first entering a low gravity field, before the player is actually deployed on earth to complete the mission.

If you have the time please check the demo out, I need some feedback. =)

## GUI/Tools programming vs Game programming

Dear diary...

I've been doing a lot of GUI/tool programming for the last two months (mainly building a level/character/campaing editor).
And I have noticed a huge difference in my mental state while programming GUI/tools sutff.

As in, when I'm programming games, I'm constantly on my toes: "Is this efficient? Am I making a copy of this? What O(n) is this? How can I avoid this loop?" etc etc... basically I didn't realize until now that every time I'm game programming I'm like this:

Pictured: 10.000 actions in 16 ms.

Now, don't think I'm a optimization maniac. In fact, after seeing this talk on gpp2015... apparently I'm not even doing enough.
I try to live by the rule number 1 of optimization: "Don't do it"; but I do tend to have a sense of awareness that if I can effortlesly redesign my algorithm to make it faster, I do, as long as it doesn't take me 2x+ the time to code it.

But... my eyes openend when I programmed my tools and my GUI. It felt like this:

Pictured: 1 action in 100 ms.

My mind was like: "Iterate through all 20 items? Lol, sure... Open 15 files to build this menu? Be my guest!"

Like, the reaction time was huge (user dependant), the number of items being handling was ridiculous low, 20... 30 options. It felt like a vacation.

So, my question to you... Is this a normal feeling?

If it's not: am I doing something wrong? Game programming should not be more stressful than "regular" programming. Any advice?

If it IS: If this is a common feeling, I am seriusly considering not coming back to the game industry once the indie-dream is over. I mean, if I can feel this relaxed on my work environment (and the higher salary is nice too), then maybe my doubts about what industry should I go back to is easier to answer.

Any thoughts?

## Character Editor is done

It was very simple to create since I had all the screens ready.
I just separated three screens form the Level Editor (Image Editor, Part Editor and Object Editor) and packed them into a Character Editor.

Now you can create your own character, with any number of limbs and its own physical properties, and use it for your campaign. Once the character is saved, it can be loaded for the Character Screen on the Level Editor and set to a starting position and pose, so it can be used on the level.

I was pleasantly surprised by how little time it took me to recreate my old character from scratch using the new editor.

To give you a comparison, this is what my older character "editor" looked like:

Quite an improvement, if I may say so myself =).

## Level Editor done.

The level editor is done.

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)

I'm planning to include this editor with the game, but probably I need to make it easier to use and hide a lot of details from the user. But that's for another time...

I need a character editor now...

## Building a level editor.

I've been delaying the Level Editor for too long. Always with the excuse that I had better things to do, or that I only needed one or two ore levels for the demo, so it was a waste to make a full editor right now, and I could survive with manually modifying txt file for now.

Well, excuses are over and now a full editor is needed to start the development of the entire game.

The early build is out! www.themostposerheroes.com

And if you could provide me some

# feedback

would be awesome.

So now full production on the level editor. I'm gonna include it on the final game so people can create their own levels, so I can not just have a barely working version, it needs to be slightly polished and feature complete.

Here are some gimp drafts I made to try to see the scope of the project. So far it's seems like it's gonna be a decent amount of work.

## Brutal Soul-Crashing Dream-Destroyer Feedback required.

Ok,
I finally managed to put together a 6 level early build of The Most Poser Heroes.

Please, I need brutally honest feedback. Yeah, the one that destroys your soul and dreams.

Here is an old trailer, and here are gifs and screenshots.

Things I'm interested in listening:

1] Tutorials: Did you understand how to play? Are they enough?
2] Difficulty: Is this a game you would clasify as hard?
3] Controls: Did they get in your way? Is something missing to let you achieve your goal?
4] Gameplay: Did you have fun? Do you see yourself playing further? What level did you reached before giving up? If the game was not fun, why do you think that is?

Any other suggestion is welcome.
No music, so use your favorite playlist.

You can post your feedback here on the comments, or, if you want to curse and get personal, email: stochasticlints@gmail.com

Thanks.

## New everything.

My father gave me his old laptop.
Since his "old" laptop was still 4 years younger than my current laptop, I took it. I needed it to record better videos since fraps+my game was too much for my current machine. Nothing else. I was probably going to keep using my machine for development.

I don't like configuring, installing, updating software. I hate it. But since this is a new environment, let's get new stuff.

First impression is I am exposed to a lot of things that have changed...

Is this Windows 7? Woah, this is the future... wait, was I using a 15 year old operating system. Yes.
I still got rid of everything on 7, setting it to "improve speed" option... ahh, lovely '98 gray task bar never leave me.
Installed the latest version of Code::Blocks. wow, nice, lots of new things, better useful autocomplete (in a computer that doesn't stutter). I'm pleased.
New MinGW... c++11 stuff on it? Nice!
New SDL. Apparently 1.2 is old school now. Ok, I have to update to 2.
What do you mean there's OpenGL 4.0?

And... after cursing a little bit with box2d (as usual)... I'm ready to go.

If you had asked me one week ago if my development computer was fine I would have said it was perfect!

Sure, some buttons on my keyboard didn't work and others had to be pressed hard.
Sure it would blue-screen or just freeze ocassionally, no big deal.
Sure it was slightly slow if i tried to do anything else parallel to programming.
But I was happy, really, honestly, I totally got by with a smile (this is not sarcasm).

Now... now that Ive seen what it is to work in a fully functioning computing... I cannot even think of going back to that piece of junk.

And that is the moral of the story kids. Do not try better things. Do not go to fancier restaurants. Keep using the bus. Do not try actual good quality brand shoes. Do not upgrade your electronics. Just don't. You don't need that, as long as you don't try it.

Repeat after me: quality, not even once.

ps: I don't have too much to show because of theses changes, so here is a little gif:

# Oh, an alpha DEMO is coming soon! (mid july probably)

[color=rgb(102,102,102)][font=verdana]

### 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:

[/font][/color]

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 stuck; so the player assumes he is working at the right time, but actually he is at the end of the animation).

[color=rgb(102,102,102)][font=verdana]

### And considering that

[/font][/color]most players completely failed at Step (1)[color=rgb(102,102,102)][font=verdana]

### , this cycle repeated a lot of times.

[/font][/color]

[color=rgb(102,102,102)][font=verdana]

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

[/font][/color]

• IK controls: as I mention in my previous post, now you can control the whole limb with a handle, instead of part by part.
• No need to "play": After a change, if you forwards in time, you will se the results. "Updating" is no longer needed.
• Automatic "go back": This is tricky, sometimes the player stops the movie because he doesn't like the results; other times because he is pleased with the results and wants to start working at a different frame. For now, if you press stop you go back to the last "dynamic frame"... that is, where the character did a significant movement.

[color=rgb(102,102,102)][font=verdana]

### 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.

[/font][/color]

[color=rgb(102,102,102)][font=verdana]

### So here comes the most drastic change ever.

[/font][/color]

## [color=rgb(102,102,102)][font=verdana][/font][/color]

[color=rgb(102,102,102)][font=verdana]

### You can see that every time you move a limb, the simulation is run behind and a silhouette shows you what will happen!

[/font][/color]
[color=rgb(102,102,102)][font=verdana]

### So now, even if you have no idea what you are doing, you can see if it's working, and retry very easily.

[/font][/color]

[color=rgb(102,102,102)][font=verdana]

### So the current cycle is:

[/font][/color]

1. Move the entire limb using the IK.
2. Go back to (1)

[color=rgb(102,102,102)][font=verdana]

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

[/font][/color]

[size=2][color=rgb(102,102,102)][font=verdana]** I haven't tested this with actual users yet... so maybe I'm celebrating too early.[/font][/color]

## Solution to Level 2

Continuing working on the introductory levels, this is the solution for level 2.

Here the player gains control over the leg also (level 1: only controls the arm). The body is still fixed, so there's not a lot of room to screw up.

Exactly zero minutes were spent researching the insides of a helicopter. I just needed a task that involved the arms and legs so the players gets used to keyframe, timing, etc, before he is actually loose and at the mercy of physics.

## Inverse Kinematics to the rescue.

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 code to truncate the rotAng variable:if (bones[boneIdx].hasLimits){ bool limitExceeded = false; if (rotAng > 0 && bones[boneIdx].angle + rotAng > bones[boneIdx].maxAngle) // truncate to maxAngle { rotAng = bones[boneIdx].maxAngle - bones[boneIdx].angle; limitExceeded = true; } else if (rotAng < 0 && bones[boneIdx].angle + rotAng < bones[boneIdx].minAngle) // truncate to 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).

## New, easier, introductory levels.

So, besides my hud problems, and gameplay troubles, it has come to my attention that the first level is too hard.

This is the current first level:

It's a vertical level, from top to bottom; so gravity was supposed to help. It was not enough. So this level needs to be redesigned.

Also, 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 really liked, so I came up with three introductory scenes, in which your character's body 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)

Hopefully this will give the player enough actions to get use to the poses/keyframes/mechanic of the game, before he has to worry about moving the character around.

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.

## The IGF reviews are here.

The IGF reviews are here. The good news is that they all concur to the same point. The bad news is the point they all concur to.

Consensus: Good idea. Boring implementation.

===

I really like the idea behind the game however in it's current state it is no fun to play at all because the process of animating the character feels to tedious and slow.
Maybe an idea to facilitate and speed up that process would be to preanimate some poses and then reuse them with some kind of drag and drop mechanic. I can see this being fun but it would need some damatic changes in its interaction principles.

----

This is a really interesting idea, but the inherent tedium of animating is not mitigated enough at this point. This may be one of those ideas that looks good on paper but doesn't work out when you actually prototype it, or there may be ways to improve the pacing, such as the ability to save poses to swap in more quickly or having characters with fewer joints at the beginning.

----

REALLY love the idea, but the implementation is just not there. It's not fun to play. It sounds amazing in my head--and I was blown away as soon as I was reading what it was asking me to do--but I didn't enjoy the doing.

===

This implies much bigger changes than the HUD things I was talking about. The suggestions they give I had already considered, but i rejected them because of their implications on gameplay.

I think these are the first objective, over the internet, opinions I've gotten, and for that I give them more weight than the ones I've gotten so far face to face (a lot of people won't say to your face that your game is boring).

Now i need to decide if I keep my original direction, thus aiming super-niche, and sink with the ship.
Or... make a drastic change, trying to appeal to a (slightly) broader audience. I really wish I could do this without compromising the original ideas of the game, but right now that doesn't seem possible.

Decisions, decisions, ahead of me... and of course lots of prototyping.

"Art is not a democracy." - GRR Martin.
[size=2]But I'm not an artist, Martin, I'm an artisan.