Remix.run Logo
brcmthrowaway 3 days ago

Is there any bullet propf open source middleware for this any more?

dividuum 2 days ago | parent | next [-]

There's enet (https://github.com/lsalzman/enet) or something like naia (https://github.com/naia-lib/naia) which supposedly uses ideas from the old (but very reliable back in the day) networking of the game Tribes 2 (https://github.com/nardo/tnl2 / https://www.gamedevs.org/uploads/tribes-networking-model.pdf).

gregoryl 2 days ago | parent [-]

Thanks for those links; quite enjoyed the tribes networking model read especially, having played unreasonable amounts of Tribes 1 back in the day.

CodeArtisan 2 days ago | parent | prev | next [-]

GameNetworkingSockets from Valve. Maybe not middleware enough? You have to implement the serialization and a state update strategy yourself.

Reliable & unreliable messages over UDP. Robust message fragmentation & reassembly. P2P networking / NAT traversal. Encryption.

https://github.com/ValveSoftware/GameNetworkingSockets

shdh a day ago | parent [-]

Yep, you will need to implement your own serialization and snapshot system with GNS.

javaunsafe2019 3 days ago | parent | prev | next [-]

What are you even asking?

flohofwoe 2 days ago | parent | next [-]

Could be related to the 'disappearance' of RakNet, which at some point in the past was *the* go-to networking middleware for games (because it implemented a flexible guaranteed-vs-nonguaranteed and ordered-vs-unordered protocol on top of UDP) until the author sold the library to Facebook and essentially vanished (and Facebook letting the library rot).

klaussilveira 2 days ago | parent [-]

RakNet is still somewhat alive: https://github.com/SLikeSoft/SLikeNet

burnt-resistor 2 days ago | parent | prev | next [-]

There was the q3 client and the q3 server. It was point-to-point but could be hosted on the internet. There was no "middleware" except for locally-hosted aimbots for cheating by rewriting the cheater's client packets using a socks proxy... obviously not sportsman-like nor fun for anyone else.

PS: I had 7 ms ping* to a Q3 server at Stanford but I still sucked, unlike one of my college roommates who stuck to Q II and the railgun and was quite good.

* Verio/NTT 768kbps SDSL for $70/month in 2000-2001

eertami 2 days ago | parent [-]

Funny how 7 ping was phenomenal 25 years ago, but now it is the minimum expectation (in WEU). I expect my ping to always be 7 or less (in CS:GO). I don't play on MM servers if the ping is more than 10.

Thaxll 2 days ago | parent | next [-]

Even in the same city most people won't have 7ms, not sure where that number comes from.

skhr0680 2 days ago | parent | prev [-]

Isn't ping mostly determined by the physical distance between you and the server?

burnt-resistor 2 days ago | parent | next [-]

Sort of, but not precisely. In practice, it really depended on the slowest link's maximum single-channel bandwidth*, oversubscription ratio of the backhaul(s), router equipment and configuration like QoS/packet prioritization... and then it also depended on internet traffic at the particular time of day.

In my case, I was 3-4 hops away and 34 mi / 55 km straight line distance, 110 / 177 driving, and most importantly roughly around 142 / 230 of cable distance approximately by mapping paths near highways in Google Earth. I doubt the network path CalREN/CENIC was used because it never showed up in hops in traceroute (although there was nothing preventing intermediaries from encapsulating and transiting flows across other protocols and networks), but it definitely went through PAIX.

* Per technology, zero-distance minimum delay is a function of the single maximum channel bit rate and data size + lower layer encapsulating protocol(s) overhead which was probably UDP + IP + 1 or more lower layers such as Ethernet, ATM, ISDN/frame relay BRI/PRI, DSL, or POTS modems. With a 1 Gbps link using a billion 1 Hz|baud channels, it's impossible to have a single bit packet latency lower than 1 second.

shdh a day ago | parent | prev | next [-]

Due to how most FPS games are implemented you are actually seeing other entities in their past state.

What happens is the game will buffer two "snapshots" which contain a list of entities (players, weapons, throwables, etc.) and it will linear interpolate the entities between the two states for a certain period of time (typically the snapshot frequency).

The server might have a "tick rate" of 20, meaning a snapshot is created for a client every 50ms (1000ms / 20 tick rate).

