April 16, 2010


Filed under: Uncategorized — wickedworx dev clone 1 @ 12:38 pm

Yesterday I worked on player movement / physics on two games. One is currently going under the title “Stick ‘Em Up 2”, but subject to change if we think of a different name… One of the areas where we got a lot of mixed feedback on Stick ‘Em Up was the controls. We use Box2D.XNA for our physics, so anyone also using Box2D might find this interesting!

So, for SEU2, I have been prototyping improved player movement:

  • Ducking
  • Improved handling of slopes
  • Improved jump handling
  • Wall jumping

One of the strangest complains we got on SEU was that jump was on the left trigger, and not a face button. I really think it’s obvious why jump is on the left trigger…but for those who didn’t understand why: right analogue stick is used for aiming meaning your right thumb is not available to press face buttons.. if jump was on a face button (A X B Y), you’d have to stop aiming while you jumped. In SEU2, I plan to have jump mapped to both left trigger *and* a face button – so people who (for some strange reason) find left trigger awkward, can have it their way. Weirdos.

OK, so the first thing I did to improve the player movement was to ‘reset’ the play velocity every frame, and over-write it with what we felt was correct. This means BOX2D’s world gravity force is not applied to the player (it is still applied to all other world objects), and we have to use our own gravity counter to accelerate the player downwards. The reason for this change is to avoid the ‘mini accidental jump’ the player would do after running up a slope (after running up a slope, your Y velocity is going upwards, the slope ends, and you continue running upwards). Instead of just using an X/Y velocity, we now have the velocity split as “gravity/jump velocity” (Y) and “walk velocity” (not quite X). Walk velocity is then always applied perpendicular to the ground you are currently on (or, if you are in the air – along X). This worked. It was great, and you need no longer fear that mini-accidental jump at the top of slopes (which often meant you couldn’t do a *real* jump because you were already in the air…)

Wall jumping… this was fun, and easy. Firstly, I lowered the amount of control you have of the player in the air – in SEU1 you had as much control in the air as you did on the ground, meaning you didn’t need to take a run up for jumps, and you could completely reverse the direction of a jump once in the air.. This is no longer the case.. while you still have a large amount of control over your jump in the air, it is not on the same level as when you are on the ground (approximately 1/5th the amount of left/right acceleration in the air as on the ground). This means we have much more control over ‘pushing’ the player off walls when they do a wall-jump, even if they are still pressing the stick in to the wall.

Ducking .. in order to do ducking we give the player two physics bodies. Only one is ever enabled, either the ‘standing’ or the ‘ducking’ shape. The properties (position, velocity) of the enabled body are copied in to the disabled one each frame. When the player switches between ducking/standing – we swap which body is enabled. If the player is ducking, we do a raycast check to make sure there is enough space to stand back up, and if not – we make sure the player stays ducking. Actually fairly simple to implement, and so far, appears to work fine!

For Excruciating Guitar Voyage, I’ve been adding extra features which should allow the level design to be more open, despite the game’s 2D limitations.. One of these new additions is LADDERS. I use a ‘sensor’ body for the shape of the ladder, which informs the player whether they can “ladder” or not (on BeginCollision and EndCollision messages are sent).. If the player can “ladder”, and chooses to ladder (by pressing ‘up’ or ‘down’) we simply turn off their gravity, and allow movement in *either* X or Y. This prevents diagonal ladder climbing – you can either go up/down or left/right. If they jump, or leave the ladder area, everything returns to normal. This hasn’t been tested to death, but so far – it seems to have the desired effect. In EGV as there are no other dynamic objects than the player, the world gravity is actually set to (0,0) anyway… one feature I haven’t found in Box2D is the ability to set different gravity values per object (override, for example), so best to not use it altogether in this case.

OK, was gonna write more, but I forgot what while I was eating lunch.

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: