As multiplayer proposals go, I'm all for the 'All Calculations on the Server End,' personally. It's the simplest proposal, won't present any serious glitches, and won't require splitscreen support. Sure, there will be input lag, but a person can plan around latency. A physics engine can't. The issue with all other proposals is that they assume lag can be glossed over, or that compression will spare them. Beam's physics run calculations 2000 times a second (0.5 milliseconds). A quick Google search says it takes a few milliseconds at minimum for any two machines to so much as contact each other, before any actual information is even sent. So before we can talk about two instances of Beamng sending physics info to one another, we'll need a connection that's capable of sending information from one computer to another computer, and then sending roughly the same amount of information back to the first computer, in less than 0.5 milliseconds. Not to mention calculating the physics and compressing/uncompressing the data on both ends. That is, if I understand the problem correctly.
Interesting read (courtesy of estama): https://fgiesen.wordpress.com/2018/01/20/network-latencies-and-speed-of-light/
If your ping was over 100ms is would be almost torture to play with someone. If someone else had lower specs than your computer, beamng would be harder to run for both users, and they would have to have the same exact mods downloaded. (I think)
It's been done before (to this day) with Nvidia game streaming-thing. Not exactly multiplayer since all the client is doing, is sharing the host's screen and 'connecting' your input devices to the host's computer. It works well, the only lag you can get is video lag (because it literally is, 'streaming') and the lag on the host's pc. (of course also regular connection lag) The Two Seat camera function is used, which can sometimes be annoying when you are driving too far away from the other player. Even then, it works incredibly well.
I just want to go cruising with my friends and their real time ghost cars in multiplayer, but even that idea was shot down long ago.
I don't know about anyone else, but I personally would only like Multiplayer so me a friend can go onto, for example, West Coast, USA and do drag racing in different cars.
The silly thing about all of this is the mere fact that multiplayer gets shot so hard every time it is brought up.... yes... it is brought up so much that we are all sick of seeing it being suggested... but in the back of all of our minds, we all want it whether we think it is doable or not. Yes, there are issues with the potential for lag and this thing and that thing and ping sucks if I live in China and you are in the USA and we try to play together or something... bla bla bla... there is literally no game (to my knowledge) that has multiplayer that has gotten around this issue. Hell... even games like League of Legends can have some pretty bad lag in it. It just becomes something that, as a gamer, we have come to live with if we have a terrible connection. Games themselves have countermeasures to try and not have the laggy player ruin things for everyone else as well... sometimes it works pretty well... other times... well... just look at laggy Forza races and you know where I am going with this. We all know the game will lag if it is put online... all games do as I just pointed out... so it makes me laugh every time this is brought up as the argument without really discussing the implications of that lag... WHY is that a bad thing. No one bothers to explain it to people as to why this is bad for a game like Beam. So... I will... yet again... I think I am gonna end up having one of these discussions in every stinking multiplayer thread on here... but if its what I have to do it's what I have to do. First though... let's start with the basics and get some stuff working. How do we transfer the data of a vehicle to another computer without it crapping out? Well, requirement one is that both computers have the same vehicles... the node and beam positions, or just about anything in the JBeam can be different or swapped around, but both computers MUST have the same models and textures with identical texture names and settings to that the vehicle can be properly loaded on both machines and actually rendered. The vehicle should not have to be downloaded from one computer to the next computer every time that someone loads another vehicle if the other computer already has all the assets for that particular vehicle... and in fact it will not, as that would be a waste of bandwidth. If you have the option added in the particular game (used to be in RoR I think) and enabled to download any vehicle that you don't have, then it will download every new vehicle that shows up on the server you are on the first time it sees it... after that, all the assets are on your computer and there will be no issues from there on out. Next step... we loaded the vehicle that the other guy has on our computer, but we don't know where it is or how its moving... plus why doesn't the JBeam matter as stated above? I am getting to that now. Beam doesn't work like most racing games/vehicle games. Most simulation racers have a body model bounding box, calculated combined spring rates for the tire and suspension as each corner of the vehicle (why most games that only have 4 wheel vehicles don't do higher wheel counts, or usually lower for that matter as it messes up their strict vehicle calculation structure), and then animated tires that follow where the wheels and tires are calculated to be. This can be seen best in Forza in my opinion as they do some of the animations incorrectly for the front wheels. If you have Forza you can try this for yourself. Take a car... any car in the game... doesn't matter... also the game doesn't matter either... 4 through 7 at least and all the horizons (well... I have 2 and 3 that both do it) and go out for a drive. Find yourself a nice open area to do this... cut the wheel all the way to one side and proceed to slowly drive in circles... not fast enough to break traction though. Swing the camera around and look at the inside front tire of the car to the turn you are making (if your turning left, look at the front left tire and same for the right). The tire is not turning anywhere NEAR sharp enough to actually make the turn that the car in game is currently doing when you do this. A couple of select race cars in the game might not do this... but to the best of my knowledge almost all the cars will. Anyways, that's how most games do it... so when doing multiplayer, once the computer knows what kind of car you have, it will now know what the hitbox for that car are and all that fun stuff on your end automagically already. The only things that need transmitted during a race now are just the position and rotation of the vehicle in question. Some games go a little further and transmit the steering angle, perhaps the gear that person is in as well... but honestly... that's about it. Usually it's just an X,Y,Z coordinate with some form of rotation coordinates (probably in Quaternion rotations to save data), plus a steering angle and a gear if you get fancy. Everything else is calculated on your computer from the sound to the squealing tires and the collision boxes of all the vehicles in a particular race. This is how most games get away with running so well even on complete garbage internet connections such as mine. Beam... well... if we were to get multiplayer working in Beam a completely different approach would need to be used. NOTE: WHILE THIS METHOD WOULD WORK FOR BEAM AS WELL it would be completely pointless to implement as there would be no damage. That's right... no damage. Seeing as that's one of Beams strongest points it seems rather pointless to implement multiplayer this way. This is similar to that modded multiplayer that you saw in a couple of previous posts. I think they just used the reference nodes for position and then just superimposed the model over it. It does work... it just isn't very pretty... and... in the case of Beam... would transmit no damage or collision seeing as there is no such thing as hitboxes in the node/beam world. This is why a different approach must be taken. So, to get this to work and to get it to work properly, the positions of all the nodes must be transmitted (ouch) as so your computer on the other end can know how to deform the mesh properly and visually show the damage... never mind contact the other vehicle... I haven't even gotten that far yet. This node position transmission can probably be done a number of ways, but the two that are noteworthy (because its all I can think of at the moment) are the brute force method.... just literally transmit every X, Y, Z coordinate of every node of a particular vehicle (if that would work with even one car I would be in shock) or the conservative method. In my head this works like this. Transmite the X, Y, Z world coordinates of the reference nodes to your game. Once you have them in game, you can now create a local coordinate system. Once you have that local coordinate system with a centerpoint, you can now user a Quaternion rotation and a vector to locate the position of each node in relation to the new coordinate system... Sure... we only dropped one coordinate, but that does reduce our data dramatically. If we are using a 500 node car (including wheels) then we just went from 1500 coordinates to 1004 coordinates... again... this isn't small by any means... but it's better than nothing... besides, there is probably a better way to do this, but I am unsure as to how you could do it much cheaper than that. The plus side of doing something like this is that if you have modified the node positions of your particular file (say you lifted the D series to a crazy height or something) then that would show up on the other computer without having to share the file. Kinda neat. Anyways, perhaps we need to drop this even further to get our data down... we could only transmite the nodes that are likely to be in contact with something, or are necessary to animate something rather specific... again, remember... we are only transmitting nodes... there is no physics going on on your computer with this vehicle as that is all being transmitted from the other players computer that already did the physics to put the nodes into the places that they are in. If we only transmite body, wheel, some suspension, and perhaps a few other important nodes, we could possibly drop that 500 node count down to around... I dunno... lets say we cut it in half... so 250 nodes now only need 504 coordinates to do a similar job. TAKE NOTE THOUGH! IF THIS IS DONE SOME DEFORMATIONS MAY END UP LOOKING RATHER ODD ON OTHER VEHICLES! This would be down to a lack of deformation node points to guide the mesh deformation of the persons vehicle you are playing with leading to some odd looking outcomes. Perhaps a node interpolation algorithm could add in some extra nodes to help guide the mesh once it has gotten to your computer, but running that kind of interpolation algorithm on so many nodes would probably A: not look good enough to be worth the effort and B: take up enough resources that you might as well be simulating the other car anyways.... Basically I am saying while you could do it this way... it seems unlikely that this would be a solution to the data issue. More than likely one would have to use some sort of a data compression to get that much data through in one shot... unfortunately I know next to nothing about that. Which brings me onto my next point. We have the vehicle in question assets and we have them displayed in game with working deformation if they were to drive into a tree or something, we could see it. However, that is all we have... we don't have any collision. That is where this mess gets tricky... See... on your computer (the one receiving the vehicle's data from the other computer) It would be very easy to just merely read the JBeam file for that vehicle, which as we clarified earlier, you already have, and add in the collision triangles which are defined in the JBeam file. Simple enough. Now you have a colidable vehicle that is only using collision triangles on your computer for physics... not too bad when you think about it. However, more than likely this is where the biggest mess comes in. As stated before, the physics engine (collisions included) run at roughly 2000 fps (so to speak). More than likely, the VERY BEST that a single vehicle being transmitted over some of our connections (like mine) might be around 30 fps? Maybe? That means, in the event of a collision, that the vehicle on our computer will go through about 66 physics calculations and position changes before the one being transmitted even updates once. That is a big problem. Remember how bad crash welding used to be? Well... Imagine that but on a scale about 10 times worse. The only way I can see how to combat something like this is to possibly interpolate the node positions based on previous data at the required 2000fps. Unfortunately, this won't fix everything... crashes would have a false amount of apparent extra energy if both vehicles were moving at a decent rate of speed... but it's better than nothing. But again... that is a lot of potential calculations for something that might not even help. Now... let's bring that lag back into the equation... imagine that while your game is running at the proper speed (I AM A GTX 1080!!!) by some magic means but your internet is garbage (potato powered router anyone?) and the updating/transmitting vehicle is only running at a pultury 5 fps... ouch. One of two things happen when a collision happens (lets say a classic head on...). Without the interpolation, the vehicles crash into each other, but on both computers, the transmitted car is in the wrong place for a solid 400 physics calculations. After those 400 calculations, each computer receives the others new coordinates... well, that is now 400 physics calculations past the actual collision point inside of each other for a total offset of 800 physics calculations. Once you start adding any amount of speed into the equation, you can easily see that it would be possible to just pass right through someone else's path without even hitting them even if you were supposed to. Now for the fun... add in the interpolation. (EDIT: Adding on to this... one thing to keep in mind when we just use the raw position data without any calculations... hilariously, since we aren't transmitting any velocity or momentum data or anything like that this way, stationary vehicles become invincible... weird quirk of this method I guess...) Adding in the interpolation makes small collisions work perfectly without a hitch, but once we start building up speed, we can basically end up with the kamehameha of crashes. Let's use our head on collision again. As the two cars touch, the proper point for the collision to take place is determined within a close enough margin of error even though the one car is only being updated at 5fps. However, once your car makes contact with the transmitted car, the interpolation will not receive updated data for another 400 physics calculations. So, rather than stopping (because remember, there are no physics being run for the transmitted vehicle) it would continue on its same path for another 400 physics calculations completely unleaded even though the exact same thing would be happening on the other computer to that vehicle. Your vehicle would be piledriven by an unstoppable force for those 400 physics calculations past the original accident. Yes, once the new data was received, the car being transmitted would snap backwards to its new damaged location, but the damage has been done. Both cars would shoot away from each other as if they had both experienced a head on collision with a bus from seemingly out of nowhere. Probably hilarious but not very realistic. Anyways, my point is that the collision is the last real hurdle to getting this kind of thing working. Everything else has been done in RoR before to rather good success. It's just that collision that has been plaguing the problem the whole time. EDIT: Alright, I didn't mean to outright kill the discussion in this thread... we can still talk about it.
multiplayer in the game sounds good. people can only switch cars that aren't used. they cannot upgrade the vehicle. racing missions/usual missions. makes game unlaggy like the multiplayer in brick rigs. these are what MIGHT happen if multiplayer comes.
It doesn't have to be 15 players or so. It can be basic co-op with at least 2 to 4 players that is perfectly enough And i believe from what i read they will try to do so
They are trying literally everything imaginable with this game, porting cars from other games without blender, artificial intelligence that not only knows its surroundings but can influence surrounding vehicles aswell, making 200+ cars from the 20ish brand models, realistic deformation engine going beyond dents and scratches, even multi seat options wher everyone gets a equal camera angle, eventually it's going to have a RoR multiplayer setup, where there might just be 6 or so vehicles, honestly, the RoR multiplayer setup would be a great first step to reach for the dev team, it features pretty seamless play, even on my potato, although it lacks player on player collisions, it still holds strong as a fun way to connect with others, as I still play it from time to time! You might even see me sometime on NHelensModded ripping up the bus driving peeps in my An-12
I think you are not allowed to do it as a mod without the dev autorization because of the security issues
i remember them saying that they wanted to focus on geeting out the story mode before they did anything else real big like multiplayer so after the story mode maybe theall start on the multiplayer who knows
i think a split-screen mode would be really cool though. --- Post updated --- like co-op, 2 player would be nice.
i didn't read the whole thing but u mentioned that cause this game uses beams and nodes over hit boxes couldn't we morph the hit boxes so that when the hit box gets hit it damages the jbeam structure in that area
Hmmm... I mean... I get what your saying... but that may end up being largely inaccurate when it comes to collisions. I am not entirely sure though.
Ok. I completely get your point, but HOLY FUCK, did you had to exaggerate that to epic proportions?!?!?! xDDD I challenge you, to LITERALLY NAME A SINGLE GAME IN EXISTENCE, WHERE YOU CAN RACE AGAINST 59 OTHER PPL, AI'S OR HUMANS. CAN'T THINK OF ONE? THAT'S BECAUSE SUCH A GAME LIKE THAT LITERALLY DOES NOT EXIST! Aside from the Crew XDDDDD. Every other racing game had at most 16 other players in a multiplayer race. The reason the crew is able to run smoothly on a fully equipped (but not particularly pimped out) pc, and even a fucking last gen console, is because there are virtually no physics systems being calculated in the game apart from basic car gravity physics and some destructible objects. But I digress. You do have a point though. It takes a fucking beast of a computer EVEN TO THIS DAY, to run beamng on max settings, with just ONE SINGLE CAR spawned. So doing basic math, you would literally need 50 TIMES THE COMPUTING AND GRAPHICS POWER to be able to smoothly render a race of 50 individually physically simulated vehicles, ALL IN REAL TIME, JUST TO GET THE GAME TO RUN SMOOTH IDLY! X'DDDD
this is bait however, i would like to take this opportunity to remind people that infiniband exists, giving sub-microsecond latency and 5.6GB/s (yes, gigabytes per second) of throughput at under $150 in used hardware on ebay devs, take note x d
