# Lunar Lander Game help

connor dobbin

Greenhorn

Posts: 1

posted 4 years ago

Hi, i am currently coding my own version of Lunder Lander for my course work in university but i am completely new to java and game development. I have all the basics down and coded but i am really stuck on the physics that i have to use, and how i would implement them into the game and the code?

Thank you for your time and help

Thank you for your time and help

posted 4 years ago

Generally, you'll find unfocused questions get unfocused answers...if they are answered at all.

Most folks here would say you have done it wrong. If you have written code before you understand what you need to do...how can the code possibly be right?

You should start by figuring out all the things you need to do, then code them in pieces...add in one tiny part at a time. For example, code the acceleration to gravity. Your lander will probably crash a lot.

once that works, code the thrust of your ship. perhaps at first, your ship can only be pointed straight up, so you don't have to worry about the angle. Once that works, you can code for your ship to be angled and what the vertical thrust would be. At this stage, you might have it where you only allow 0% or 100% thrust.

Once that works, code for variable thrusts.

Once that works, code for allowing your ship to turn.

Once that works, code for air resistance (assuming there is any).

etc.

Most folks here would say you have done it wrong. If you have written code before you understand what you need to do...how can the code possibly be right?

You should start by figuring out all the things you need to do, then code them in pieces...add in one tiny part at a time. For example, code the acceleration to gravity. Your lander will probably crash a lot.

once that works, code the thrust of your ship. perhaps at first, your ship can only be pointed straight up, so you don't have to worry about the angle. Once that works, you can code for your ship to be angled and what the vertical thrust would be. At this stage, you might have it where you only allow 0% or 100% thrust.

Once that works, code for variable thrusts.

Once that works, code for allowing your ship to turn.

Once that works, code for air resistance (assuming there is any).

etc.

There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors

Phil Freihofner

Ranch Hand

Posts: 126

4

posted 4 years ago

One key to implementing physics in a game is that you need to do it in on the basis of the time slices of a game loop.

Velocity is often coded (by beginners) as an X distance and a Y distance that is traveled in one game loop slice, where X & Y are a number of pixels.

Thus, if you are at (x, y) and have a velocity (xVel, yVel), the new location will be (x += xVel, y += yVel).

Acceleration is then often coded as another X and Y amount that is summed into the velocities, e.g., xVel += xAccel; yVel += yAccel; done once per time slice. Gravity is a constant acceleration in the Y direction (conventionally, anyway).

This implementation has some definite limitations, because the distance traveled per time slice will be larger on diagonals than on horizontal or vertical paths. One can use trig functions to ensure distance traveled is the same in all directions. Tutorials for the trig implementation should not be hard to locate. I'm thinking, nothing more than High School level trigonometry skills are needed, but a lot of us slept through those classes and forgot the material because we didn't know it would actually prove so useful down the road!

HTH

Velocity is often coded (by beginners) as an X distance and a Y distance that is traveled in one game loop slice, where X & Y are a number of pixels.

Thus, if you are at (x, y) and have a velocity (xVel, yVel), the new location will be (x += xVel, y += yVel).

Acceleration is then often coded as another X and Y amount that is summed into the velocities, e.g., xVel += xAccel; yVel += yAccel; done once per time slice. Gravity is a constant acceleration in the Y direction (conventionally, anyway).

This implementation has some definite limitations, because the distance traveled per time slice will be larger on diagonals than on horizontal or vertical paths. One can use trig functions to ensure distance traveled is the same in all directions. Tutorials for the trig implementation should not be hard to locate. I'm thinking, nothing more than High School level trigonometry skills are needed, but a lot of us slept through those classes and forgot the material because we didn't know it would actually prove so useful down the road!

HTH

posted 4 years ago

Don't forget the basics: F = M A

All of your accelerations for the various thrusters can be directly calculated from this, then you just use the acceleration to vary the velocity, and then you calculate position. The physics is nearly trivial. Of course, on the moon, you can't use 32feet / second/ second for gravity's acceleration.

