Ambiera ForumDiscussions, Help and Support. |
|
| [ 1 2 3 ] Page 2 of 3 |
|
|||||
|
As I stated, I wrote many different types of multiplayer scripts with CC4 , 5 & 6. One of the other methods that I used was simply saving the data in a text file, encrypted, however and using compiled language to send the data to the server. When I open sourced "The Mech Project" multiplyaer script in 2017 within this community... well, it was coppied...Maybe not the code, but the methodology... It should still be floating around somewhere. There were many downloads. |
||||
|
A the time there were only two multiplayer scripts... One, which was a web GL Demo that moved two blocks around the screen and mine... Mine was and still is the most advanced script that was written. It had everything from shields, health, animation controls, weapon pickups, health pickups and much more... But because of people attacking me all the time... I deleted the code and shut down the project. |
||||
|
What udp have to deal with it? You don't get any response with TCP - it's a transport protocol. It only provides data transfer channels, and doesn't have any request-response interface. Telnet, websocket, http and 9000 overs are application layer protocols which are build over tcp, and use tcp to send data. Imagine there is a bridge across the river. Your house is on one side and your favorite pizzeria is on the other. So in order to bring a pizza for a party at your house you need to cross the bridge one way(request), buy pizza and get back (response). You can either take a byke, car or either go on foot to cross it. Bridge is your freaking TCP and your byke (or in your case a diy skateboard) is your telnet, or whatever you use. So, the flow for now is: 1. You spawn cmd (takes time) 2. You spawn curl (+ adds more time) 3. You write to file (+ adds more time) 4. You read from a file I have issues with that: Firstly, do you realize, that the main advantage with an established TCP connection is that you don't have to establish it every time? Every time you spawn a cmd you establish a NEW CONNECTION, which takes additional time. Secondly, how many times in a second should I write to a filesystem? What if the game is installed to a slow hdd? Also the file is usually gets blocked if it's opened in another application - this means I will receive read/write errors here and there. Anyway, this approach is just not good. I would rather use a built-in http client, at least it doesn't jerk off the hard drive 60 times per second and doesn't have errors with blocked files. Or just build electron + webgl, and use websocket if I need a more reliable connection. Anyway thank you for the clarification - I guess, I've learned anything I needed. |
||||
|
I have already explained all of the above... I am not explaining it again. ...go through the thread... I am not going to bother responding again. |
||||
|
Also... I have built an https client...and I have used my methodology... Mine works instantly. You are just plain wrong, https is very slow and any real developer reading this thread would understand that... Actually, just ask any AAA game developer whether they use TCP OR HTTPS to network... Actually ask blizzard... They use TCP for world of warcraft. Google it. Nobody seriously consciders using https for ultiplayer games because it has an average delay of about 0.5 ms on most connections and TCP has a delay of about 0.003 seconds. UDP is faster then TCP... So use that if you want...but seriously, no serious game developers us https for networking |
||||
|
If you ask any decent developer they will tell you that they work with either tool that does the job or a tool requested by a customer. It doesn't matter if you use TCP or UDP, or if you send your requests with doves - there are other downsides: 1. You use proxy application to perform the request 2. You create a new TCP connection on every call 3. You use filesystem as IPC bridge Now you're throwing some random numbers from top of your head. Even if you're request takes 0.003 seconds, you should add: time which takes to open cmd, time which takes to call curl, time to establish the connection, time which takes writing the response to a file system, time to read a file from the filesystem. I don't think there is any commercial game on any engine which work that way. Actually, with your approach with coppercube you want be able to get a response from a server faster than in ~16ms. As you execute system call, due to the latency, you'll have to wait for a next frame in order to read the file content. Another analogy to make you understand my point. Imagine there is a guy who once heard that it's really important to stay hydrated. But instead of drinking a clean bottled or at least tap water he starts to drink from a muddy puddle in his backyard. And now he convinces other guys who prefer cola, that they also should drink from the same puddle, since drinking water is healthy and drinking cola is not. |
||||
|
again, you are not reading my posts...again, I have explained all of this and why you are wrong...again, I am not the only developer that uses TCP and UDP....Many developers have done this... and finally, you only need to open the CMD once on load if you want to use a batch file to execute the encrypted data and send to the server and no... You are not using logic again CMD was designed for 386 computers before windows... CMD is impossibly fast for IO and networking calls... CMD was designed to run on computers with memory of 12kb... Please stop trying to be smart and actually make a real argument... FYI - I was the first person to use this method and many people have coppied it in CC...There are templates available...go and try them out yourself before you come here trying to convince a developer with 20 years experience that https is faster then UDP & TCP - what a laugh |
||||
|
You already have my arguments: 1. You rely on a 3rd party application, which make your system more complex and overall does the same. You, probably, heard of KISS, you're breaking it for no reason. 2. You not using TCP properly - you should establish a connection and transfer data through it. In your case, you open a new connection every time you need to send a request, and this is not how it's designed to work. 3. You're using filesystem as IPC which I don't like for many reasons. Please feel free to google why you shouldn't do that. I only heard the following from you: 1. TCP if "faster". So what? This advantage will be diminished by the network latency and server processing time. Though, you also do not use tcp properly. 2. All AAA studios use raw TCP. So what? Why don't you use UE? most AAA games use it and there is not a single AAA title which uses CopperCube. 3. CMD is old and fast? So what? I'm not telling you it's slow, I'm telling you, it's another tool which takes time to start and execute curl, which also adds up to the request send time. It also means you need to save a response to the filesystem, and then read it from there. And due to how coppercube works you will be able to read the response only on the next frame (~16ms with 60fps) after you've send corresponding request; 4. You have 20 years of experience? So what? Software development is a vast area. 20 years of web development with php will not make you an expert in low level network programming. How many years of relevant commercial experience do you actually have in this area? It's not about http being "slow" in general, it's about your approach to be a huge smelly workaround, which is not better than a built in tool for the reasons mentioned above. |
||||
|
Anyways, Mysql uses TCP.... Just use this command to connect to database... mysql.exe -u[username] -p Run some queries and save the results in txt through cmd. |
||||
|
Anyways... I am not arguing anymore. All my methods work. I have tested them all I was the first person to build a real multiplayer game in this community that did more then just move two cubes around...your oppinion does not bother me |
||||
|
Also, you invented point 2 above...I never told you on the exact algorithm that I used Your TCP argument is ridiculous...shows how amateur you are... Does not matter if you are using https , ftp or tcp...all responses slow down based on the server algortyhms |
||||
|
Sure they do - this doesn't change the fact these are smelly, not reliable workarounds. |
||||
|
Thanks for all the input upfront. I don't want to re-open a harsh discussion - but I'm wondering what would be the fastest/best option to create a Multiplayer setup on a Server based WebGL game? Happy Holidays to all! Update: I've found jaime's multiplayer here: https://jaime.zegpi.cl/lab/coppe... + https://github.com/jaimezegpi/mu... Huge thanks @jaime for sharing this Indeed this does run with "ccbDoHTTPRequest" and beside the fact that I really like it - it's kinda slow for "realtime/fps" action. You can open two instances of it; when your "characters" are close enough you will see a small "cubic" symbol on the ground - latency ~ 1-2 seconds. Any idea how to create a fast multiplayer setup within WebGL/server? |
||||
|
My guess would be websocket. But I'm just slightly aware of these socket.io apps; how's about doing it self-hosted? Any idea...? |
||||
|
Hi gree, for webgl it's websocket definitely. Check https://docs.replit.com/tutorials/build-tictactoe-with-websockets-kaboom. It's for kaboom js, but the idea is the same. |
||||
| [ 1 2 3 ] Page 2 of 3 |
|
|
){kind=link}