Algorithm help, horrible at math
I am messing around with some Javascript game development, trying to create a simple Framework for drawing a playing field (for a sports game).
I am horrible at math and really need help with this algorithm.
Say I have these variables:
GAME_WIDTH = 1024;
FIELD_LENGTH = 170;
PLAYER_SPEED = 4.72;
update_duration = 30;
The first 3 in caps are variable, meaning they can be set by the user. The last is essentially how often my "update" code is called in 1 second.
GAME_WIDTH is pixels, FIELD_LENGTH is meters, PLAYER_SPEED is how many seconds a player can cover 40 meters.
What I want to do, is take those 4 variables and translate that into how many pixels a player can 开发者_高级运维move in 1 "update". I have never really done any Game Development and I never payed attention to Geometry or Trigonometry in school so I am completely at a loss here.
Can anyone help?EDIT
This is a 2D top-down game so this algorithm is only dealing with X (right-to-left) coordinates.You need to embrace the fine art of "Units Conversion". http://oakroadsystems.com/math/convert.htm
For example, 12 inches = 1 foot. So you can convert inches to feet like so:
48 inches * (1 foot / 12 inches) = 4 feet. The "inches" cancel out, leaving just feet.
So the answer we want is pixels per update. (Is update_duration in milliseconds? assuming so...)
(40 meters / 4.72 seconds)
* (1024 pixels / 170 meters)
* (1 second / 1000 ms)
* (30 ms / 1 update) = 1.53140578 pixels / update
or if the 30 is updates/second, same idea:
(40 meters / 4.72 seconds)
* (1024 pixels / 170 meters)
* (1 second / 30 updates = 1.70156198 pixels / update
(I may have misinterpreted the meaning of your constants... but that's the technique. The concept is that each of those fractions, a / b, is equivalent to "1".
This looks better when you write it in full classroom fraction style, all the canceling becomes chalkboard-perfect. Very useful technique to embrace.
Just multiply everything up so that the correct units come out:
1024 px 40 m 1 s px
------- x ------ x ---------- = 1.70 ------
170 m 4.72 s 30 updates update
(If you want to impress your friends at the next cocktail party, say you solved it by "dimensional analysis" :-) .)
You probably don't want to work with the pixel/update ratio directly. Rather, you want to keep track of the total number of pixels that have been traversed after a certain time and render those. The point is that you cannot make sense of fractional pixel counts, so you can only advance by either one or two pixels per update, but how do you know which one? Rather, you could say "now it's the 10th update, so I need to be at pixel 17."
So, what you want is how many pixels there are to the meter...
That's Pixels/Meters. In other words, you take the number of pixels and divide it by the number of meters, and you get the number of pixels per meter;
1024 pixels/ 170 meters = about 6 pixels / meter.
If someone can run 40 meters in 4.72 seconds. You need to know how many meters they can run per second. That's meters/second.
Again take the number of meters and divide it by seconds and you get meters/second:
40 meters/ 4.72 seconds = about 8.5 meters / second.
Now, you want to know how many pixels that person can move in a second. We have:
6 pixels/meter and 8.5 meters/seconds
Look at the units:
pixels/meter meters/seconds
Let's say we multiply them:
pixels * meters / meters * seconds
Meters are on the bottom and top, so let's eliminate them and get pixels / seconds. Let's do that:
6 pixels/meter * 8.5 meters/seconds = 51 pixels / second
That's pretty much the secret: You look at the units and see how you can manipulate them.
BTW, you know that the number of pixels will change depending upon the direction the player moves. For example, this only works if the player is moving across or vertically. If the player is moving at an angle, you have to figure out the actual length using the ol' pythagorean theorem.
精彩评论