As I strive to put interesting features into my current mansion project, I've found that trial and error is currently my only method of design, and I think that stinks. I can't help feeling that I could be much more effective if I were able to describe interactions in Midnight Mansion mathematically so that I could model how a certain mechanism is to work before I go building it. It also occurs to me that some of what I want to know may already be common knowledge among the community.

So, before I went haring off trying to figure all this out on my own, I figured I'd post a list of all the things I want to know and see what others can fill in. After that, I'll figure out the rest and post them in a follow-up, so we can all have a handy reference to build off of.

Units
If you're gonna describe something, ya gotta have units! Fortunately, we only need three in this case. I've chosen to use seconds (s) for time, tiles (t) for distance, and tiles/second (tps) for speed.

Please use these units when posting quantities (or if there's a better unit, use it but explain it).

Modeling Jack's Motion

• How fast does Jack run (tps)?
  
• How fast does he fall?
  
• How fast does he slide down poles?
  
• How high does he jump?
  
• How high does he jump from vines?
  
• How fast does he travel horizontally while falling?
  
• How far can he jump (can be obtained from the previous three)?
  
• How fast does he climb ladders and vines?
  
• How far can he fall without dying?
  
• Bonus question: What effect do moving things (conveyor belts, moving platforms) have on Jack's horizontal motion, and is there a mathematical relationship between this effect and the speed of the platform?
  

Modeling other motions and times

General:

• 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?
  
• How do duration numbers translate into seconds? (some dialogs say it's s/60, but others don't. Is this consistent?)
  
• How long does it take a door to open?
  
• How long does it take Jack to flip a switch?
  

Spiders:

• How fast does a big spider descend/ascend? (tps)
  
• Small spiders--actually, I can't make head nor tail of these numbers. If someone could explain what they mean I would be most appreciative.
  

Birds:

• How does the amplitude number translate into vertical range (as in, given an amplitude number, how many tiles will the bird deviate up or down from its placed position)?
  
• What does "angle delta" mean?
  

Fish: What relationships correlate initial speed, gravity, jump height, and speed of ascent/descent at a given vertical position?

Final remarks
I think that's all the information anyone could need to model any aspect of the game. If we can figure out all these numbers, it should be possible to just plug things into a spreadsheet and churn out answers to all sorts of design problems.

Here's a simple example if you're having trouble visualizing why I'd want to know all this: Suppose Jack is sliding down a pole. You have horizontal zapper beams across the path of the pole, and you want Jack to ride down in a cocoon of safety, with beams turning off just as he reaches them, and turning back on just as he passes through. I've seen this done before, and wanted to do it, but got stymied by the prospect of building it by trial and error. If I knew Jack's rate of fall on a pole (and what the zapper durations mean), I could just set up a few formulas in Excel and fill down to churn out the values for all of the zapper beams.

Think of it. Just think of it!  :o :o ;D :P

Also, this information really should be in the manual. Eh Vern, wink wink nudge nudge?  ;) ;) :-? :-?

ryos,


I've also puzzled over those factors myself.  :-/ :-/ :-/

I've done the same as you with trial and error methods because I was too lazy too sit and calculate especially because it's different from Mac to Mac. I'm sure there's formulas behind the movement. just not sure whether Vern would publish those.
FWIW I did do a bunch with measurements in the custom graphics tutorial so that may help but that's a GREAT idea about modeling a mansion first. In a post somewhere I did mention that I was using Excel to track my layouts, critter dispersal, path validation and such and it would be very cool to add movement formulas to it.
Hmmmmmmm, we need to talk about this some more (unless Vern considers it taboo or reverse engineering). But I definitely LIKE the idea!

Joe B

joeb wrote on 15.04.2007 at 07:27:22:

* joeb goes to read the tutorial... Hey, that's nice! I now know that what I had previously referred to as a "tile" is really half of a tile, at least in the graphical sense. I chose the tile because it seems to be the only unit that's sane to try and measure in the editor, due to the grid. It also seems the most convenient, because everything is tiles in MM. So: 16x16 pixel tiles, 40x27 tile screen. Actually, I do have a program (Art Director's Toolkit) with an onscreen ruler. That will be of much use I think. [quote]...but that's a GREAT idea about modeling a mansion first. In a post somewhere I did mention that I was using Excel to track my layouts, critter dispersal, path validation and such and it would be very cool to add movement formulas to it. Hmmmmmmm, we need to talk about this some more (unless Vern considers it taboo or reverse engineering). But I definitely LIKE the idea!

Yay! Someone else crazy like me! ;)

I'll get to measuring tonight when I get done with work. My tools of choice will be the aforementioned ADT and a stopwatch. I'd be happy to post any spreadsheets I come up with as well. It should be easy to come up with a few calculator sheets (fish movement, small spider movement, etc) that convert desired movement characteristics to dialog box numbers.

I don't have time to really get into this right now, but I'd recommend using game seconds instead of real world seconds to make measurements. And the most reliable way to do that is the zapper beams. The time increments the zapper beams use is supposed to be 1/60th of a second. So a beam with 1 on and 59 off should flash once per second, and you can make measurements off of that.