All of your accelerations for the various thrusters can be directly calculated from this, then you just use the acceleration to vary the velocity, and then you calculate position. The physics is nearly trivial. Of course, on the moon, you can't use 32feet / second/ second for gravity's acceleration.

posted 4 years ago

I think you can skip the trig, Phil. You've correctly separated the position and velocity vectors into their scalar components along orthogonal axes. Yes, for a given time-slice, Δt, the total distance traveled will be greater if both Δx and Δy (which you are calling xVel and yVel) are not zero than if one of them is zero (and the other is the same in both cases), but that's how the physical scenario actually works. Consider: If I drop a rock, initially at rest relative to a surface, from height h over that surface in a constant gravity field, the rock will take a total time t fall h distance and hit the surface. If I drop the same rock from height h, but give it an initial velocity vector v, parallel to the surface, it will still take precisely t to fall to the surface, but will travel a much greater distance (along a parabolic arc). If I drop two rocks, one initially at rest and the other with velocity vector v, parallel to the surface, both will fall to the surface in time t, but the velocity vector of the rock initially in motion will be greater than the rock initially at rest; it will be the vector sum of the at-rest rock at the moment of impact, and its own initial velocity vector. Just before they simultaneously hit the surface, one of them is moving faster than the other in a diagonal direction. By treating the vector components individually, you avoid the need for any trig, and simplify the entire physical model.

Now, if you were summing up the Δx and Δy components into a vector of their own, then adding that to the position vector and (complicating matters even more), summing up the ΔVx and ΔVy acceleration components into a single ΔV acceleration vector to add to the velocity vector, then, yeah, you'd have to start taking sines and cosines of the vectors when you were done, to get the Δx and Δy values you were after in the first place. But, if you just do your X and Y math separately all the time, you never have to do any of that stuff.

Phil Freihofner wrote:

This implementation has some definite limitations, because the distance traveled per time slice will be larger on diagonals than on horizontal or vertical paths. One can use trig functions to ensure distance traveled is the same in all directions.

I think you can skip the trig, Phil. You've correctly separated the position and velocity vectors into their scalar components along orthogonal axes. Yes, for a given time-slice, Δt, the total distance traveled will be greater if both Δx and Δy (which you are calling xVel and yVel) are not zero than if one of them is zero (and the other is the same in both cases), but that's how the physical scenario actually works. Consider: If I drop a rock, initially at rest relative to a surface, from height h over that surface in a constant gravity field, the rock will take a total time t fall h distance and hit the surface. If I drop the same rock from height h, but give it an initial velocity vector v, parallel to the surface, it will still take precisely t to fall to the surface, but will travel a much greater distance (along a parabolic arc). If I drop two rocks, one initially at rest and the other with velocity vector v, parallel to the surface, both will fall to the surface in time t, but the velocity vector of the rock initially in motion will be greater than the rock initially at rest; it will be the vector sum of the at-rest rock at the moment of impact, and its own initial velocity vector. Just before they simultaneously hit the surface, one of them is moving faster than the other in a diagonal direction. By treating the vector components individually, you avoid the need for any trig, and simplify the entire physical model.

Now, if you were summing up the Δx and Δy components into a vector of their own, then adding that to the position vector and (complicating matters even more), summing up the ΔVx and ΔVy acceleration components into a single ΔV acceleration vector to add to the velocity vector, then, yeah, you'd have to start taking sines and cosines of the vectors when you were done, to get the Δx and Δy values you were after in the first place. But, if you just do your X and Y math separately all the time, you never have to do any of that stuff.

"Il y a peu de choses qui me soient impossibles..."

Phil Freihofner

Ranch Hand

Posts: 126

4

posted 4 years ago

I was referring to the following common situation:

