Modeling Jack's World

[Mikee]

Yes, thus a few new monsters momentum in the play would now correctly bring, or?

[VernJensen]

Okay, I'm not going to try to convert my units into yours, but let me introduce mine:

1) Frames - this refers to a frame of animation. If you were to slow everything way down, then each

change

in the animation occurs in a single frame. The game runs at 60 frames per second, or fps.

2) All of my units are in

pixels per frame

. Tiles are 16 pixels wide and tall, not counting the fringe. So convert my values into your tile-based values if you want, but they're given in terms of pixels in the code.

Here are some values, given in pixels per frame, for Jack:

Walking speed - 2.5 ppf
Climbing speed - 2.2 ppf
Pole sliding speed - 6.0 ppf
Maximum falling speed - 12 ppf
Gravity - 1.3 ppf (i.e. most objects accelerate by this amount per frame)

That's all I got. Jumping is tricky, so I can't really explain it. It's different from falling though. The mechanics are totally different. He normally falls much faster than he does during a jump.

I can't answer most of your other questions, except for a couple:

1) How fast does he travel horizontally while falling?

Same as normal, I think. It's just that he falls so darn fast (12 ppf within a few frames) that his horizontal movement speed is quite small by comparison.

2) What is the conversion factor between the speed number you type into the dialog box and tps? Is this factor the same for all sprites that can have a speed?

The answer to this question is interesting. You see, in old-style Mac dialog boxes, you couldn't enter fractional values, like 2.5. And I wanted that for the monsters. So instead what I did was divide all entered values by a certain number one they were loaded. For instance, if I divided by 2, and you entered

5

in the dialog, you'd get a speed of 2.5 ppf. But for some monsters I wanted more of an ability to have lots of fractional values than I needed for others. So the medusa heads are divided by something like 10 or 20 (I could look this up if you really need to know), while I think certain other monters aren't divided by anything, and some are divided by fairly small numbers, like 2 or 3.

3) How fast does a big spider descend/ascend? (tps)

You're going to have to convert ppf to tps yourself. But here are the ppf values:

Descend speed - 1.8 ppf
Climb back speed - 0.6 ppf
Delay between drops - 60 frames

4) How far before Jack dies?

7 tiles


Interesting idea you have to be so mathematical about everything, but honestly, even as the designer of the game, I'd do everything by trial-and-error myself.

[ryos]

WOOOOT! Vern, you are my hero! That post was made of awesome, no joke.

Don't worry about converting units - I can take care of that. I posted that I wanted tps mostly to ensure that everyone that posted did include units. In the end I don't really care what they are, so long as I understand them.

(The ppf makes perfect sense for programming MM, but is all but useless for working in the editor. Fortunately, it's an easy conversion to tps. )

VernJensen wrote:
2) What is the conversion factor between the speed number you type into the dialog box and tps? Is this factor the same for all sprites that can have a speed?

The answer to this question is interesting. You see, in old-style Mac dialog boxes, you couldn't enter fractional values, like 2.5. And I wanted that for the monsters. So instead what I did was divide all entered values by a certain number one they were loaded. For instance, if I divided by 2, and you entered

5

in the dialog, you'd get a speed of 2.5 ppf. But for some monsters I wanted more of an ability to have lots of fractional values than I needed for others. So the medusa heads are divided by something like 10 or 20 (I could look this up if you really need to know), while I think certain other monters aren't divided by anything, and some are divided by fairly small numbers, like 2 or 3.

If you wouldn't mind posting the divisors for all of them, I would be so grateful! It would save me a lot of measuring. (Including the platforms - even though I'm done measuring them, I'm curious to see how accurate my measurements are.)

Interesting idea you have to be so mathematical about everything, but honestly, even as the designer of the game, I'd do everything by trial-and-error myself.

I look at it like I look at scripting. Oftentimes, when I'm doing some repetitive task, I think to myself,

Self, you could write a script to do this for you.

But then I realize that writing and debugging the script would take longer than just doing the task by hand, so I don't.

But, if it's a task that must be done again, the script saves time. Also, scripting can solve problems that you just can't manage by hand.

That's where I hope to take this - automate some frequent number conversion tasks (like,

What do I need to type in the box to make the fish reach this high in this amount of time?

) and also create puzzles and effects that would be impossible (or prohibitively time-consuming) to do by hand. Hopefully, when you see some of the uses I've imagined for this, you'll agree with me that it's worth it.

One more question before I go, about fish gravity. If I type a 3 into the fish gravity box, does that mean that it decreases the fish's initial velocity by 3 ppf each frame (and then increases it on the way down)?

Once again, THANK YOU for posting those Vern!  

[joeb]

I look at it like I look at scripting. Oftentimes, when I'm doing some repetitive task, I think to myself,

Self, you could write a script to do this for you.

