I thought he was going to get hit in the nuts based on the technique name
i love your work so much
Can’t wait to see a finished version
A friend made this:
Thanks!
Also, something occurs to me, if you’re going to make a single player game like that, wouldn’t it be best to just run everything on the client, and only have the map on the server?
Looks amazing but…
I’ve got nothing to kill the hostiles with and hence it’s impossible. I saw a gun on the floor though.
Do I have to pick this gun up?
or is the gun just broken for me…
Sorry to clarify this is not my game! It’s a friends and I was posting it in response to Capones question on who was making a SuperHot game a while ago. I edited the post, forgot that Guests question was quite a few pages ago.
Oh, and you can click any black object to pick it up, the guns are just cuboids at the moment.
Although I do have something of my own that might interest a few people…
What do you use for calculating upward movement? Just if the plane is above a certain speed, or something like airfoil?
Also, press enter before the tag, spoilers don’t work if it is the line after text… and that is a video, not a gif (less painful for mobile data).
http://devforum.roblox.com/t/simple-aerodynamics-on-roblox/8520
I’ve made the air very thick for various design reasons, I’m hoping that the physics are just realistic enough without being too complex for the average player to understand.
This grinds my gears.
What’s with the weird lighting setup?
Quite possibly my coolest optimization yet. The player model is being removed from workspace to save on physics/GPU workload. He’s stored elsewhere so I don’t expensively spawn new parts and all his animations are run instantly and his body in general does no more calculations to prevent his animations or body placement from continuing to eat CPU cycles as well.
I’m obviously gonna check for windows and such in the final product but yeah All that’s left is prediction (make the player model appear a few frames before he’ll be visible so you don’t magically see the player model load when he comes around the corner at 30 walkspeed). I’ll also be doing this for anyone that isn’t on-screen.
Edit: Nevermind, it already predicts when a player is about to be visible lol. It’s hard to see since the gif runs at 15FPS but yeah
Edit 2: I’ve actually made it kinda complicated now. It takes whether or not the character model is currently visible to decide where or not to use extrapolation on the camera and/or said character. Also anything within 50 studs is visible. Makes for some responsive use.
You sure this is helping lag? It seems like computing when to add/remove players, as well as the cost of parenting things in/out of workspace would be way more expensive than simply letting the physics run for the players… especially on a scale of 90+ players.
I’m testing it online right now with a few players. No hiccups yet and I imagine with 90+ players it’s only gonna benefit me more and more considering I’ll be saving so many cycles on rendering/animations/positioning/raycasting.
From my testing cloning/instancing new parts is far more expensive than simply reparenting.
It’s definitely worth it. Checking a ray here and there is very cheap relative to running dozens of joints.
http://i.imgur.com/qVr4U6D.gif
I also check if the character is on screen. If it isn’t, then it disables the skeleton’s graphics. When someone’s nearby behind the camera I can still keep audio enabled; My lua joints only exist when they’re in use, so only the leg joints would initialize while a footstep sound plays. It’s all anchored cframe, so it doesn’t need any parts or welds.
There are so many epic optimizations that can be done when using custom animations.
You explained exactly what I’m doing haha.