I'm currently mulling over the idea of an (seemingly) infinate universe for Cosmic Peril. At first, I'd planned to use swapmaps to create sectors as needed, save them, and then load them again when a player returns. However, with player synchronization, this seems to be almost impossible.
What I just thought of was completely overriding the map display and spatial system Byond has built in. I would then compare the player's location with the planets, enemies, allies, and other players in their sector, displaying them accordingly. That way, I don't have to worry about going into negatives on the map, and I can probably save some resource space.
One question I do have about implementing this system, since this is really the first time I've done something like this, is how should I display the map to the players? Should I use use the client's screen or give each player a small section of the map to create the screen on?
Also, if you have attempted something like this before, please feel free to give me a few tips :D
ID:152481
 Sep 1 2006, 11:14 am
|
|
DarkCampainger wrote:
Should I use use the client's screen or give each player a small section of the map to create the screen on? Probably the latter, if you're going for speed. Screen objects are somewhat inefficient; change one part of the HUD and the entire HUD gets re-sent over the network. Apparently the drawing code is inefficient as well. This way you also get more flexibility in how you interact with objects. The downside of using map objects is that you have to create a new object for every object in each player's view. So be careful of object limits. You should probably still use SwapMaps to give each player their own bit of map. | |
Thanks for the suggestions! I'll tell you how it turns out :)
And Crispy, is there any chance of the screen's drawing code being redone in a later version of Byond? Thanks for replying, guys :) | |
And Crispy, is there any chance of the screen's drawing code being redone in a later version of Byond? Part of the motivation behind BYOND 4.0 is adopting OpenGL as the primary renderer, which uses hardware blitting instead of the software-based BitBlt(). Translated: "Yes." ;-) | |
DarkCampainger wrote:
And Crispy, is there any chance of the screen's drawing code being redone in a later version of Byond? We get OpenGL in 4.0. That should hopefully speed it up a little, but you'll still have the problem of the entire HUD getting re-sent every time you change part of it. | |
Just a question off topic here, about screen objects being resent, does that count if say an overlay is added to a screen object? May be a silly question but wanted to know anyway!
Thanks, - GunRunner | |
Yep. Any change to any object in the client's client.screen list forces a full refresh of every object in the list. It works just fine for rudimentary HUD systems, but complicated HUDs with lots of gauges, widgets, doohickeys, thumbdingers, whatchamacallits, thingamajigs, and whatsits will quickly bog down.
| |
However, if infinite space really is your aim, the individual-screen-on-map based routine works much better out of the two possibilities. You just have to remember to use an event-driven system instead of a poll-driven system for updating the screen; i.e., don't check the local area around a ship to see what its surroundings are -- have the surrounding objects report their actions to anyone or anything that cares instead. This helps minimise needless screen updates.
Incidentally, if your sectors are relatively uncomplicated (like outer space is ;-)), it shouldn't be too difficult to seamlessly load maps by preloading the surrounding sectors in addition to the current sector a ship is in. In other words, a ship can smoothly enter a nearby sector because it has already been loaded when a ship entered the adjacent sector. Many industry-level games (Oblivion and Morrowind, for instance) use this type of on-the-fly seamless loading.