ID:151941
 Aug 30 2008, 6:34 am
|
|
Well, as you all know, HUDs tend to be a little laggy in BYOND, seeing as they are completely server-side. So I was wondering whether it was possible to program a HUD client-side, so it would only have to interact with the server when doing an action and things like displaying the HUD, scrolling etc. would all be done locally. I don't suppose there is a way to do this without some tricks. I discovered you could send data to another world, so I thought it might make sense to create a local server which interacts with a webserver, enabling you to get control over the sent data. However, I have no idea if this interface is capable of handling a big amount of sent data. So, if someone could give me a little input on this, that would be nice.
| |
Jeff8500 wrote:
I'm pretty sure the only possible way to do that would be to create your own networking using world.Export()/world.Topic() etc. Well, doesn't entirely contradict what you said per say, but since all "clients" are really servers, you could make some good use of DLLs instead of world.Export() world.Topic(), if you're willing to program the network communication on your own in C etc, that is. The upside is that you could make it much more efficient, of course. | |
No, you just use the call() proc to run a .dll that manages your connections and the likes. I didn't think of this before, but it's still relatively complicated and requires a good knowledge of C/C++, probably (I don't know how to do anything more than say "Hello, world!").
| |
call() is only executed server-side, you'd need to take that into account. A good way to think of how BYOND operates is a server (the host) with a bunch of thin clients, that relay commands from their user to the server, and draw any information they get sent back. It's actually not as clear cut as that, but I feel it's okay to think of it in those terms as a start.
| |
So the client itself would have to be a complete BYOND hostable, either way. I'm not sure whether an external dll would make the transfer any faster, if I think about it I think all things like compression could also be coded in DM.
It could work like this: - players would be able to download a client together with the game resources, there might also be a resources-updater - the server would contain a non-graphical representation of the whole game which it could encode/compress into text - when a client requests data, it will be sent a representation of an area of the map around the player which will be updated by the player's eye moving or a visual event in the shown area, in which case information about the changed objects will be sent Yes, this would take quite some effort, I'm not sure I'm going to do that, it's just an idea. | |
Transfer would be quicker through a DLL, simply because you can pick up a decent compression algorithm library and use that, plus you could happily deal in binary data for transfer, instead of straight text. You'd essentially write a Tonker toy protocol on top of TCP.
| |
Stephen001 wrote:
call() is only executed server-side, you'd need to take that into account. We were already discussing a network of multiple servers that connect to a central server, having all players run their own server for effectively accomplishing client-side processing, and since this includes DLL execution it was 'taken into account' already. =P | |
I saw, it was mainly for the benefit of other readers, mainly the "MAC address banning" ones. I suspect the biggest deal would be sensibly passing through that movement data from other clients and passing your movement data to other servers. Effectively you've left BYOND to do some game logic, and drawing, at which point you'd have to ask "If I've done everything else in C++, why leave those things up to BYOND?".
| |
Stephen001 wrote:
"If I've done everything else in C++, why leave those things up to BYOND?". Since doing otherwise is not entirely needed - and it will take 10x the time. | |
I'd suspect if you managed all the rest of it, the rudiments of 2D would not be much of a stretch. The over-bearing hammer of suitability is nearing, BYOND wasn't really designed with this kind of project in mind.
If we're going on shortest lead time and the un-bending requirement that the client must be able to draw and update it's own HUD (which I've read to be the original question to consider) for response and lag purposes, throw it together in a game toolkit like vbGore or pygame, where the toolkit's provided functionality easily permits the fulfilment of that requirement. The approach put forward involving BYOND is not particularly appropriate, a bit like shoving a cube into a round hole. It fits but does it really belong? Or course, it's entirely doable, if you are so inclined. Just as making an equivalent in assembly would be, or Java (straight or applet), Python, flash etc. etc. It's just I wouldn't, nor would I recommend such an approach to others. | |
Yes yes, it is a doable suggestion. A possible idea, but not the best one. Didn't really imply otherwise.
| |
CIB wrote:
Well, as you all know, HUDs tend to be a little laggy in BYOND, seeing as they are completely server-side. So I was wondering whether it was possible to program a HUD client-side, so it would only have to interact with the server when doing an action and things like displaying the HUD, scrolling etc. would all be done locally. I'm not sure on performance issues, since I lack a way to benchmark on different attempts in the "black box" BYOND, but as far as I understood you, maybe you could use BYOND 4.x skin feature and have your HUD realised as part of the skin. I'd suppose most of these are handled by the OS and thus as fast as possible for your computer, if realised propperly. Just a guess though. | |
How are HUD's laggy, by the way? I never noticed this.