But then I realize that writing and debugging the script would take longer than just doing the task by hand, so I don't.

Congratulations! You've run smack into one of Murphy's theorems of programming.

22. (I think) Programmers will spend 90% of their time programming 5% of the project that is cool or nifty and then spend 10% of their time trying to finish the other 95% of the project.

Boy have I fallen into that trap a bunch of times!


Fish gravity. The higher the number, more gravity. Need a higher speed to get to the same height as a lower gravity number and the speed of the fall is faster. Check with Newton!

8-) 8-) 8-)

Joe B

[ryos]

So...it's been attack of the killer finals for the past few days. But, I've now made a little progress, thanks to Vern.

Thanks also to Vern, I now think the most useful unit for working in the editor is tiles per frame (tpf). With tpf, there is no need to convert to seconds/60 because its unit of time, the frame, is equivalent to 1/60th of a second!

Based on my measurements of platform speed, I've inferred that the divisor for platforms is 2. (Is that right, Vern?) That is, take the number you type into the box, divide it by 2, and the platform will then move that number of pixels per frame. Given that there are 16 pixels per tile, divide the speed number by 32 to convert to tpf.

This is much simpler and more accurate than the crazy polynomial expression I'd come up with previously!

House of Coine will have several rooms based on all this madness...

[ryos]

Knowing the divisor for the platforms, it was extremely easy to infer the divisors of everything else that can move horizontally by just matching their speed to a platform.

It turns out that the divisor for everything is also 2, with the following exceptions:

• Brown bird: 1
  
• Medusa heads: 20
  
• While the divisor for eyeballs is 2, their horizontal motion stops while the squishy animation plays as they hit the ground. This delay must be taken into account in anything that models eyeballs.
  

So, don't worry about posting those anymore, Vern. I am, however, still curious about fish gravity.

[ryos]

A few insights from the first (successful ) modeled room I've produced:

• Jack's falling distance, both horizontal and vertical, can be easily determined by trial and error. The time taken by the fall can then be determined from the horizontal distance alone (given that Jack always moves horizontally at 2.5 ppf). There is no need to mess with tricky trajectory calculations (that we currently don't have enough info to perform).
  
• When making sequential zapper beams that leave a

  bubble

  for Jack to move through, use the midpoint between zappers as your data point for calculation, and not the position of the zapper itself.
  

Related to point 1 above, we should be able to determine the horizontal range of a falling object provided the horizontal speed, distance of the fall, and the gravity number from Vern's post. We just can't do so for a jumping Jack (ho, jumping jack, ho ho) because we don't know how Jack's jump mechanics work. But, since most things that fall don't jump, they're much easier to grok.

PS I'm posting these results as I find them so those (well, just Joe ) who are interested in modeling can also get started. I will eventually have an Excel workbook with some useful stuff in it to post, but for now, everyone with the inclination has enough information to get started modeling their mansions!

[ryos]

...and an addendum to the addendum to point 1 above! I figured I'd explain how that calculation can be performed. ;D

First, a little physics review. The position s of an object moving under constant acceleration is s = x0 + (v0)t + (1/2)at^2, where x0 is the initial position, v0 the initial velocity, a the acceleration, and t the time.

Adapting this formula to our MM falling objects gives d = (1/2)gt^2, where d is the distance of the fall and g is the MM gravity (= 1.3 pixels / frame^2). Solving for t gives t = sqrt (2d/g). This is the time required for any object to fall a given distance in MM.

You can then find how far that object travels horizontally while falling as vt, or the object's speed times the time required for the fall.

There are many potential uses for this sort of calculation. For example, you could use this to make sure that a scorpion that falls from above will land on a moving platform below, without any trial-and-error effort at all.

Ah, the joys of nerdhood.

[Alanfalcon]

Completely fascinating, ryos. Add me to the list of people who are interested in your progress and double interested in the resulting spreadsheet/mansions

[ryos]

I'm starting in on this again, after a long hiatus. This time, I'm taking on the fish, since I think they would benefit the most from being able to plug numbers into a spreadsheet.

So far, I have inferred that the divisor for the fish's initial velocity is 3.

Now, the fish's gravity doesn't behave quite like I would expect. Based on what Vern explained about the global gravity in post #11:

Gravity - 1.3 ppf (i.e. most objects accelerate by this amount per frame)

So, let's say that you input a fish's gravity of 20 and an initial velocity of 60. Since the divisor is 3, that means the fish is initially traveling 20ppf. Assuming that the engine subtracts the gravity value from the fish's velocity every frame, the fish should only travel one frame (20 pixels) before turning around and accelerating back down. This is not what happens! The fish actually travels around 11 tiles (176 pixels) before turning around!

I'm not sure what to do at this point. I might need another Vern Ex Machina, or I might just give up.