Howdy, I am currently working on a Liero type game. I am trying to recreate the grenades, or, in this video, the “chiquita bombs”, which bounce on the terrain, before exploding.
I am trying not to rely on Roblox’s physics, to make the overall performance of the game more reliable. While I have the bouncing working mostly, I see that my Shapecast can sometimes create inacuracies in the trajectory, leading to different trajectories. This is because the segmentation of the curve is not always equal, due to the difference in frame times.
With this said, I am trying to detect the collision point of a trajectory in the most accurate way possible. In advance, I appreciate any help in acheiving this.
Below, I inclue a video of how it currently performs, and a place file containing my current code.
Quick thought: would this not be solved by using delta time? If the difference in the time between each frame is a problem, delta time could correct that.
I am taking it in mind, and using it. When I am talking about the difference is that when a collision is happening, the starting position of the projectile can be farther or closer to the surface it will impact. The thing is that this initial position can affect how “inclined” the segment is and, consequently, the part of the terrain it hits.
To try and play around this, I have tried to decompose the frames into other small segments of 0.002 seconds if I recall correctly. It helped in making the frames more consistent in regards to the length of the segment, which is already quite nice. Still, I would need some better detection in the curve. I am open to other methods not involving raycasting, by the way.
We are talking about small numbers here, but they can make quite the significative difference as you may see on that clip I shared.
Only solution I can think of is disregarding DeltaTime, and having a fixed step per simulation frame. If difference in framerate is causing discrepancies, ignore it.
I mean like using Stepped and use 1/60 in place of DeltaTime.
The issue with doing something like this for the players, is that the trajectory may not feel as nice. Perhaps it is a bit insignificant but I notice myself.
I have tried to do something similar here, by dividing the DeltaTime in segments of 0.001, more or less synchronized with tick() and processing the remainder separately, although with subpar results. One issue I also have with this approach is the different framerates players can set, and how I could adapt for it not to be staggering. Also, if a frame freezes for some unspecified ammount of time, it would need to be compensated for.
I am not sure if I am approaching the “network model design” wrong, but I am trying to make the projectile visuals in the client and have the server have it play “invisibly”, to then, through remotes, share the results with the clients. For this I wanted it to be as synched as possible between clients and server, including some hypothetical compensation for the player that created the projectile. If you also have some suggestions on alternative models, I am all ears, as well.
Anyways, I think this approach you suggested could work but I am wondering how it would be appropriate to tackle the situations I just mentioned.
Maybe use my approach for background processing of the projectile, and have the client process the visuals on renderstep using an equation so it is theoretically infinitely smooth with an infinite framerate. Then, update the client with new information with every bounce of the grenade so it can still follow the server-calculated trajectory quite accurately, with minimal discrepancy on visually.
Today I no longer have the time capabilities to try it out, as soon as I can get some time I will make sure to test it out and share some feedback. I appreciate the input!
Howdy! Got some time to try it out, and it is working perfectly.
I do not think I will need to have a remote synchronize with the client’s bounces for accuracy. I defined a field on the bananas that indicates the last time processing happened and had it process under very small values, as per your suggestion. With it in mind, as long as the values are the same in the client and server, it should always be accurate between the network. I will try to adapt it a little for some ping compensation, but it is super fine. Once more, thank you for your suggestion!