If the rocket is standing still and has its X velocity increased by 1, it will be going 1 pixel per slice. If this rocket then has its Y velocity increased by 1, it will be going something more like 1.4 pixels per slice, yes?

Many early games and simple games treat a distance of 1 along the diagonal as equivalent to 1 along the horizontal or vertical. The classic "Snake" comes to mind as an example.

If you have a "booster" or "accelerator" for your rocket, and it can go in any direction, then at some point in the process you will need trig to determine how to break out a given amount of boost into the component X and Y vectors, if you want to maintain a more accurate physical model.

I think you can skip the trig, Phil.

I was referring to the following common situation:

If the rocket is standing still and has its X velocity increased by 1, it will be going 1 pixel per slice. If this rocket then has its Y velocity increased by 1, it will be going something more like 1.4 pixels per slice, yes?

Many early games and simple games treat a distance of 1 along the diagonal as equivalent to 1 along the horizontal or vertical. The classic "Snake" comes to mind as an example.

If you have a "booster" or "accelerator" for your rocket, and it can go in any direction, then at some point in the process you will need trig to determine how to break out a given amount of boost into the component X and Y vectors, if you want to maintain a more accurate physical model.

posted 4 years ago

Correct. Note that you were able to deduce that without trig, because you separated the velocity vector into its component axes. If ΔX = 1 and ΔY = 1, the magnitude of the vector is, indeed, about 1.4 (to be precise, it is √2).

For a physical simulation, that would certainly be a mistake.

True, if, as you say, the acceleration vector can have any direction. For a given orientation away from vertical of θ and acceleration magnitude of a, ΔVx would be a⋅sinθ, and ΔVy would be a⋅cosθ (sign adjusted for whether you are tilting left or right). After that, your math is all simple addition.

However, a number of very good, fun lunar landers have been written that do

I just wanted to be sure the OP was clear that, just because the modeled vehicle begins to move in two dimensions, there is no need to make velocity adjustments in contemplation of the fact that a one-pixel move in one dimension at the same time there is a one-pixel move in the other dimension amounts to a √2-pixel move on the screen. It certainly does do that, but that's exactly what it should do. No need to make adjustments based on trig or anything else.

Phil Freihofner wrote:I think you can skip the trig, Phil.

I was referring to the following common situation:

If the rocket is standing still and has its X velocity increased by 1, it will be going 1 pixel per slice. If this rocket then has its Y velocity increased by 1, it will be going something more like 1.4 pixels per slice, yes?

Correct. Note that you were able to deduce that without trig, because you separated the velocity vector into its component axes. If ΔX = 1 and ΔY = 1, the magnitude of the vector is, indeed, about 1.4 (to be precise, it is √2).

Many early games and simple games treat a distance of 1 along the diagonal as equivalent to 1 along the horizontal or vertical. The classic "Snake" comes to mind as an example.

For a physical simulation, that would certainly be a mistake.

If you have a "booster" or "accelerator" for your rocket, and it can go in any direction, then at some point in the process you will need trig to determine how to break out a given amount of boost into the component X and Y vectors, if you want to maintain a more accurate physical model.

True, if, as you say, the acceleration vector can have any direction. For a given orientation away from vertical of θ and acceleration magnitude of a, ΔVx would be a⋅sinθ, and ΔVy would be a⋅cosθ (sign adjusted for whether you are tilting left or right). After that, your math is all simple addition.

However, a number of very good, fun lunar landers have been written that do

*not*allow for arbitrary directing of the acceleration vector. I like this one, for example. In those games, vertical acceleration is throttled independently of lateral acceleration. (Although the actual Apollo LEM could move by tilting, its thrusters actually did move it by lateral acceleration at right angles to the thrust produced by the main motor.) You can get some beautiful and physically accurate trajectories in simulations based on this approach, they are somewhat easier to code (no need to draw a rotated lander, for example), and can be extended later if you do want to model a lander that rotates (or uses vectored thrust in any other way).

