9
\$\begingroup\$

I'm working on a game that you control a trebuchet to throw balls to the opponent.

It's like a game called 'Medieval Siege'. When the trebuchet is swinging its arm, player need to seize the best moment to press button and release the ball. Then the ball will fly at the tangent angle. enter image description here My problem right now is that the trebuchet arm swing too fast for player to seize the right moment. Meanwhile it has to be this fast otherwise it can't throw far enough. And there is a tiny string connecting the ball and trebuchet arm, if the arm swing too slow, the ball is just hanging on the string when the arm move.

I solve the problem by toggling step size, whenever the arm is swing, I change step size from 1/60 to 1/200. And once player release the ball, it's back to 1/60.

This works pretty good except my game is for multiplayer with networking. So changing step may cause problem.

Another solution I can think of is to allow it swing slow, but when player release the ball, I manually add velocity onto the ball while keeping its direction. I don't really like this solution cause it looks fake and I still have the problem that the ball is just hanging on the string, unless I make string very very short..

Please shed some light on this, thanks!


EDIT

Thanks for everyone's input, I solve the problem by making the arm swing slow and when player release the ball, grab ball's velocity and times two. It looks exactly the same as changing step size. There's just one extra thing I need to do. Because the arm is swinging really slow, the ball is just hanging on the arm end instead of swinging. I solved this by applying a force equal to the gravitational force on the ball during and only during the swing period. Then it no longer hang there but swing together with arm.

@MrCranky 's answer is detailed and looks doable, so I'd accept it. :)

\$\endgroup\$
  • \$\begingroup\$ Maybe you could move the trebuchet slowly, but multiply the forces that act on the ball? I haven't worked with Box2D before, so sorry if this is a dumb idea. Other than that, my only guess would be to fiddle around with the mass of the ball to see if heavier or lighter ones might give you acceptable results at slower speeds. Also, it might be worth looking into the physics of real life trebuchets. Those look somewhat slow, so maybe data about them (size, ammo, forces etc.) might give you some ideas for your simulated one. \$\endgroup\$ – Christian Nov 26 '13 at 8:33
  • 2
    \$\begingroup\$ Getting computer physics to behave like "the real thing" is really difficult. Almost all physics engines simulate rigid bodies, meaning effects like the bending of the trebouchet arm are not accounted for neither are rope physics nor material behavior in any way accurate, so an exact simulation without "cheating" is next to impossible. The process to get close to something that looks real goes a little like this: tweak, tweak, tweak, cheat, tweak, tweak, cheat, cheat, tweak, start over, tweak, tweak, tweak, tweak, cheat, tweak, cheat, cheat, tweak. \$\endgroup\$ – LearnCocos2D Nov 26 '13 at 10:04
  • 4
    \$\begingroup\$ Kitten cannon uses the most realistic approach to this issue: Humans really are that bad at manipulating physical reality and need machine assistance, if you would like to give the "feeling" of a trebuchet that moves slowly enough for a human to control manually but launches faster than physically possible, you might want to create a purely artistic animation of it "firing" and then spawn the ball based on where the user interrupts the animation. \$\endgroup\$ – MickLH Nov 26 '13 at 11:27
3
\$\begingroup\$

Instinctively I'd say that we're missing a substantial part of the context needed to answer, which is "why does the multiplayer aspect prevent you from changing the timestep?"

If you are trying to share a physics simulation over a network connection, well, that's usually a pretty hard thing to do. The simulations diverge very easily, and especially with network connections that can lose packets, it's very hard to keep things together.

The simple and most robust answer to your question is to use a variable timestep. When you approach the moment of decision, instead of updating your physics simulation by one second for every real-world second that passes, update it by half a second, or another suitable number. As it's an integration effect, you'll probably be able to get away with simply snapping the update rate down to the lower rate during the decision window, but you can also interpolate quickly downwards to the lower rate. Either way, you are essentially playing back the physics simulation in slow motion. It should behave perfectly accurately, just slow enough that the player can make their decision. I wouldn't consider any other means of fudging the physics to make it work, they'll most likely all work out horrible and not feel 'right'. Keep the physics pristine, and counter the decision window problem outside of the simulation.

So we come back to the networking implementation. Without further information, I'd guess you have two choices. Firstly, if you're operating in lockstep with the other networked party. So when one player has to slow down to make their decision, slow down both players equally. This will probably feel annoying and weird for the player who isn't firing, because it'll confuse their own reaction times.

For the second, imagine two trebuchets firing at each other. The trebuchet takes 10 seconds to throw, and the firing window starts at T+5s. P1 starts the firing cycle at T+0s, and at T+5s slows their local physics simulation down by 50%. It'll take them 15s to play through the whole cycle. So at T+5s, P1 tells P2 to start playing back the 10s launch cycle at full speed. So P1 sees the trebuchet cycle take 15s, P2 sees it take 10s, but both players see the cycle finish at T+15s. When P1 actually releases, they tell P2 when in the notional cycle they released. So if P1 releases at T+10s, that's actually at 7.5s through the 10s launch cycle. P2 can then show the release at T+12.5s (7.5s into its local playback of the cycle), and both players simulations should have launched the projectile at the same physical point in the cycle.

So in this second approach, you're no longer simulating in lockstep. You're running two independent simulations, but tracking player inputs instead. If both are told that the player released at 7.5s into the launch cycle, they should both agree on where the projectile will land. In practice though, that's likely to diverge very fast, and you're going to need to synchronise simulation states somehow.

\$\endgroup\$
0
\$\begingroup\$

Why not just copy/adapt what already exists and works in similar cases?

enter image description here

\$\endgroup\$
0
\$\begingroup\$

If your trebuchet is moving too fast, the obvious solution would be to scale time to make it slower. That is, for every second of real time, make only e.g. 0.1 seconds pass in your physics simulation. Now, from the player's viewpoint, the ball will be moving 10 times slower.

Actually, there's another way you can achieve the same effect: instead of scaling time, just scale all your physics constants that are in units including time. For example, gravitational acceleration has units of speed / time = distance / time², so if gravity is the only constant in your game, scaling it down by a factor of 100 = 10² achieves the same effect as slowing down time by a factor of 10.

Of course, if your physics model includes other constants with units of time (or speed = distance / time, or acceleration = distance / time², etc.), you'll have to scale those too if you want to keep the trajectories the same.

Note that there's a limit to how far you can practically go with this: if you slow time down by, say, a factor of 100, your trebuchet will be really easy to control, but your players are also likely to get bored waiting for the balls to slowly float down after firing them. If that's an issue, you may need to resort to more advanced tricks like those suggested in other answers, such as using really slow time scaling while the trebuchet is firing, but switching to a faster time scale once the ball has been launched.

\$\endgroup\$
  • \$\begingroup\$ thanks, but u probably didn't see my edit. Yeah I solved it with the last method in your answer \$\endgroup\$ – Arch1tect Nov 28 '13 at 1:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.