Things to know before you read the rest of this topic: "You" refers to anyone wanting to make a multiplayer/online/MMO/networking/etc game.
----- Part 1 -----
So I've got to get this out. You can't just go and make a multiplayer game, okay? In reality, a multiplayer game requires lots of planning. If you run straight on, you will not get the results you want. I know that from experience. I have made a multiplayer game before in Python, and to be honest, I went straight out. I got it to work and all, but after adding more features, it just stopped working. Just stopped. This is the intro paragraph.
Okay, so here are the first things you need to know about networking if you want to create a multiplayer game: Client connects to a server. An example of Client to Server is like when you open up your web browser ( web browser = CLIENT ) then type in a URL, for example, scratch.mit.edu ( scratch.mit.edu = SERVER ). The web browser connects to Scratch's web-server ( technically MIT's server, but whatever ). So every time you load a page, this is what happens:
Web Browser starts up a connection with server, once that is up, it sends a request to view a web-page, the server sends the page to the client, the connection then disconnects.
Now each step of that takes bandwidth. It can range from 1KB ( kilo-byte ) to 100MB ( mega-byte ). So if you load one hundred pages, you will use 1KB at minimum, which may not seem like a lot, but it is. You will understand later in the topic. So many of you know that loading a web-page takes time, even if it is just a blank page with a sentence or two on it. On average, for me ( Magnie ) it takes about 1-5 seconds to load a page on scratch.mit.edu which isn't to bad.
But if you are trying to run an MMO that has players changing their position every 0.01 seconds, then you will have trouble. So remove the option of using web-hosting to record the x and y positions of all your players. It's just way to slow, and since you are loading 100KB per second then system admins will get mad at you for using to many resources and they will shut down your site and your game is gone.
Now one of the many problems of chat programs now a days, is that they ask the server for new chats. That is just a waste of time and resources. Just a waste. When a new chat is sent to the server, all the clients ask if there is a new chat, the server says there is and sends the chat. But when there isn't a new chat, the server says no. Well chat programs are asking this same question every 0.5 seconds. It's like when you are driving on a trip and you ask "Are we there yet?" the driver says no until you do get there.
So instead of us asking "Are we there yet?" how about we just wait until the driver says "We're here!"? Many parents would like that. But that is how the server feels when it is asked the same (stupid) question over and over. So the way to fix that is... (guess it correctly)... to have the server tell the clients that there is a new message. We have just barely saved a *lot* of energy, both on the server's side and the client's side.
Okay, since web-requests just connect and disconnect, the server can't tell the client that there is a new message. How do we solve this problem? Well, this is where you probably have to learn a new programming language. We will solve this by having the client connect to our self-created server, not a pre-made web-server that limits us to only websites. The clients connect, send a message, then wait for a response, send a message, wait for a response, continually. It never disconnects till the client wants to.
That saves another big chunk of bandwidth and it decreases the response time between the request and response making it go faster. Now that the client is connected and always waiting for a message, it isn't doing needless work with asking the server if there is new data for it.
So now that we have this better link speed and efficiency than the web-hosting what can we do with it? Anything till you reach it's limit. Once you reach that limit, you will need a lower-level language and then you will get to the point, you can't get it any faster and you will have to wait for new technology.
Now that you have hopefully learned something it is time for me to take a break until I decide to write the next part.
-----
I could probably clarify on everything in this lecture, but what could I write and explain better? I need feedback!
Last edited by Magnie (2012-10-11 20:06:11)
Offline
Once this gets popular, Scratch Live will likely be going down. Although, on a side note I already knew most of this and I'm very bandwidth aware.
Offline
Shouldn't instead of saying this bit:
Magnie wrote:
Things to know before you read the rest of this topic: "You" refers to anyone wanting to make a multiplayer/online/MMO/networking/etc game.
Just replace all instances of that with 'one' as if you want to be more grammatically correct then that's the word you would use.
as if one wants to be more grammatically correct then that's the word one would use
Offline
bobbybee wrote:
Once this gets popular, Scratch Live will likely be going down. Although, on a side note I already knew most of this and I'm very bandwidth aware.
Yeah, people don't realize the problems with using the $_GET so often to update. Using the website to record data is only easier for things that don't need to continually update. Like forums instead of chat. Even then, people should still stick hosting their own server.
Yeah, I know many people know about the bandwidth, but I don't want people making projects with something that is slow, insecure, and very inefficient. Of course, I was the one that brought and took advantage of the $_GET function of PHP and Panther's loading URL feature which probably brought most of the projects that take advantage of those features.
rookwood101: Thanks, I'll see about getting to that.
Last edited by Magnie (2011-12-17 13:09:15)
Offline
Of course, I was the one that brought took advantage
Offline
SJRCS_011, that is not the point of this topic. Aside from bandwidth, GET requests hog everything else as well. Chances are, an unlimited bandwidth host will ban you if you truly apply the "unlimited" word.
Offline
SJRCS_011 wrote:
This is why you use a host that has unlimited bandwidth.
Also, there isn't anything that has "unlimited bandwidth" except the government (but of course, they have limited bandwidth too). Even your internet has a bandwidth limit. But even if you really did have unlimited bandwidth, it is a bad idea to waste resources like that. It makes life better for everyone if you use resources efficiently.
That's not the only problem, the speed is also a problem. It takes about half a second to make a GET request, so updating anything is slow. So no multiplayer games and if you are running a chat program, you won't get updates in real-time and you will miss some messages because you are continually updating, and if it updates too fast you won't get the correct response.
Offline
@Magnie, SJRCS_011
I have a great idea! How about you just use sockets like a normal programmer.
Offline
Is there a way to manually open and close connections with squeak code in panther, and readlines in between? maybe with a custom C block?
Offline
Magnie wrote:
Things to know before you read the rest of this topic: "You" refers to anyone wanting to make a multiplayer/online/MMO/networking/etc game.
Wow, I've always though about a multiplayer game of my own when I got banned from another one for no reason.
----- Part 1 -----
So I've got to get this out. You can't just go and make a multiplayer game, okay? :( In reality, a multiplayer game requires lots of planning. If you run straight on, you will not get the results you want. I know that from experience. I have made a multiplayer game before in Python, and to be honest, I went straight out. I got it to work and all, but after adding more features, it just stopped working. Just stopped. Well, now I know not to do it.This is the intro paragraph.
Okay, so here are the first things you need to know about networking if you want to create a multiplayer game: Client connects to a server. An example of Client to Server is like when you open up your web browser ( web browser = CLIENT ) then type in a URL, for example, scratch.mit.edu ( scratch.mit.edu = SERVER ). The web browser connects to Scratch's web-server ( technically MIT's server, but whatever ). So every time you load a page, this is what happens:
Web Browser starts up a connection with server, once that is up, it sends a request to view a web-page, the server sends the page to the client, the connection then disconnects.
Now each step of that takes bandwidth. It can range from 1KB ( kilo-byte ) to 100MB ( mega-byte ). So if you load one hundred pages, you will use 100KB at minimum, which may not seem like a lot, but it is. You will understand later in the topic. So many of you know that loading a web-page takes time, even if it is just a blank page with a sentence or two on it. On average, for me ( Magnie ) it takes about 1-5 seconds to load a page on scratch.mit.edu which isn't to bad.I knew that :D
But if you are trying to run an MMO that has players changing their position every 0.01 seconds, then you will have trouble. So remove the option of using web-hosting to record the x and y positions of all your players. Aww... It's just way to slow, and since you are loading 100KB per second then system admins will get mad at you for using to many resources and they will shut down your site and your game is gone. :(
Now one of the many problems of chat programs now a days, is that they ask the server for new chats. That is just a waste of time and resources. Just a waste. When a new chat is sent to the server, all the clients ask if there is a new chat, the server says there is and sends the chat. But when there isn't a new chat, the server says no. Well chat programs are asking this same question every 0.5 seconds. It's like when you are driving on a trip and you ask "Are we there yet?" the driver says no until you do get there. Are we there yet?
So instead of us asking "Are we there yet?" how about we just wait until the driver says "We're here!"? Many parents would like that. But that is how the server feels when it is asked the same (stupid) question over and over. So the way to fix that is... (guess it correctly)... to have the server tell the clients that there is a new message. Makes sense. We have just barely saved a *lot* of energy, both on the server's side and the client's side.
Okay, since web-requests just connect and disconnect, the server can't tell the client that there is a new message. How do we solve this problem? Well, this is where you probably have to learn a new programming language. We will solve this by having the client connect to our self-created server, not a pre-made web-server that limits us to only websites. The clients connect, send a message, then wait for a response, send a message, wait for a response, continually. It never disconnects till the client wants to.
That saves another big chunk of bandwidth and it decreases the response time between the request and response making it go faster. Now that the client is connected and always waiting for a message, it isn't doing needless work with asking the server if there is new data for it.
So now that we have this better link speed and efficiency than the web-hosting what can we do with it? Anything till you reach it's limit. Once you reach that limit, you will need a lower-level language and then you will get to the point, you can't get it any faster and you will have to wait for new technology.
Now that you have hopefully learned something it is time for me to take a break until I decide to write the next part.
-----
I could probably clarify on everything in this lecture, but what could I write and explain better? I need feedback!
Well.
Offline
After reading through your comments, I realized that 100KB is a little inaccurate (actually, really inaccurate). It's more like 1 to 2KB.
Edit: Or I just didn't read the context and 100KB is correct... whoops...
Last edited by Magnie (2012-10-11 23:57:57)
Offline
In that case, the problem is 50x not as bad as you thought it was.
Offline
LiquidMetal wrote:
In that case, the problem is 50x not as bad as you thought it was.
It still makes a new connection for ever single request. So it will take two to three times as much time to send and get the request as it would be to just receive it from the server when it's updated.
1KB (a full HTTP request) for every 0.01 would be 100KB every second. So actually, my article is correct and I just didn't read the context.
Offline
Nice guide! Maybe you should add a section about sockets, and AJAX, though.
Last edited by Hardmath123 (2012-10-12 02:06:19)
Offline
LiquidMetal wrote:
Is there a way to manually open and close connections with squeak code in panther, and readlines in between? maybe with a custom C block?
+1
If there is, it could cut down a lot on the extra kb, and be much faster, correct?
Last edited by LiquidMetal (2012-10-12 08:45:29)
Offline
Nice article, though it'd be much more useful if you actually talked about the programming languages you mentioned, and how to use them with Scratch (are we talking networking with Scratch here, right...?)
Offline
HardMath123: Possibly.
LiquidMetal: There is no sockets blocks built into Panther, but Mesh is. So you can use the Mesh blocks to open and close connections, but of course, that only supports any servers that have the RSC protocol built into them. Which are only custom servers. The thing is, HTTP requests are "static" in the sense that once you get the webpage, it won't update until you send a new request.
technoguyx: This guide is meant as a guide for any language. It's basically saying don't use HTTP for real-time multiplayer games. Though you can use pretty much any programming language to use sockets (this includes PHP). Though I guess I could make another part explaining how to use them.
Offline
That's what I assume, technoguyx.
Offline
Magnie wrote:
LiquidMetal: There is no sockets blocks built into Panther, but Mesh is. So you can use the Mesh blocks to open and close connections, but of course, that only supports any servers that have the RSC protocol built into them. Which are only custom servers. The thing is, HTTP requests are "static" in the sense that once you get the webpage, it won't update until you send a new request.
Would be possible to code that in squeak, though?
Offline
LiquidMetal wrote:
Magnie wrote:
LiquidMetal: There is no sockets blocks built into Panther, but Mesh is. So you can use the Mesh blocks to open and close connections, but of course, that only supports any servers that have the RSC protocol built into them. Which are only custom servers. The thing is, HTTP requests are "static" in the sense that once you get the webpage, it won't update until you send a new request.
Would be possible to code that in squeak, though?
Yes, it would be. http://wiki.squeak.org/squeak/325 has some examples.
Offline
Magnie wrote:
LiquidMetal wrote:
Magnie wrote:
LiquidMetal: There is no sockets blocks built into Panther, but Mesh is. So you can use the Mesh blocks to open and close connections, but of course, that only supports any servers that have the RSC protocol built into them. Which are only custom servers. The thing is, HTTP requests are "static" in the sense that once you get the webpage, it won't update until you send a new request.
Would be possible to code that in squeak, though?
Yes, it would be. http://wiki.squeak.org/squeak/325 has some examples.
Thank you!
Offline
bobbybee wrote:
@Magnie, SJRCS_011
I have a great idea! How about you just use sockets like a normal programmer.
i agree with you
_____________________________________
watch movies online @ http://themoviesdatabase.blogspot.com/
Offline