Bullet Physics?

[DARKB1KE]

Are weapons going to be working client-side or server-side?

This leaves room for a ton of discussion.... especially if PVP is involved and netcode and stuff.

As I understood it, the server-side bullet physics meant that your skill mattered. A shot was a shot and where you aimed mattered. It also was a more fair battle with PVP as far as I'm aware?

Also lots of questions about how the AI is going to be running and what UE4 is capable of?
I can only judge it based on FireFall but I don't know if the AI running server-side actually benefited the game at all. People were always complaining about rubberbanding and non-responsive AI which affected the combat.

There's pros and cons to both of these options.
It's also hard to separate the AI from the combat too since they go together.

Since I'm not a developer, I'll leave this thread to those that know.
Perhaps they can share some knowledge.

 

[Nunaden]

running the AI client side would be.... yeah...
you can crack even closed source, so some1 could make a completely inactive AI, and it would also worsen the performance

 

[EviltwO]

your question is a big mess. lets say short: it's all tied up and complicated.

about unreal - it's made for shooters. according to what the alpha ut4 and some other ue4 games have for now i can tell it's still the best engine for shooter, hope devs got straight hands (￢_￢)

about firefall.old firefall had problems with pvp and shooting. as example: most annoying one (for me as mainly recon) was head hitbox time to time (and especially from side view on target) placing not where head is (. _ .) and this one existed from 0.5 to after release.

different weapons with different physics + potato servers = tons of pain in pve and pvp. but unreal can handle that... especially if you know what almost every weapon in firefall is a copy from UT (don't know how it's going to be in Ember)

if you want to read something about how shooting works in shooter, here some article for you (a bit old but simple and still actual):
http://kotaku.com/5869564/networking-how-a-shooter-shoots

 

[Zarkopafilis]

Well, first up Unreal is not made for shooters only.