The client will throw that snapshot onto a buffer and wait for a second one to be received. Once the client is satisfied with the number of snapshots in the buffer, it will render entities and position them between the two snapshots. Clients translate the entities from the position of the first snapshot to the position of the second snapshot.

Therefore even with 5ms ping, you might actually be seeing entities at 55ms in the past.

fragmede 2 days ago | parent | prev [-]

Depends on the location of you and the server. Obviously it can't go faster than the speed of light, but it can go much slower, since it doesn't go add the crow (or photon) flies, and more of in a zig zag path, and it has to traverse several photon/electron translation hardware hops (aka routers and switches), and there's typically some packet loss and buffer bloat to contend with as well. The speed of light in fiber is slower than in a vacuum, to be fair, but the latency you experience is marred more, not by the raw speed of the photon in fiber, which is still quite fast (certainly faster than you or I can run), but by all the other reasons why you don't get anywhere near that theoretical maximum speed.

From me to Australia should be ~37 milliseconds if we look at the speed of light, but it's closer to 175 milliseconds (meaning a ping of ~350). Nevermind the latency of being on wifi adds to that.

https://www.pingdom.com/blog/theoretical-vs-real-world-speed...

Hikikomori 2 days ago | parent [-]

There are many problems with this article, it's for laymen so simplifies things but it's also factually incorrect. Fiber is usually next to roads or railways, which usually do not zigzag. Modern router/switches have a forwarding delay of micro/nanoseconds. The beam in a single mode fiber does not bounce like a pinball, it doesn't bounce at all, hence the name.

Ping is largely a product of distance and the speed (200km/s). It's not the distance a bird would fly but it can be close to it sometimes. And then the internet is a collection of separate networks that are not fully connected, so even if your target is in the next building your traffic might go through another bigger city as that is where the ISPs peer.

burnt-resistor 2 days ago | parent [-]

You're still missing many other significant factors besides distance. There are many conditions that affect latency, but on the minimum theoretical value possible, it's mostly dominated by the slowest path technology's single channel bandwidth. The other factors that reduce performance include:

- Network conditions

- High port/traffic oversubscription ratio

- QoS/packet service classification, i.e., discriminatory tweaks that stop, slow, or speed up certain kinds of traffic contrary to the principles of net neutrality

- Packet forwarding rate compared to physical link speed

- Network gear, client, and server tuning and (mis)configuration

- Signal booster/repeater latency

- And too many more to enumerate exhaustively

As such, point-to-point local- and internet-spanning configuration troubleshooting and optimization is best decided empirically through repeated experimentation, sometimes assisted by netadmin tools when there is access to intermediary infrastructure.

Hikikomori 2 days ago | parent [-]

I wasn't enumerating all sources of latency. I wrote largely, as after some amount of distance all the other factors are not really relevant in a normally functioning network (one without extreme congestion).

Fade_Dance 3 days ago | parent | prev [-]

maybe they mean solid open source netcode? Call of Duty famously used Quake 3 net code for a while. That engine was a great core to build from since Carmack made such solid stuff.

But then again, they're probably just a bot.

skhr0680 2 days ago | parent | next [-]

AFAIK (remember) Call of Duty was built on a modified Quake 3 engine long before it went open source

newsclues 2 days ago | parent [-]

IW Engine is based on the RtCW version of the id Tech 3 (Quake 3) engine they licensed.

brcmthrowaway 2 days ago | parent | prev [-]

What does Call of Duty use now?

bananaboy 2 days ago | parent [-]

Custom code still derived from q3

shdh a day ago | parent [-]

Its likely that every component of the engine has now been swapped out and almost no Q3 derived code exists.

bananaboy a day ago | parent [-]

Yeah I know, I work for Sledgehammer Games on cod. It's not that it's been swapped out, it's been rewritten and rewritten many times over the years. What I meant to imply (but didn't succeed in saying) was that for systems that were in q3a, if you knew the q3a code, then you would feel a sense of familiarity with those parts of the cod code.

I occasionally do some random spelunking for fun and while there's practically no code left, there are still a few small remnants like the odd comment or function signature (or partial signature) that are still there, and some that even date back to Quake 1!

shdh a day ago | parent [-]

That's really cool, thanks for sharing that information!

EarlKing 2 days ago | parent | prev | next [-]

[flagged]

imafish 3 days ago | parent | prev [-]

That’s a good question. Are you a bot?