Sunday, January 5, 2014

Game Physics - Jumping

In modeling physical behaviors for the purposes of games, we try to get as close to a realistic model of the world as possible. Things like cars will have a velocity, acceleration, and friction, and even gravity will come into play if you catch air. Generally, we just apply all the forces acting on the car - acceleration from the engine, friction from the brakes, drag from the air, and gravity. Generally these are applied over long periods of time, and so modeling these all as forces and handing them off to the physics engine works very well.

However, jumping is not so simple. Unless we’re talking about rocket-boosted jumps, jumping is not a continuous force applied over time. Instead, it is an impulse - a powerful force with a very short duration, followed by ballistic motion until the jumper returns to earth. And for the purposes of a game, we may not want to think in terms of very large, short-lived forces - it would be preferable to think in terms of maximum jump height. That’s much easier to code with, and makes a level designer’s life a lot easier as well.

Let’s go through the physics to see how we can relate a maximum jump height to the impulse force necessary to produce it.

First, let’s start with the equation for ballistic motion - the motion that occurs after the jumper leaves the ground. We can ignore the horizontal motion for now; we’re only concerned with only the vertical component.


What we want to determine is an expression for the maximum height achieved during the jump. To that, we take the derivative with respect to time, and set it equal to zero:


We can plug this value of t in to the original equation to get a maximum value for y. We can also assume that y0 is 0, and that y just refers to the jump height relative to the starting point:


Looks like the only variables governing jump height are the initial velocity, which is determined by the impulse we talked about earlier, and gravity, which is a constant. We can rearrange terms to get an expression for the initial velocity in terms of the jump height and gravity, which will be useful later on:


By convention, +y means up, and therefore g will negative and y will be positive, resulting in only real numbers. If we reversed the convention, it wouldn’t matter: g and y will always have opposite signs, and the equation will still work. We also threw away the ± in front of the square root, because negative initial jump velocities make no physical sense.

Next, let’s figure out the impulse part. For this, we’ll want to use Newton’s Second Law of Motion. It is usually written as follows:


When dealing with impulses, however, it’s somtimes easier to write it differently:


What this says is that to achieve a change in velocity of Δv for a mass m, we need to apply a force F over a duration of Δt. In our case, Δv will be the difference between the pre-jump velocity - zero - and the initial jump velocity, which we calculated as 2gy. To get the jump to be instantaneous, we’ll want the force to be applied over a single step of our physics engine. Usually, it’s easy to query the physics engine directly for that value. And if we’re using a physics engine based on forces, we’ll have to have a mass defined for our jumper as well. The only unknown know is F, which we can solve for:


Apply this force to the jumper when it jumps, and the peak of its jump should be exactly y.

Why go to all this trouble of calculating a force when I could just set the velocity directly?

It’s certainly possible to do things that way - you just need to be careful you’re not messing up your physics engine, or making weird things happen. For example, if your jumper is moving upwards on a fast platform, and you set the velocity as 2gy directly, the jumper might fall right through the bottom of the platform instead of jumping off of it. The right way to do jumping as a velocity instead of a force would be to do something like this:

    velocity.y += Math.sqrt(-2 * jumpHeight * gravity);

Thursday, January 2, 2014

Markdown Cheat Sheet

Markdown Cheat Sheet

Table of Contents



# Header 1
## Header 2
### Header 3

Basic Formatting








> Something famous was said

Something famous was said

