As I continue to be just about to work on high-score/screenshot server(s) for DragonSnot, I had another question come to mind:
Will a server .dmb, accessed through Import(), show up on the hub as a game in progress?
And more on the multi-tasking abilities of servers...I need to figure out whether to have one server for both high-scores and screenshots, or to split them to reduce potential lag/bottlenecks. Tom explained some of this, and I think this might not be an issue, but I still want to make sure I understand.
Say three players decide to upload screenshots at around the same time (it can take a couple of minutes to upload one so this may not be uncommon) and in the meantime another two players submit their scores for high score consideration.
Will the server .dmb handle all these at once? Will it simply slow down some while the multiple screenshots come in?
Given the heavy-weightness of screenshot stuff, should I do that as its own process to keep the more common high score reports from being delayed?
ID:154586
 Jan 4 2001, 12:01 pm
|
|
On 1/4/01 4:14 pm Tom H. wrote:
In my experience, it seems like this simulates multitasking enough so that it is pretty seamless. But the best way to see is to try some alternatives and test it out. Sorry if that doesn't answer the question! Well it answers the technical question...of course it's hard to answer where I should have multiple servers or not without actual testing with multiple people submitting stuff. My worry here is say that 100 people started playing DragonSnot on a somewhat regular basis and it turns out we have big bottleneck problems requiring us to do a different server strategy, requiring everyone to re-download the game... Well, I guess it would be a good problem to have and it is just a big welcome to the headaches of internet based games! It does mean we might post-pone a 1.0 until da community has had time to pound on this some more. I want 1.0 to Just Work. | |
Will a server .dmb, accessed through Import(), show up on the hub as a game in progress? I think you mean Export(). The answer is no, because it doesn't have players directly connected to it. And more on the multi-tasking abilities of servers...I need to figure out whether to have one server for both high-scores and screenshots, or to split them to reduce potential lag/bottlenecks. The main issue here is processing time to service each Export() call. As Tom mentioned, the data transfer itself is split between all the users, and you can't increase the bandwidth of the machine by creating more processes. So, in the case of screenshots, it boils down to how much time it takes to dump each incoming packet to the disk. If you had thousands of simultaneous connections, that might start to become an issue, but until then, I wouldn't be too concerned about it. (Bring 'em on!) Only if your world.Topic() had to do a big CPU intensive calculation would I worry about user load. In that case, you might have to spawn off or segregate the intensive sub-processes so lighter ones could still fly through. --Dan | |
You mentioned the headache of having to distribute new executables to all your players. That is something I think the new release (272) deals with very well. (In fact, at this moment, the distribution method for DM software is more advanced than BYOND itself!) However, I am still preparing to add an important feature--that is an option for having paid subscriptions. You could add the players who order DragonSnot to the subscription list (or let them subscribe through the hub) and distribute your software through that mechanism. It automatically informs about version updates and offers to download and install the new software. Right now, that message only comes if you host a game from your PC on a network port, and it detects that you are using an older version than the one registered at the hub. In general, I like the model that you are developing with DragonSnot, in which the ability to host a game on your own machine is considered a thing of value. It scales really well, because it actually becomes more valuable the more popular the game gets! (Since the central site would start to get too congested.) I think this model has the potential for very rapid growth with minimal costs. An additional advantage that helps keep the cost down is that there are still some valuable centralized services, such as automatic version updates, hubfiles, score lists, and the Live! list. If you choose to make any of these available to subscribed users only, you don't have to worry so much about copyprotection, since buying a subscription would give one more value than just a copy of the game (which could be obtained on the black market!). That allows you to distribute the game for a ridiculously small sum and just shoot for popular appeal. --Dan | |
On 2/11/01 6:44 pm Dan wrote:
You mentioned the headache of having to distribute new executables to all your players. That is something I think the new release (272) deals with very well. (In fact, at this moment, the distribution method for DM software is more advanced than BYOND itself!) I am burned out from my massive week of programming (which had good results, thankfully!) -- so tonight I think I shall play. Tomorrow, though, I will check out this new stuff! An additional advantage that helps keep the cost down is that there are still some valuable centralized services, such as automatic version updates, hubfiles, score lists, and the Live! list. If you choose to make any of these available to subscribed users only, you don't have to worry so much about copyprotection, since buying a subscription would give one more value than just a copy of the game (which could be obtained on the black market!). Ah a very good idea...right now DragonSnot does not do a check for subscription upon submission of a score from a remote game, but it certainly could do so. That will be part of the next update. That allows you to distribute the game for a ridiculously small sum and just shoot for popular appeal. That's what the DDT is shooting for! | |
Good question. I believe (and Dan can correct me on this) that hub will by default display any games that have players logged into them. You can control this behavior by setting the world.hub variable, though. That might be in the current documentation. Dan just did a major doc update so it will at least be available soon.
The more data you are sending over the network, the laggier things will be. However, since the data is transmitted in chunks, you shouldn't have to worry about an immense lag between operations just because you happen to be sending, say, a large screenshot. For example, when player #1 sends a huge screenshot and player #2 follows up with some command (sent across the network) #2 doesn't have to wait for the #1 to completely finish before anything happens. Instead, the server will receive a chunk of #1, a chunk of #2, etc.
In my experience, it seems like this simulates multitasking enough so that it is pretty seamless. But the best way to see is to try some alternatives and test it out. Sorry if that doesn't answer the question!