Quote:

is supposed to be

Yes and no. REALLY don't want to get into it but a slower machine takes more time to do EVERYTHING not just the system task which is supposed to occur once a second but actually doesn't based on interrupt status. This is from my Test Engineering days at GE, RCA, Intel and Motorola and based on what's actually hooked to the processor and the speed of those peripherals you can see some interesting "seconds".
But the model you present is an accurate one for figuring out what ryos is talking about.

What kind of engineering? Based on the sit and calculate (or plug and chug as we called it in the olden days) I'd say you were one of those unfortunate soul EE students looking to calculate anything but parasitic capacitance. YUK!!!!

Let me know what you come up with and I'll see if I can Excel it. Doing a lot with Excel now as we're using a new product called Crystal Xcelsius for creating dashboards for financial analysis and it'd be fun to do something other than figure out how the bank can make yet more money.

And yes, my wife says I often dabble in the realms of crazy and she just wishes I weren't so good at it.

Tin foil hat is now off.....

Later dude,

Joe B

The zapper clock is an interesting concept, but unfortunately it proved too hard to watch both it and what I was trying to time, plus its inherent inaccuracy means that the error introduced is probably more significant than any differences based on differing machine time.

I still think it doesn't matter. The timing of all events in-game should scale in exact proportion to the current machine time. Data collected on a slow machine should yield the same models as data collected on a fast machine. We just have to be careful not to mix data sets and we should be fine.

Naturally, as with all empirical functions, there is an error involved that we need to be aware of. These methods are only so precise, and yield functions that are only valid under conditions near those used to determine them. Fortunately, this application does not demand a great deal of precision. One thing I've learned is that good enough is sometimes good enough. :)

Anyway, I found a free stopwatch program called "Chimoo Timer" that works quite well. I didn't have time to get many measurements and I'm now going to bed, but I'm optimistic that this will prove fruitful.

Oh, and I'm a ChemE, hoping to work on alternative energy technologies/solutions. My dream is to help improve batteries to the point that an electric car has only upsides. They're already pretty close; see the Tesla Roadster for the best example. I also wouldn't mind working on renewable processes for producing electricity (like this one for example).

But right now, what I feel like is a monkey with a calculator. ;D

Progress report time! (What follows is a description of what I've done so far to try and discover the function that maps the speed number to the physical unit of tiles per second, for those who are interested in that sort of thing.)

I timed all the speeds with Chimoo Timer, plotted the data, and fit a line to the plot. The resulting equation...didn't work in practice. I tried to construct a zapper beam room where Jack rides a platform of speed 20 across the beams in a pocket of safety, and the timings produced by the function were off by a fair amount. However, they were close enough that it wasn't too hard to tune the thing by hand.

After I had tuned it by hand, I entered those numbers into the sheet to determine the actual speed of the platform. I tuned another speed by hand to get another point and ran a line through it. The resulting function...didn't work.

Then, I came up with an even more accurate (but time-consuming) way to measure time in MM. Set up two zapper beams separated by the distance you're measuring over (one full screen for high speeds, less for slower speeds (for the sake of my sanity)). Have a platform with the speed to be determined bounce between them. Get the numbers right, and the beams will flash every time the platform hits them. The previously determined linear functions give a decent ballpark to start from.

Once the true numbers are determined by this method, not only will we have a table that we can use to just look up the proper speed, but we should get a more accurate function out of it as well. It's possible the relation isn't quite linear...we'll see.

...time passes...

Ok, I've got all the measurements done and the function fit. The data aren't entirely linear, but pretty close. It makes me wonder if I might be off in my measurements by 1/60th of a second on some of them. Oh well.

The function that provides the best fit is a third-order polynomial. THIS IS VALID FOR SPEEDS 1-20 ONLY! Fortunately, there aren't any other possible speeds. ;D

The function is accurate to +/- 0.5 tps (or 8 px per second). That should be good enough for most applications. Those that require more precision can use the lookup table.

Here it is:
y = ax^3 + bx^2 + cx + d
a = 0.000397348
b = -0.006289512
c = 1.808243877
d = 0.041327132

With y being the speed of the object in tps, and x being the speed of the object in MM speed numbers.

I haven't tested this yet, but given the method employed I feel confident that it worked. :)

Jesus, you guys really must have some spare time to fill !   ;D :D ;)

aquaMat wrote on 16.04.2007 at 21:32:22:

Jesus, you guys really must have some spare time to fill !   ;D :D ;)

What can I say? I'm out of mansions to play! :D

The semester is winding down for me. I'm in the lull where there isn't much homework, but it's still too early to start studying for finals. Hence, this monkey starts looking for more things to calculate!

And, really, all that sounds time consuming, but it wasn't that bad.

BTW, do people want me to keep chronicling my quest to model Midnight Mansion? Or would you rather just consume the fruits when it's done? I did it assuming it would be interesting to someone, but if no one cares I'll save myself the trouble. :)

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

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.

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 on 17.04.2007 at 10:43:36:

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


Quote:

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!  :)

Quote:

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

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

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.

A few insights from the first (successful :P) 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!

...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. :D

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

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:


Quote:

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. :(