I just wanted to be sure the OP was clear that, just because the modeled vehicle begins to move in two dimensions, there is no need to make velocity adjustments in contemplation of the fact that a one-pixel move in one dimension at the same time there is a one-pixel move in the other dimension amounts to a √2-pixel move on the screen. It certainly does do that, but that's exactly what it should do. No need to make adjustments based on trig or anything else.

"Il y a peu de choses qui me soient impossibles..."

Phil Freihofner

Ranch Hand

Posts: 126

4

posted 4 years ago

I'm in total agreement, but am uncomfortable being

But yes, one can have independent horizontal and vertical thrusters and vertical gravity, and create a nice simulation, without any trig whatsoever, with good trajectories. I agree, and didn't initially see that that was part of the classic lunar lander scenario.

Pax!

*told*that I obtained the 1.4 number without trig. In fact, I did look up to verify sin(PI/4) and cos(PI/4) both equal approx 0.7. An alternate route, the Pythagorean equation a^2 = b^2 + c^2, leading in this case to the square root of 2 also kind of counts as something learned in trig, yes?But yes, one can have independent horizontal and vertical thrusters and vertical gravity, and create a nice simulation, without any trig whatsoever, with good trajectories. I agree, and didn't initially see that that was part of the classic lunar lander scenario.

Pax!

posted 4 years ago

Well, I wasn't trying to read your mind, or anything. I was just speaking to the content of your post. Everything in it was correct, and (maybe this

Heh. We've probably done more to confuse the OP than encourage him, at this point. I wrote my first lunar lander game on a TRS-80, back in 1979. It's a great choice for a first video game, because the math really is quite simple, the load on the CPU is pretty light, and yet the on-screen results are amazingly realistic. I hope he'll try it and, if we can help, that he'll come back here and ask for it. I'm pretty sure either of us can help him get the job done.

Phil Freihofner wrote:I'm in total agreement, but am uncomfortable beingtoldthat I obtained the 1.4 number without trig. In fact, I did look up to verify sin(PI/4) and cos(PI/4) both equal approx 0.7. An alternate route, the Pythagorean equation a^2 = b^2 + c^2, leading in this case to the square root of 2 also kind of counts as something learned in trig, yes?

Well, I wasn't trying to read your mind, or anything. I was just speaking to the content of your post. Everything in it was correct, and (maybe this

*was*a guess at your behind-the-scenes thinking) I just assumed you were estimating the magnitude of two summed unit vectors at right angles, which, as you point out above, can be done with Pythagoras's Theorem. (I grant you that the Pythagorean Theorem might be taught in a class on trig, but, fwiw, Pythagoras himself had no knowledge of the topic. The earliest math that could be recognized as trig was probably the work of Euclid, about two centuries after Pythagoras.) More to the point I am trying to make: that calculation, regardless of how it is done, is never required by the simulator (unless, as you point out, one is simulating a rotating ship or vectored thrust). That's because, if your velocity vector components are both 1, their vector sum just

*is*√2. You don't need to compute that sum to run the simulation, because the laws of physics will simply make that be the actual, on-screen velocity of your lunar lander. It's not that you can do it with trig or do it with Pythagoras's theorem; it's that you don't have to do it

*at all*. (That would not be the case, of course, if you wanted an on-screen display of the velocity of the lander. That would be an interesting issue to consider for design: would you want an absolute velocity indicator, or would that confuse the player who might be more interested in rate of ascent/descent (Δy), and speed-over-ground (Δx). as separate values?)

Heh. We've probably done more to confuse the OP than encourage him, at this point. I wrote my first lunar lander game on a TRS-80, back in 1979. It's a great choice for a first video game, because the math really is quite simple, the load on the CPU is pretty light, and yet the on-screen results are amazingly realistic. I hope he'll try it and, if we can help, that he'll come back here and ask for it. I'm pretty sure either of us can help him get the job done.

"Il y a peu de choses qui me soient impossibles..."