Devas of creation's npc replication idea? (smoothness)

The new game “devas of creation” just came out. The blocking mechanic and slashing mechanic is very smooth, even when on 400+ ms servers. I just wanted to hear your opinion on how this was made. Let’s also keep “exploiters being able to exploit these methods” off this topic. We should care about the regular user’s experience more when it comes to rpg games like this. Here are few ways I came up with:

The “initial”(at the very least) of slashing and blocking was obviously client sided, now what? How do they perceive attacks?
possibility number 1) For the blocking, I’m guessing the block uses fire server, then the enemy ai casts a server hitbox for enemy attacks and then… if the parry value is false (use invoke client to check if player is blocking, might just be lagging, and when the player is actually blocking they return true).

possibility number 2) For the blocking, players will use “AnimationPlayed” on enemy humanoid vicinities. Once the enemy humanoid attacks with an animation, then the client waits for the “hitbox” keyframe to pass, and then the client itself will check if it is bound to get hit by the hitbox. (This way you can check it yourself if the client is blocking from the client side.) The client will then be the one to admit to the server if they got hit or if they parried the attack (FireServer). To top it off, they may even be playing the animations in client instead of playing it in the serverside.

for me, I believe it might just be possibility number 2. Exploiting out of the topic, this is the best way to make a multiplayer “Player vs AI” games.

2 Likes

Without taking exploiting into account, yea I’d agree that #2 is probably the best way. Just have everything run on the client since there won’t be any lag for the player, and the client will confirm hits/blocks/etc.

However, I don’t think it’s practical to ignore exploiting when making a multiplayer game since that completely changes how you’d implement features of your game. I imagine the devs have some sort of way to verify everything on the server without relying on the client to simulate everything.

2 Likes

Thanks for the feedback, If we’re assuming its a “co op” multiplayer “rpg” game, i think we should prioritize the user experience more :slight_smile: It would be a different story if the game was competitive.

There are other workarounds to patch exploits, like using different methods to check things like “if client wasn’t able to send” or “if client sent the honest data” in specific ways. This is rather optimized yet a good solution if you are willing to change the method to check the client’s honest data every few days in order to detect exploiters (Speaking on exploiter’s behalf, it is easy to get a workaround and spoof the methods, but if you constantly update the game and change the methods of how you check the data, you will be able to catch one of them lacking, efficiently, with the BanAPI.). Once you catch a script kiddie lacking, they won’t be able to do much with roblox’s new ban api, that is if they’re only script kiddies.

That’s fair. I haven’t played Devas that much to learn all the gameplay features they have but it doesn’t look as competitive as other games out there.

If you’re interested, there’s a talk on the Overwatch netcode. It starts around 22:30 and talks about how they implemented a completely sever-authoritative system while keeping the client experience as responsive and “lag free” as possible. Not saying Devas does something like this, but it’s one method to keep the player experience feeling good while mitigating exploiting risks.

Hello, overwatch’s resource cannot be comparable with roblox’s server resource. I believe in overwatch the normal matches are typically below 70 ms and is stable, therefore they can use server resource as much as theyd like to. In terms of server memory I believe overwatch surpasses

If you do not care about exploiters being able to completely bypass the game mechanics, then the second possibility has some potential. However I would strongly recommend avoiding the first idea, as using a Invoke Client commonly like that could allow exploiters to crash servers by infinitely stalling the invoke. Which, regardless of how competitive the game is, still harms the experience of other players.

I didn’t play devas for very long or experienced high ping in it, so I can’t really comment on how plausible it is that they used the 2nd possibility. Especially since the game has pvp with item loss. It is more likely that they simply had the client fire to the server when it presses the block button, and the server has a gracious parry window. But as I’ve heard it’s their first major release, there is a chance it’s implemented in such a fashion.

A better way of going about the second option would be to apply an attribute to characters that are attacking, (with Character:SetAttribute(Name, Value)) that contains a time for when the hitbox is supposed to happen. Then listening for those attributes to change on characters you’ve engaged in combat with. (with Character:GetAttributeChangedSignal(Name):Connect()).

However you go about implementing it, I wish you luck on your work!