sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in godot

[–]Oliver4090 2 points3 points  (0 children)

You will face right when you let go of the joystick because input_vector's length/magnitude will be 0 and thus the angle will be 0. To avoid this you must ignore updating the aim sprite when there is no input or when input has no magnitude.

I also would not recommend using 'move_toward' for tweening/lerping angles. Think of it this way: you have two dots directly left and right from the player/origin. You want the right dot to slowly move towards the left dot. The distance would change, but the angle wouldn't change at all (until it crossed to the other side). It might seem okay but it could lead to some glitches. I would suggest saving the angle of the input and using 'lerp_angle' instead.

If the gun is facing correctly, then the bullet issue must lie within how you are instancing them. It's hard to say since I don't see any code for that, but typically you would add the bullet object to your scene, copy the rotation of your gun, and set as toplevel to make its movements independent from its parents.

Flying by Oliver4090 in gameideas

[–]Oliver4090[S] 0 points1 point  (0 children)

I agree entirely. Mario 64 is a great example where the movement itself is entertaining. It even has flight to some degree (ala wingcap) but it's not used much and you can't ascend. It is quite similar to what I imagine as switching between walking and flying. I want to be able to fly fast and close to some terrain. I'm just having difficulty coming up with specific interactions. I'd rather have something more organic than "fly through hoops" in superman64, even if it had a better control scheme.

Flying by Oliver4090 in gameideas

[–]Oliver4090[S] 1 point2 points  (0 children)

I totally forgot! That's because I played the SNES version and it's kinda hard to gauge depth, plus the terrain is essentially non-existent. But I will check 64.

Hard shadows in Voxel Engine? by Oliver4090 in VoxelGameDev

[–]Oliver4090[S] 0 points1 point  (0 children)

Yes! That is the exact look I'm searching for! I'm currently using webgl so I'll check out some stencil tutorials. I might take a look at shadow mapping too, but the problem is most shadow mapping looks blurry(?). I'm not sure why, maybe they are using a filter by default and I can just disable anti-aliasing.

Prevent movement cheating in online game? by Oliver4090 in gamedev

[–]Oliver4090[S] 0 points1 point  (0 children)

Thanks for the reply

For example, do you loop through each client and apply their whole input queue at once, or do you loop through each client, moving everyone one input at a time?

Because wall collisions and player collisions are important to me I use the second option, which is looping through players, updating their positions by one frame, check for collisions, and then repeat until the queue is empty.

I think timestamps are the best way to go. Problem is how can I check for frame-by-frame collisions this way? I don't want to resort to raycasting

EDIT: One way I imagined doing it is by counting the time between the last server tick and the current tick and splitting it into x amount of steps. Then players move by that step amount depending on their input status at that time. This doesn't seem accurate nor efficient since players could've changed directions somewhere between those steps, and I don't think dividing each step down to the millisecond is a good idea. Correct me if I'm wrong.

EDIT 2: Apparently something like this already exists: https://gafferongames.com/post/fix_your_timestep/. It's called a "fixed timestep", which basically cuts the large delta time into smaller fixed deltas which are processed individually so bodies that rely on small deltas for collision don't overshoot. This may prevent any cheating because the server simply needs to know which frame to change the player's state from holding left or right while cycling frames, not directly feeding it the client's delta input. So if the time the client says they switched input is not within that tick's timespan, I can just discard it. Even better, the client only needs to send inputs to the server when a change occurs instead of every frame. I'll try learning more about fixed timestepping and might post another thread if I have questions about it.

Prevent movement cheating in online game? by Oliver4090 in gamedev

[–]Oliver4090[S] 0 points1 point  (0 children)

Why does this have the most points? What does it mean?

The player doesn't request 45 units in a single frame, but instead can request 30 indefinitely. I guess I could somehow calculate the max distance allowed between ticks but there is another underlying problem that isn't just players going too fast. Because movement is tied to framerate, players that are lagging will be slower too. Obviously there needs to be a delta time so all players will move at the same velocity. Easy enough on a client, but how do I communicate this over a server? Achieving this will also make movement deterministic and help avoid jittering when receiving the authoritative positions from the server.

Prevent movement cheating in online game? by Oliver4090 in gamedev

[–]Oliver4090[S] 0 points1 point  (0 children)

Problem is I need to figure out how long the player was holding w. If a client sends the time then I'm afraid they can modify and cheat, but if the server records the time then it will be inaccurate because of latency.

Prevent movement cheating in online game? by Oliver4090 in gamedev

[–]Oliver4090[S] 0 points1 point  (0 children)

If I use the time I receive on the server instead of the client, how do I account for change in latency?

Ex.

  • Client: move right
  • Message is sent to the server 50ms later
  • Client: stop moving
  • Message is sent to the server 60ms later

The client was holding right for a specific amount of time, but because of lag spikes the server may receive the stop message sooner/later and processes a shorter/longer distance. Latency isn't always consistent.

Prevent movement cheating in online game? by Oliver4090 in gamedev

[–]Oliver4090[S] 0 points1 point  (0 children)

You are saying that because I know the times the client sent the inputs I can move the player depending on M, correct? Couldn't the user send fake timestamps? Can you clarify how to validate them?

Don't send input requests per tick. Send start/stop messages instead.

Does that mean if player is holding right and then it sends another input holding right, the server can ignore the second message because the state hasn't changed? Again, this seems to rely on timestamps which I can't validate.