May 21 2012, 5:55 am
|
|
Stephen001
  |
I don't, but I may just have access to a game with a large player base (~100 on a server) that may elect to experiment a bit for us, I'll have to have a chat and see.
|
Stephen001 wrote:
I don't, but I may just have access to a game with a large player base (~100 on a server) that may elect to experiment a bit for us, I'll have to have a chat and see. That would be great. Please keep me informed. I actually have money to spend on making a game and I am taking this seriously. | |
I think this is getting a bit off-topic, but you surely haven't dealt with network programming as it is in the real professional game industry.
For one, thing, in a real-time multiplayer online action game, they don't use TCP. It simply isn't an option if you want the game to run smoothly. A good article about TCP and UDP. On the other hand, I can't completely disagree with you about BYOND games. None of them are fully 3D massively-multiplayer action games. So, maybe with BYOND it is fine to send 100 packets (1 per player) per frame. I haven't tested this, because I don't have a game with that many players that runs at more than 10 FPS. Also, I don't know if 'network programmer' is a real title, but people who do that job are few and far between. Having that on your resume really singles you out as a unique programmer. Every response you've given me so far seems to show a great lack of actual research. Just sayin'. | |
Complex Robot wrote:
Also, I don't know if 'network programmer' is a real title, but people who do that job are few and far between. Having that on your resume really singles you out as a unique programmer. It is not a real title; having it on your resume would single you out as someone doctoring their resume. There is such a thing as a programmer who has worked extensively with low-level network code, and I would wager they're less common than regular garden-variety programmers, but that's about all you could say. | |
Complex Robot wrote:
Every response you've given me so far seems to show a great lack of actual research. Just sayin'. Here are the two points I'm making: 1. Sending updates every frame is often necessary because BYOND's game client (Dream Seeker) can't make any assumptions about what's happening in the game to fill the gaps between updates. Nearly everything that happens in the client is driven by an update from the server. Other games can have the server tell the client "you started casting a spell" and the client knows to show the spell casting timer and fill the progress bar up over time. With BYOND, all of those things are driven by updates from the server. 2. Computers can handle sending more than 10 updates per second. I can't find a post where people talked about dropping their game's framerate to 2 fps because they couldn't handle 10 fps. If games have worked fine at 10 fps for the last 10-15 years, they'll run fine at 20-40 fps today. For #1 that's just how BYOND works. For #2 it should be obvious that computing power has improved since the late 90s. I can find some sources and cite them if you'd like but it shouldn't be necessary. Lummox JR wrote: There is such a thing as a programmer who has worked extensively with low-level network code, and I would wager they're less common than regular garden-variety programmers, but that's about all you could say. That's because most programs use existing protocols. You can easily write an application that communicates over a network without writing any code that deals with the actual communication. You're just putting the payload in the message - the means to send and receive the message is handled for you. There aren't a lot of cases where you're writing completely custom network code, so if you find that you are, it probably means that you're doing something wrong. The hard problems in networking tend to be at the lower layers, not at the application layer. Using TCP or UDP to send data for a computer game is a simple and boring problem. As computing power and network performance increase it only gets more boring. If you're looking for a job that deals with computer networking, The interesting problems tend to be in the hardware or lower software layers, or in security. | |
All right.
I follow what you're saying. I agree on both points for the most part. However, I'd like to mention on #2 that it's not just one packet per frame, it's one for every player. But, most likely two, one to the server from the client and one from the client to the server. (I assume there's more from server to client for sending updates.) And on #1, it's not always necessary to send an update every tick, especially if nothing has changed, or if it can be inferred by the client what is going to happen next. I agree that with BYOND's system where anything can happen every tick and everything happens on the server, there's probably no way they can get around sending so many packets. But, BYOND aside, it is generally bad practice to do so. This is mostly because the client itself can do a lot of processing on its own, and it should be doing as much as it can. And just so I know we're on the same page, you have to agree BYOND's way is not the only way an online multiplayer game can be done. Forum_account wrote: The hard problems in networking tend to be at the lower layers, not at the application layer. Using TCP or UDP to send data for a computer game is a simple and boring problem. As computing power and network performance increase it only gets more boring. If you're looking for a job that deals with computer networking, The interesting problems tend to be in the hardware or lower software layers, or in security. I don't know anything about the lower-level programming, so excuse my ignorance. But, there's quite a bit to be said about debugging and testing a networked application, especially one made with UDP. With a normal program, you can do run-time debugging and step through your code one line at a time, viewing variables and watching everything happen. Debugging and testing these offline programs seems very easy when you compare it to debugging networked applications. With a networked application, you often need multiple people to test it, and you don't have the same luxury for debugging. So, sometimes bugs are much harder to find and require a lot more thought. And another part of it is deciding what to put into the packet so that enough information is sent without bloating the packet. All of this is very scientific and nothing that, I personally, consider boring. I never said I was a 'network programmer' as apparently it's a heinous thing to declare yourself as, but what I mostly meant when I was talking about that is someone who has extensive knowledge on programming online multiplayer games, and enjoys the formulating, debugging and testing of such applications. Whatever the hell you want to call it, that's my definition. | |
Complex Robot wrote:
However, I'd like to mention on #2 that it's not just one packet per frame, it's one for every player. But, most likely two, one to the server from the client and one from the client to the server. (I assume there's more from server to client for sending updates.) I'm not sure what you mean there. I expect that Dream Seeker only sends messages to the server when the client performs an action (ex: triggers a macro or mouse proc) and that one packet is sent per tick (if you trigger two macros at the same time, one message is sent). This would mean that players could make their game client send one message to the server each frame but it's not likely that the player is constantly mashing keys that quickly. With a networked application, you often need multiple people to test it, and you don't have the same luxury for debugging. So, sometimes bugs are much harder to find and require a lot more thought. For debugging you only need to verify the data that's being sent and received. Once the data is received you call a method to do something but that method can be tested separately (the method doesn't care if it was invoked because you actually received a UDP packet or because you simulated the receipt of a packet). Since you just need to check the data that's being sent and received, you can use a tool like Wireshark or just log all data that is sent/received and review the logs. This also assumes that you're writing the code to format/parse the data being sent. Many programs use existing protocols so this isn't a concern. The network connections and object serialization/deserialization are handled for you so it's rarely something you'd have to debug. And another part of it is deciding what to put into the packet so that enough information is sent without bloating the packet. If the server has to tell a client they took damage, you just have to tell them. The packet size doesn't matter. That information is important and has to be sent. When you think about the amount of data that some programs deal with and transmit over a network, the amount of data used by games is insignificant. If you're looking to make a career out of it, I don't think it's a complex enough problem to just focus on the networking code in multiplayer games. | |
So I played the monster kingdom demo when it was up, and their fps was set to 100. Everything seemed to be alright. I don't have any actual data, I just logged in and played for a bit. It was working fine as far as I could tell.
| |