anothergod posted:

This gif turned out pretty OK.

GlyphGryph posted:

I did not get the sense that Imaginary Friend was just a designer/writer, was just sharing a technical example of "how I would do it".

D34THROW posted:

I haven't seen anything about it recently and the latest Google results are old as poo poo: whatever happened to that one game somebody in here was working on called Black Annex? The one done in QBASIC? That poo poo was awesome!

Imaginary Friend posted:

Imaginary Friend posted:

Well I wouldn't call myself a programmer, but I got some of the stuff you wrote at least

Also, good thing I broke both my legs longboarding so I have time to add useless stuff to my game! When entering blah-mode, different kinds of blah's are jumbled together with keywords that are tagged with [blah] in the text file. The keywords in there are food and here so I actually managed to create some weird kind of blah-language!

FuzzySlippers posted:

Do you guys think it is tacky to mention other games to let customers know how your game plays easily? Like I remember a game on Steam just said "like advance wars" which saved them a butt ton of words describing advance wars and I knew what they meant and if someone didn't they went on to explain a bit more.

Imaginary Friend posted:

Hammer Bro. posted:

Physics Question

I want my skeletons to lob bones in parabolic arcs that will hit the player if they don't move -- standard physics engine stuff.

When a skeleton is ready to throw, I know the position of the bone, the position of the player, the value of gravity, and the angle at which they intend to toss it. What I don't know is the initial velocity to give that projectile so that its trajectory intercepts the player.



What's the formula to find this?

TooMuchAbstraction posted:

Google for ballistic trajectory formula. Specifically look at the "angle required to hit coordinate" section.

Hammer Bro. posted:

That gives the formula to find an unknown angle:



I've got a fixed angle, so I'd need to solve that equation for v. I'm not sure my algebra is up to that standard anymore, but I'll spend some time on it.

Polo-Rican posted:

Honestly, for this use case, I'd just solve it using a little guess and check. If you were making a golf game or a tank game or something, then it would be worth really hitting the books. A skeleton throwing a bone?... I dunno...

1. pick a y-velocity and gravity value for the projectile that feel good
2. do a test throw with x-velocity=10 and see the distance it travels in pixels
3. (x-distance in pixels / 10) = the distance / x-velocity ratio you can use

Add a slight amount of randomness to each throw and that's probably good enough that nobody will ever complain. if there are lots of circumstances where the thrower is above the player, you can figure out a similar ratio that decreases the x-velocity if the y-distance is positive.

This is a better solution in some ways because it's super easy to add maximum and minimum x-velocities, so your skeleton whiffs bones in the air if the player is too far away.

GlyphGryph posted:

I really want to play... whatever this is. That's quite an interesting aesthetic you've got going on.

Obsurveyor posted:

If you need more guidance, this is a good article:

https://blog.forrestthewoods.com/solving-ballistic-trajectories-b0165523348c#.2j112v87k

Polo-Rican posted:

Honestly, for this use case, I'd just solve it using a little guess and check. If you were making a golf game or a tank game or something, then it would be worth really hitting the books. A skeleton throwing a bone?... I dunno...

1. pick a y-velocity and gravity value for the projectile that feel good
2. do a test throw with x-velocity=10 and see the distance it travels in pixels
3. (x-distance in pixels / 10) = the distance / x-velocity ratio you can use

Add a slight amount of randomness to each throw and that's probably good enough that nobody will ever complain. if there are lots of circumstances where the thrower is above the player, you can figure out a similar ratio that decreases the x-velocity if the y-distance is positive.

This is a better solution in some ways because it's super easy to add maximum and minimum x-velocities, so your skeleton whiffs bones in the air if the player is too far away.

anothergod posted:

Yeah I agree a lot here. The work involved in making this "AI" be perfect is a lot, but the player will understand that all they have to do is move. If you compare that to Hammer Bros. in Mario or Skeleton Throwers in Castlevania, they throw things relatively close but mostly randomly, and the player's response becomes much different and is more about judging the minute differences in stimuli.

Splat posted:

I'll try and remember to write it out later but:

anothergod posted:

