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.

$$y = y_0 + v_{y0}t + \frac{1}{2}gt^2$$

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:

$$\frac{\delta y}{\delta t} = v_{y0} + gt \\ 0 = v_{y0} + gt \\ t = \frac{-v_{y0}}{g}$$

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

$$y = v_{y0} \frac{-v_{y0}}{g} + \frac{1}{2}g\left(\frac{-v_{y0}}{g}\right)^2 \\ y = - \frac{v_{y0}^2}{g} + \frac{v_{y0}^2}{2g} \\ y = - \frac{v_{y0}^2}{2g}$$

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:

$$v_{y0} = \sqrt{-2gy}$$

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 $\pm$ 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:

$$F = ma$$

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

$$F\Delta t = m\Delta v$$

What this says is that to achieve a change in velocity of $\Delta v$ for a mass $m$, we need to apply a force $F$ over a duration of $\Delta t$. In our case, $\Delta v$ will be the difference between the pre-jump velocity - zero - and the initial jump velocity, which we calculated as $\sqrt{-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:

$$F = \frac{m\sqrt{-2gy}}{\Delta t}$$

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 $\sqrt{-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);

Markdown Cheat Sheet

Table of Contents

[TOC]

• Markdown Cheat Sheet
  • Table of Contents
  • Outline
  • Basic Formatting
    • Bold
    • Italic
    • Blockquote
  • Links
    • Inline Link
    • Reference Link
    • Anchor Link
    • Footnotes
  • Images
    • Inline
    • Reference
  • Lists
    • Bulleted
    • Numbered
    • Definitions
  • Tables
  • Code
  • Math
    • Block
    • Inline

Outline

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

Basic Formatting

Bold

__bold__
**bold**

bold
bold

Italic

_italic_
*italic*

italic
italic

Blockquote

> Something famous was said

Something famous was said

Links

Inline Link

[link text](www.google.com)

link text

Reference Link

[link text][name]

[name]: www.google.com

link text

Anchor Link

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

Anchor
link to anchor

Footnotes

Some text[^footnote]

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

Some text1

Images

Inline

![alt text](https://www.google.com/images/logos/ps_logo_6.png)

Reference

![alt text][id]

[id]: https://www.google.com/images/logos/ps_logo_6.png

Lists

Bulleted

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

Numbered

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

Definitions

Term

Definition 1

Definition 2

Tables

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

Header	Centered	Right Align
Left	Center	Right
Colspan		Right 2

Code

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

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

Math

Block

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

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

Inline

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

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

---

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

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.

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.

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!

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.