[link text](

link text

[link text][name]


link text

<a name="anchor">Anchor</a>
[link to anchor](#anchor)

link to anchor


Some text[^footnote]

[^footnote]: Footnote content can be placed anywhere in the document.

Some text1



![alt text](

alt text


![alt text][id]


alt text



  • Unordered
  • Lists
    • Nested
    • Multi
  • Mixed
    1. Children


  1. Ordered
  2. Lists
    1. Nested
    2. Multi
  3. Mixed
    • Children


Definition 1
Definition 2


| Header | Centered | Right Align |
| ------ | :------: | ----------: |
| Left   | Center   | Right       |
| Colspan          || Right 2     |
Header Centered Right Align
Left Center Right
Colspan Right 2


 def fib(n):
     if n <= 1:
         return 1
         return fib(n-1) + fib(n-2)
def fib(n):
    if n <= 1:
        return 1
        return fib(n-1) + fib(n-2)



$$ e^x = \sum_{i=0}^{\infty}\frac{x^i} {i!}$$



The quadratic equation is $ x = \frac{-b\pm\sqrt{b^2-4ac}} {2a} $

The quadratic equation is x=b±b24ac2a

  1. Footnote content can be placed anywhere in the document.

Tuesday, March 13, 2012

Searching the command line history in bash

With as much as I've been using bash lately, it's weird that it's taken me this long to stumble across a need for searching the command-line history. But it happened today, and it was easy to do, as soon as someone told me how to do it. I had a command I'd run a few times over a week ago, and in the intervening time I'd run thousands of other commands. I could figure out all the parameters to this command if I wanted to, but the Second Rule of Programming states that "Programmers are Lazy," so I was going to find a better way. And it's pretty simple:

Hit CTRL+R at the command prompt, then start typing what you remember of the command. When the one you want shows up, hit Enter to run it or Escape to have a chance to edit it. Simple as that.

I really enjoy using all the *nix operating systems and the power you get in the shell environment. However, the biggest drawback is that using the shell environment is not intuitive like a GUI can be (if designed correctly, of course). Chances are, you can do whatever it is you need to do, because someone else needed to do it first and went and made that possible. But you need to go and learn it yourself, because there's not a whole lot you can divine from a screen blank except for a cryptic '$> ' and a blinking cursor with zero prior knowledge. That's fine by me, as long as such knowledge is as readily available as possible when I need it. I'd much prefer that to a ridiculously complicated ribbon interface with a buttons for so many things that finding the button I need takes longer than asking Google to find it for me. I mean, if I'm Googling anyway, it's easier for me to remember a command name or a keystroke combo than a series of menus or ribbon tabs to drill through. I'd further argue that executing a known command in a shell or a keystroke combo is an O(1) operation, whereas executing a command from a menu or a ribbon interface is O(log(n)), with n being the number of available menu options or ribbon buttons. With few possible commands (like, say, MS Paint), it's not a big deal. With a ton (like, say, MS Word), it can be a nightmare if you need something fairly obscure.

Friday, March 2, 2012

Automated Testing with MonoTouch on an iPad: Revisited

Back in December, I wrote this post about my efforts to set up automated testing on an iPad in MonoTouch. I updated that a couple of weeks ago, noting that there was now a --launchdev option which might make all of that unnecessary, so long as your test app didn't need any data. Unfortunately, mine did. However, as of MonoTouch 5.2.5 (or potentially earlier, but 5.2.5 is when I noticed it), I saw a new command-line option appear for the mtouch program: --argument. It's description? "Launch the app with this command line argument. This must be specified multiple times for multiple arguments." Could this be a way I could ditch the separate launcher app and related AppleScript incantations completely? The short answer is yes. The long answer follows, after the break.

Saturday, February 18, 2012

C# Initializers

C# generic collections offer a lot of flexibility and power for organizing your program's data. However, if you need to set one up manually, you may have written code that looks something like this:

List<string> list1 = new List<string>();
list1.Add("list1 item1");
list2.Add("list1 item2");
list2.Add("list1 item3");

List<string> list2 = new List<string>();
list2.Add("list2 item1");
list2.Add("list2 item2");
list2.Add("list2 item3");

List<string> list3 = new List<string>();
list2.Add("list3 item1");
list2.Add("list3 item2");
list2.Add("list3 item3");

Dictionary<string, List<string>> dictionary = new Dictionary<int, List<string>>();
dictionary.Add("list1", list1);
dictionary.Add("list2", list2);
dictionary.Add("list3", list3);

Wouldn't it be nice if you could declare a dictionary in one statement? Or a list? Or an array? Or even an entire class, complete with all data members, which may themselves be other classes, lists, dictionaries, or arrays? Well, turns out that you can. Find out how after the break!

Friday, February 17, 2012

Customizing Appearance of Disabled UIBarButtonItems

Have you ever wanted to change the appearance of a disabled UIBarButtonItem? It seems to be a fairly common issue without many good solutions - at least, until iOS 5.0, anyway. Perhaps you've tried this one:

UIBarButtonItem button = 
    new UIBarButtonItem("Untitled 1", UIBarButtonItemStyle.Plain, null);
button.TintColor = UIColor.White;
button.Enabled = false;

It all works fine, up until you disabled the button, at which point your button becomes a very faded version of whatever you had in there. Normally, that's what you want to have happen, because dimming the button is a good indication to the user that the button cannot be pressed at the current time. However, there may be situations where that isn't true...

For example, I have a toolbar with a document title in the center. It's a UIBarButtonItem, so that it can detect touches, and respond by showing a UITextField that allows the document title to be edited. The document editor has two modes: an edit mode, and a run mode. In run mode, I don't want the title to be edited, so I disable the button. However, I still want it to be nice and visible, like a title should be. I also wanted to avoid the obvious workaround of swapping out my title button for another non-functional button with the same content. It would work, but it would kind of break some of the behind-the-scenes stuff we're doing with our user interaction model, and would require me to maintain the state of two separate buttons with the title. Also, a button that is enabled has a little sparkly animation when it is touched, to let you know that it is touchable and that the system recognized that you touched it. The two-button workaround means I would still have that animation, and gives the user the impression that they can still edit the title, but it's not working right.

So, what did I do? Find out after the break.