Also, Unreal works with a server/client model (wether there is a dedicated server or a client acting as a server). The server does all the mission critical calculations to ensure synchronisation between all the players as well as to prevent cheating. For example, when the player wants to fire a bullet or a projectile , the hitscan or the projectile launch needs to first happen on the server and then be synchronized (replicated is the correct term) to all the clients. This is noot good for visuals on the client side due to lag (even if it's a couple of ms). This is why developers also spawn these projectiles on the client side , but only for eye candy. As soon as the client receives some more information from the server, it updates (possibly changing/correcting) the properties of the projectile to ensure everybody sees the same. bla bla bla....

 

[Nunaden]

well, seems like the typical hithack/wallhack from Cube 2 doesn'T work on UE. nice to see, was kinda the pest back there...

 

[Zarkopafilis]

well, seems like the typical hithack/wallhack from Cube 2 doesn'T work on UE. nice to see, was kinda the pest back there...

Encrypting variables could also be an extra security measure to push amateurs away

 

[Nunaden]

Encrypting variables could also be an extra security measure to push amateurs away

well... the variables from server side weren't the problem but the variables from client side, since the server was JUST the communication medium of the clients. The most of the hacks in Cube 2 are based on manipulating the data send from teh client to the server (you could easily fake your position or where the shot went, even RoF of the weapons and every other statistics)

 

[Zarkopafilis]

well... the variables from server side weren't the problem but the variables from client side, since the server was JUST the communication medium of the clients. The most of the hacks in Cube 2 are based on manipulating the data send from teh client to the server (you could easily fake your position or where the shot went, even RoF of the weapons and every other statistics)

Im not talking about the variables on the server side, I'm talking client side, to eliminate the issue that you are talking about

 

[PlzBanMe]

Are weapons going to be working client-side or server-side?

This leaves room for a ton of discussion.... especially if PVP is involved and netcode and stuff.

As I understood it, the server-side bullet physics meant that your skill mattered. A shot was a shot and where you aimed mattered. It also was a more fair battle with PVP as far as I'm aware?

Also lots of questions about how the AI is going to be running and what UE4 is capable of?
I can only judge it based on FireFall but I don't know if the AI running server-side actually benefited the game at all. People were always complaining about rubberbanding and non-responsive AI which affected the combat.

There's pros and cons to both of these options.
It's also hard to separate the AI from the combat too since they go together.

Since I'm not a developer, I'll leave this thread to those that know.
Perhaps they can share some knowledge.

The way I understand it is pvp is not in the design plan at all right now. Making it client side I don't believe will cause too many problems. If some one is going to hack they will be hacking against AI and that really doesn't matter as much. Hacking is all about pissing people off and not really that much you can do in an all PvE game.

 

[NoahDVS]

The way I understand it is pvp is not in the design plan at all right now. Making it client side I don't believe will cause too many problems. If some one is going to hack they will be hacking against AI and that really doesn't matter as much. Hacking is all about pissing people off and not really that much you can do in an all PvE game.

Even in a PvE game it can cause problems, but it depends on the game. If AI is easy to hit and kills don't have a significant impact on something important, then aimbots and wallhacks won't have much of an impact, but it will piss some people off. If AI is hard to hit and kills don't have a significant impact on something important, it'll piss off a lot of people, but cheats won't have much of a direct impact. If kills do have a significant impact on something important, then cheats will have a significant and direct impact.

 

[Zarkopafilis]

The way I understand it is pvp is not in the design plan at all right now. Making it client side I don't believe will cause too many problems. If some one is going to hack they will be hacking against AI and that really doesn't matter as much. Hacking is all about pissing people off and not really that much you can do in an all PvE game.

It's against client-server principles . I could tell the server I have killed 100 mobs instead of 1 the same way I could inform it I killed 1.

 

[DARKB1KE]

your question is a big mess. lets say short: it's all tied up and complicated.

I know it is.

How is this going to run better compared to Amazon Web servers and Offset engine?
The AI would often stop working in FireFall.

There was too much lag for invasions and it had to be removed from game.

How is Unreal going to support hundreds of players in a map shooting targets and not causing it all to crash?

The problem is the servers cannot handle all that.

 

[Zarkopafilis]

I know it is.
The problem is the servers cannot handle all that.

Not even close

 

[DARKB1KE]

Not even close

Just to be clear I am referring to FireFall's servers not handling the loads. I don't think I typed out my thoughts that well. I'm kinda sporadic like that, I have a million questions and no way to organize them all.

I'm not sure if you're agreeing or disagreeing.... hmm.

Okay short version, is EU4 going to be better for MMO?

 

[Nunaden]

Just to be clear I am referring to FireFall's servers not handling the loads. I don't think I typed out my thoughts that well. I'm kinda sporadic like that, I have a million questions and no way to organize them all.

I'm not sure if you're agreeing or disagreeing.... hmm.

Okay short version, is EU4 going to be better for MMO?

better than the old engine i guess *lol*

 

[DARKB1KE]

Well, first up Unreal is not made for shooters only.

Also, Unreal works with a server/client model (wether there is a dedicated server or a client acting as a server). The server does all the mission critical calculations to ensure synchronisation between all the players as well as to prevent cheating. For example, when the player wants to fire a bullet or a projectile , the hitscan or the projectile launch needs to first happen on the server and then be synchronized (replicated is the correct term) to all the clients. This is noot good for visuals on the client side due to lag (even if it's a couple of ms). This is why developers also spawn these projectiles on the client side , but only for eye candy. As soon as the client receives some more information from the server, it updates (possibly changing/correcting) the properties of the projectile to ensure everybody sees the same. bla bla bla....

I already understand this stuff, but it's still good to see posted for others to learn as well.

https://developer.valvesoftware.com...ocol_Design_and_Optimization#Lag_Compensation
https://www.reddit.com/r/Overwatch/comments/46i2z3/why_youre_dying_around_corners_details_on_lag/

 

[Nunaden]

I already understand this stuff, but it's still good to see posted for others to learn as well.

https://developer.valvesoftware.com...ocol_Design_and_Optimization#Lag_Compensation
https://www.reddit.com/r/Overwatch/comments/46i2z3/why_youre_dying_around_corners_details_on_lag/

it says that UE4 does everything serverside if possible, even animations. DEVs jsut place the animations at the same time as teh server does in teh client so it looks better. but it gets synced by teh server.

 

[PlzBanMe]

It's against client-server principles . I could tell the server I have killed 100 mobs instead of 1 the same way I could inform it I killed 1.

The system won't just accept that data though. The system will most likely keep your weapon data(rof, mag size, reload speed, damage) server side too. You won't be able to tell the system you fire enough bullets to do that. It would be foolish to accept all data without any checks. There will most likely be some more complex checks too.

 

[Nunaden]

The system won't just accept that data though. The system will most likely keep your weapon data(rof, mag size, reload speed, damage) server side too. You won't be able to tell the system you fire enough bullets to do that. It would be foolish to accept all data without any checks. There will most likely be some more complex checks too.

happened back in Cube 2 too... there were no checks in the stock server engine/script and even not in more advanced ones like the DEV build (don't confuse it, it wasn't the build of the real DEVs but of some members of teh group "DEV", that was kinda a huge bunch of modders, scripters (the good ones) and hackers (the leader often DDoSed a server, when some of his hacker dudes got banned for hacking...)
The only server engine that would be able to do that may be the Noob server script/engine which will feature destructable maps :O its still under development

 

[phoenix]

Is it possible to decentralize some of the calculations? In essence, use players clients as botnets. For example, an invasion with 100 players and 400 mobs. If each player simulates 4 mobs then that would take a huge burden from the server and reduce server bandwidth.

A possible check against hackers would be to let 2 or 3 other players calculate the outcome for the same mob and if one of them gives a different response then he is found out.

Another check would be to spawn a ghost mod from time to time. A mob that is indistinguishable from other mobs but is invisible to the player. Both the client and the server will simultaneously calculate the response and if they aren't the same then the client has been fiddling with AI code.

With lag and stuff you'll likely have false negatives. An 80% success threshold would probably be good. When multiple people simulate the same mob then the fastest to calculate a response and send it to the server for synchronization will prevail. The other responses serve as a check.

Thoughts?