[QUOTE=Em See;49468166]Yeah doing a "proper" authoritative server is tricky, especially for something as tight as user controlled, real-time melee strikes. With Chivalry's mostly-clientside attacking, there is also the issue of players with unstable or high latency connections gaining an advantage (which in many cases was not offset by everyone else lagging from the perspective of the player -- I suspect you could also faff about with only dropping packets in a certain direction). CheatEngine speedhacks additionally, though VAC generally gave those players a visit.
[URL="https://www.reddit.com/r/TheSlashering/comments/3q6qt2/a_new_engine_a_new_name_and_a_bunch_of_screenshots/cwcowfd"]
Apparently Mordhau is making use of a server authoritative networking model now, fwiw.[/URL]
No need to overcomplicate things, though -- client-trusting is a lot more straightforward!
[B]E:[/B] Oh I suppose you could go the other simple route and have the clients be dumb terminals displaying worldstate with no prediction (and thus no reconciliation or timetravel), but that punishes players for having higher latencies and can feel terrible if the gameplay is very fast paced.
Have you got any footage of how the combat works? I assume its somewhat physics based?[/QUOTE]
Yeah. I'm planning to go for a simple rule of "if you blocked on your screen, you blocked". That way its responsive to block a laggy player, whereas hitting someone (which isn't as timing precise) is only clientside if their client doesn't report a block. Chivalry did suffer from laggy players, but the playerbase was generally fairly good at self policing - but to be honest I'm targeting this game at the competitive community where very high lag will be less of an issue, as well has having optional ping limited servers
That's pretty cool that mordhau is proper server authoritative. As far as I'm aware, a server authoritative melee combat game hasn't been done before (except the original AoC, but that game had the worst hit detection), so I suspect they'll run into a lot of unexpected problems
[quote]Have you got any footage of how the combat works? I assume its somewhat physics based?[/quote]
I'm planning to get some friends together once its in a more playable state and record some gameplay, I'll stick that up here when I get a chance - I'd like something I can turn into a trailer ideally. Combat works pretty much exactly the same as chiv, except attacks are define in code piecewise. Attacks take the form of windup (can feint), a small period of no damage AND no feint (does not hit a block, this fixes chivalrys feint and reverse overhead issues), and then the damageable portion which can be blocked. There's chivalry style drags/directional blocking/etc (currently no turn cap, coming shortly).
The only combat systems missing from chiv are kicks (dubious value), jumping (need to figure out the animations), and a stab (need to be able to define sword direction independent from hand -> shoulder vector)
All the walking animation n stuff is procedural IK cheating
Edit:
On a content note, hooray heartbeating! The clients spam the server with information a lot (every 16 ms in fact), so I've just used that as a heartbeat. If there's no information received from a client for x seconds, they are terminated. Simple, works well. I've also updated the swing animations to swing the upper body half with the swings, as well as bend the hips, and the knees slightly. This makes everything look a WHOLE lot less static and shitty. Idle animations would really help with this though
added deltatime to loop callback and scripts can now be reloaded on the fly
[media]https://www.youtube.com/watch?v=IT62c_4t8RE[/media]
[QUOTE=Map in a box;49470215]Just do prediction. My engine has the server do everything but for stuff like movement, the client does and the server simply skips that client when broadcasting the move packet.
[editline]6th January 2016[/editline]
-proper- prediction, that is, which is a nonissue if your server/client are in the same thing.[/QUOTE]
How do you handle prediction errors?
Assuming I'm interpreting it right, user presses button, your client moves immediately (reports user input to the server), server updates player position in its own state.
So does the server still tell the client where its player is located? If so, how do you handle;
[IMG]http://www.gabrielgambetta.com/img/fpm2-04.png[/IMG] [I][URL="http://www.gabrielgambetta.com/fpm2.html"](source btw, with re-simulation solution)[/URL][/I]
(where client->server is control input, client<-server are worldstate updates)
Without any reconciliation, jitters because the client updates local state to the authoritative world state (which represents the past).
If you don't synchronise a client's actual position, is it because your client/server are perfectly deterministic (and/or you're doing something like lockstep to additionally ensure this)?
you do occasionally synchronize the clients position, and stop predicting if the client isnt' responding
[url]https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking[/url] is a good read
Yeah, it's a classic.
Source synchronises player positions (including the client's) with every snapshot (world state).
IIRC they solve the problem in my previous post by storing previous cmd's and re-simulating the player entity if there's an error.
[QUOTE=Asgard;49470269]I'm doing a turn-based competitive game. I let the client check the moves of the other client for validity, and log [I]everything[/I]. Hasn't been tested in production yet so we'll see if it's enough but the only way it wouldn't be is if there's two cheaters playing against each other.[/QUOTE]
What is done if one client considered the other to be cheating? Is the game just shut down immediately?
[QUOTE=Em See;49470925]Yeah, it's a classic.
Source synchronises player positions (including the client's) with every snapshot (world state).
IIRC they solve the problem in my previous post by storing previous cmd's and re-simulating the player entity if there's an error.[/QUOTE]
They do store a few of the previous commands on the server/client for solving errors as well as checking where other players were when you shoot.
[QUOTE=Tommyx50;49470938]What is done if one client considered the other to be cheating? Is the game just shut down immediately?[/QUOTE]
Have the game server collect the information about the players' move and send it to a separate server to be processed.
We can then assess what happened. It could be a bug, or someone sending a false packet. Either way, if a false move is made we disconnect the player. In our case this would cause the cheater to have a 'loss' registered to their ranking.
As some Reddit comment said that I got all this from:
We log every single d/c, cheat attempt, malformed packet, everything - some fancy machine learning later... and we build a pretty picture of how all these errors overlap.
BUGS have a distinct pattern, many clients, single location, 99% fault rate (happens every time, almost). CHEATERS are single clients (mostly! not always), many locations, a history of malformed packets, or even "exploratory behaviour".
Before you can cheat you need to understand the communication protocol the game uses to talk to itself, and to do that you need to "mess around" with the game - we log that, flag your account and put you in "quarantine" where you get monitored, we start investigating you if we have your payment information, and in rare cases open an ongoing report with the police or local authorities (paid games involved, hundreds of real dollars invested by players).
Got myself a [URL="https://misfit.com/products/bolt"]Misfit Bolt[/URL] (RGB lightbulb controlled via Bluetooth) and a Raspberry Pi
Spent a little while figuring out the protocol (which was actually easy as hell. Bluetooth LE is way easier to figure out.) Now have a lightbulb I can control via basic HTTP requests. Already hooked it up to my Pebble!
Far better than using their silly app, and far more fun too.
[video=youtube;1FTbeExZ7mk]https://www.youtube.com/watch?v=1FTbeExZ7mk[/video]
Has anyone here used Torque3D, and if so how was your experience with it?
[QUOTE=Map in a box;49470856]you do occasionally synchronize the clients position, and stop predicting if the client isnt' responding
[url]https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking[/url] is a good read[/QUOTE]
Yeah this read is godlike, I had same face as your avatar when I finished reading it.
I'm making a game! :D
Procedural generation, woo!
[thumb]http://i.imgur.com/cytsm1Y.jpg[/thumb][thumb]http://i.imgur.com/hg94chP.jpg[/thumb]
[video=youtube;hz0foK4nbmA]http://www.youtube.com/watch?v=hz0foK4nbmA[/video]
[QUOTE=Asgard;49471048]Have the game server collect the information about the players' move and send it to a separate server to be processed.
We can then assess what happened. It could be a bug, or someone sending a false packet. Either way, if a false move is made we disconnect the player. In our case this would cause the cheater to have a 'loss' registered to their ranking.
As some Reddit comment said that I got all this from:
We log every single d/c, cheat attempt, malformed packet, everything - some fancy machine learning later... and we build a pretty picture of how all these errors overlap.
BUGS have a distinct pattern, many clients, single location, 99% fault rate (happens every time, almost). CHEATERS are single clients (mostly! not always), many locations, a history of malformed packets, or even "exploratory behaviour".
Before you can cheat you need to understand the communication protocol the game uses to talk to itself, and to do that you need to "mess around" with the game - we log that, flag your account and put you in "quarantine" where you get monitored, we start investigating you if we have your payment information, and in rare cases open an ongoing report with the police or local authorities (paid games involved, hundreds of real dollars invested by players).[/QUOTE]
You really need to be sure that the fact real money is involved isn't illegal. You also can't revoke a legally given right to reverse engineer applications in the EU, either.
You can't revoke legally right but you can ban the user.
What do you mean by real money by the way? Buying/making hacks is not illlegal?
[QUOTE=Fourier;49471472]You can't revoke legally right but you can ban the user.
What do you mean by real money by the way? Buying/making hacks is not illlegal?[/QUOTE]
Huh? No, I meant like in the case of bets and whatnot(with his thing), which has very tight regulations in many countries. I remember awhile back someone had a csgo betting site that ended up having to get a lawyer to make sure they were within the law.
I did a thing:
[t]http://i.imgur.com/ZP5Swaa.png[/t]
I'll add a physical "enter" button onto the UI when I start UI work, because right now it is purely keyboard driven - no mouse interaction yet.
[B]Edited:
[/B]My application's "print" calls now defaults to the dev console rather than to a standard windows console.
[t]http://i.imgur.com/5wyPi3W.png[/t]
Oh, I didn't knew the context.
Yeah law is a bitch, be careful with money stuff.
[QUOTE=Map in a box;49471523]Huh? No, I meant like in the case of bets and whatnot(with his thing), which has very tight regulations in many countries. I remember awhile back someone had a csgo betting site that ended up having to get a lawyer to make sure they were within the law.[/QUOTE]
Very much so, that's why it's important to have a proper terms of service and end user license agreement
Even if not illegal. You can get caught up in tonnes of legal fees: [url]http://www.gamespot.com/articles/blizzard-sues-starcraft-2-hackers-for-selling-cheats/1100-6419854/[/url]
[QUOTE=Asgard;49471864]Very much so, that's why it's important to have a proper terms of service and end user license agreement[/QUOTE]
The TOS/EULA(eula is typically not legally enforceable in the US, by the way) won't be enough, you need to check in with the actual laws of the countries you are operating in.
[editline]6th January 2016[/editline]
[QUOTE=Topgamer7;49471923]Even if not illegal. You can get caught up in tonnes of legal fees: [url]http://www.gamespot.com/articles/blizzard-sues-starcraft-2-hackers-for-selling-cheats/1100-6419854/[/url][/QUOTE]
The selling of cheats and whatnot is legal. The defendants would have probably won in that case, but we don't know if they have gone through with it.
[QUOTE=Asgard;49471048]Have the game server collect the information about the players' move and send it to a separate server to be processed.
We can then assess what happened. It could be a bug, or someone sending a false packet. Either way, if a false move is made we disconnect the player. In our case this would cause the cheater to have a 'loss' registered to their ranking.
As some Reddit comment said that I got all this from:
We log every single d/c, cheat attempt, malformed packet, everything - some fancy machine learning later... and we build a pretty picture of how all these errors overlap.
BUGS have a distinct pattern, many clients, single location, 99% fault rate (happens every time, almost). CHEATERS are single clients (mostly! not always), many locations, a history of malformed packets, or even "exploratory behaviour".
Before you can cheat you need to understand the communication protocol the game uses to talk to itself, and to do that you need to "mess around" with the game - we log that, flag your account and put you in "quarantine" where you get monitored, we start investigating you if we have your payment information, and in rare cases open an ongoing report with the police or local authorities (paid games involved, hundreds of real dollars invested by players).[/QUOTE]
Was the game peer to peer or something? Or a client-server architecture which, for some reason or another, could potentially leak information you'd rather clients not know about?
I would've assumed client-server, especially if money is involved.
[QUOTE=Map in a box;49471929]
The selling of cheats and whatnot is legal. The defendants would have probably won in that case, but we don't know if they have gone through with it.[/QUOTE]
Except if you live in California where Blizzard won the Case against Glider(WoW bot). But only because the court ruled that you don't need to violate any copyright, in order for Glider(Cheat) to be considered DRM bypassing of Warden(Anti-Cheat).
[QUOTE=Cold;49472696]Except if you live in California where Blizzard won the Case against Glider(WoW bot). But only because the court ruled that you don't need to violate any copyright, in order for Glider(Cheat) to be considered DRM bypassing of Warden(Anti-Cheat).[/QUOTE]
Not sure about the specifics of that but that probably could have been appealed. Then again, blizzard also has copious amounts of money and can probably hamstring any prosecution against you, since most developers are piss poor and make stuff like that for fun.
So I need to write webserver that can handle 10000 get/post requests per second, now I am testing it and it seems I can get only 500 per second :v:.
Gotta tune it a bit.
[QUOTE=Darwin226;49469196]God networking makes me sad. It really seems like it rejects any elegant solution.
The only way you can prevent cheating (not even completely) is running everything on the server, but the only way you can have smooth gameplay is running everything on the client.
Maybe that would be fine if you could just reuse the same code but you probably want to spend your resources elsewhere and not recompute everything so you're settled with some shitty predictive simulation OF YOUR OWN GAME on the clients.
I've thought about making multiplayer games before and every time I would get discouraged by this.[/QUOTE]
This is useless for e.g. an FPS game other than Screencheat where the shape of the knowledge boundaries is highly confidential, but here are my thoughts on the matter:
It is possible to do everything safely on the client even if knowledge is asymmetric in some cases (specifically, if there's symmetric knowledge about what needs to be known), but it does require a little cryptography knowledge and that you can reproduce the full game after the fact. (Mutual ignorance of a certain random state isn't a problem, since you can cooperatively roll one or many dice without trusting any other party.)
The genres perfect for this are e.g. basically all (slow-paced?) card games and [I]I think[/I] all board games.
It also applies to RTS to some extent, but there the knowledge about what must be known carries quite a bit of secret information. It's still better than being able to reveal all enemy units via FoW/map hack though.
(You can limit the latter a little, but that's pretty close to the cheating protections you need for an FPS game.)
I may end up doing a full explanation at some point, but the gist is that asymmetric cryptography allows you to commit to secrets without immediately revealing them, which has a [I]huge[/I] variety of use cases.
Made a singleplayer web game about my dog Teddy called Teddy Quest. It was part of my fiance's Christmas gift and was made in just a few days. Was pretty fun to make and she loved it.
[URL="https://bombsightgames.com/games/view/6/"]Teddy Quest[/URL]
[IMG]https://s3-us-west-2.amazonaws.com/bombsightgames1/images/bsg_teddyquest.png[/IMG]
Art by my friend/artist salmonmarine.
Something little I started working on and learned to use normal maps in the process
[img]http://i.imgur.com/cTzDN38.png[/img]
Largely inspired by this soviet cartoon depicting the russian civil war that was fought mostly with armored trains. The notion of using armed trains as mobile battlebases is super exciting to me.
[media]https://www.youtube.com/watch?v=GI-K4aCqCbk[/media]
Besides, the hyper-soviet artstyle is amazing.
Fuck this Arch is too hard I'm installing debian.
After a lot of resistance I finally gave in to using Lua for a new project, due to the appeal of [url=https://love2d.org]LÖVE[/url]. Christ though, Lua lacks so many things like binary operators and goto's and it really bothers me.
[editline]7th January 2016[/editline]
[QUOTE=Tamschi;49472828]This is useless for e.g. an FPS game other than Screencheat where the shape of the knowledge boundaries is highly confidential, but here are my thoughts on the matter:
It is possible to do everything safely on the client even if knowledge is asymmetric in some cases (specifically, if there's symmetric knowledge about what needs to be known), but it does require a little cryptography knowledge and that you can reproduce the full game after the fact. (Mutual ignorance of a certain random state isn't a problem, since you can cooperatively roll one or many dice without trusting any other party.)
The genres perfect for this are e.g. basically all (slow-paced?) card games and [I]I think[/I] all board games.
It also applies to RTS to some extent, but there the knowledge about what must be known carries quite a bit of secret information. It's still better than being able to reveal all enemy units via FoW/map hack though.
(You can limit the latter a little, but that's pretty close to the cheating protections you need for an FPS game.)
I may end up doing a full explanation at some point, but the gist is that asymmetric cryptography allows you to commit to secrets without immediately revealing them, which has a [I]huge[/I] variety of use cases.[/QUOTE]
[i]That[/i] is the coolest thing I've read in weeks.
lua has goto, although you shouldn't use it because it ruins readability.
LuaJIT/PUC Lua are going to end up quite different soon I feel.. PUC Lua has pretty much ruined Lua(killing compat, removing the good bits of Lua, adding -goto- instead of continue which everyone wanted)
The only thing LuaJIT needs is continue/bitwise operators and I'd switch to using it fulltime.
Sorry, you need to Log In to post a reply to this thread.