This gif turned out pretty OK.

Hammer Bro. posted:

Physics Question

Somfin posted:

The "set angle" aspect is what's fuckin' ya here. Set either the horizontal speed or the vertical launch speed- preferably the latter, for ease of level design- to a constant, and your calculations will become drat near linear. Plus it'll be much easier for players to read and counterplay.

zolthorg posted:

it makes more sense to me for the vertical launch speed to be constant and the horizontal launch speed/angle to change. then they would all have a uniform hangtime before they drop

Somfin posted:

Uniform drop hangtime, uniform maximum height, simple parabolic calculation for predictions. Plus they always look 'thrown.'

Mercury_Storm posted:

PHYSICS

Krunge posted:

How is the initial rigidbody.velocity determined using jumpForce?

Hammer Bro. posted:

Physics Solution

https://vimeo.com/184962484

code:

static func get_velocity_of_arc_intercept(initial_position, target_position, angle):
	var delta_vector = target_position - initial_position
	var x_velocity = sqrt((gravity * delta_vector.x * delta_vector.x) / (2 * (delta_vector.y - (tan(angle) * delta_vector.x))))
	# Adjust for lost sign.
	if sign(x_velocity) != sign(delta_vector.x):
		x_velocity = -1 * x_velocity
	var y_velocity = x_velocity * tan(angle)
	return Vector2(x_velocity, y_velocity)

Thanks for all the comments and interest.

I may end up switching to a fixed-travel-time solution, but it's nice to have this in my pocket for when I really want things at fixed angles. I still maintain that it can be put to interesting uses.

Polio Vax Scene posted:

This doesn't seem to be working for me in specific circumstances. It looks like if the delta vector X is larger than the Y it can end up having a negative value in the sqrt.

Mercury_Storm posted:

This is proving to be pretty difficult because drag is not a constant like gravity, and instead reduces velocity by a percentage every frame. Any ideas here?

Mercury_Storm posted:

rigidbody.velocity *= Mathf.Clamp01(1f - rigidbody.drag * Time.fixedDeltaTime);

Hammer Bro. posted:

Which really just means pass in the negative of whatever angle (in radians) you intuitively want to give it.

anothergod posted:

I don't know anything about drag physics, but this is not going to have the same results for different fixedDeltaTime values. Literally at fDT 1, 60, and 100 you will have different results.

Are you using Drag to keep things from moving too fast? Like to limit velocity vectors when you're on the ground? I was having a similar problem because I thought drag meant drag-while-moving-across-other-objects like moving something on the ground. Unity uses drag like you would for a plane or something moving through air, though. You can tell because the drag equation doesn't reference other objects or collisions. That means that dense objects want low drag and not dense objects want high drag - think throwing a baseball vs throwing a beachball. The last thing I had drag > 0 on was a smoke effect.

I only ask because I was using Drag for literally that problem. For a moment I was solving this drag problem by just applying drag when the player was on the ground and changing it to 0 when the player was in the air. It worked but I was upset that the physics weren't right. Then I just started using physics materials.

Hammer Bro. posted:

My Smart Brain has not recovered, but this smells strongly of Calculus II to me. Integrals (if you're not familiar with them) allow you to add up infinite infinitely-small numbers into an exact sum. Or, graphically, determine the area under an arbitrary curve.

Higsian posted:

That character sprite looks infinitely better with that background than any of the others you've shown so far. The shadows and movement also help I'm sure, but the floor really makes the character pop.

Looking at your next gif the character doesn't look as good on the stairs or the white floor.

I'm not enough of an artist to tell you why though.

GlyphGryph posted:

You might want a few backup equations in that case though - boost it up a bit if the player is up higher for example.

So one equation for if the player is more than "x" units below the thrower. Another equation if they are between "-x" and "+x", and a final equation for if they are more than "x" units above the thrower.

At least that's how I've seen it done before in games where you want them to pose a risk with any kind of approach, without them throwing perfectly horizontal fastballs at your guys (which don't look too good)

Edit: Or do the cool thing where it inverts the throw!

GlyphGryph posted:

Self imposed challenge status: COMPLETE