Is there any way to get around the 64k compile time limit? I have a rather expansive game with a large map, and it will be very hard not to surpass these limits.
I can't use areas because I already rely on areas in all parts of the map.
ID:157425
 Mar 13 2010, 11:34 am
|
|
Garthor wrote:
You do not actually need 64,000 objects. Not really, I easily exceeded that limit on a single z layer of a 400x400 map by outlining/sectioning parts of it with 3x3 object trees. And BE2 has nearly 20k shadow objects alone. With the mapping limitations of BYOND it doesn't leave you much choice in some of situations | |
Just because you're doing silly stuff like filling literally half the map with trees does not not mean that you actually need 64,000 objects.
| |
And chances are you don't need all those loaded at one time (as that's an absolutely ridiculous number to have, by-the-way), and probably a good bit of that is due to you not knowing how to elegantly do it. A lot of stuff could be randomly generated as needed, I imagine, and other stuff could be done with loading and unloading maps at runtime. You don't need that many things at one for your typical game.
And don't go on how your game is atypical. | |
But in my case, my game IS in fact atypical, and any statement otherwise would be dubious and without veracity. Telling me not to go on about my game being atypical is relatively ignorant, as you're automatically ranging the depth of my game without even knowing about it and precluding the possibility of it being in-depth. (Or at least much more so than a majority/all other games of its genre.)
Rather than try to insult me/my game, why not just suggest some of these "elegant" ways to go about what I'm trying to do? The fact of the matter is that I do need a very large amount of objects, regardless of if you think so or not. | |
Ninjafro wrote:
But in my case, my game IS in fact atypical, and any statement otherwise would be dubious and without veracity. Telling me not to go on about my game being atypical is relatively ignorant, as you're automatically ranging the depth of my game without even knowing about it and precluding the possibility of it being in-depth. (Or at least much more so than a majority/all other games of its genre.) Chash chash chasm, it be suggestion of that I am all told decrepit to the stunning capacity of your accessible-by-computer language reference book. Mitigate me whilst I shrink in consternation at this capability you maintain.* Rather than try to insult me/my game, why not just suggest some of these "elegant" ways to go about what I'm trying to do? The fact of the matter is that I do need a very large amount of objects, regardless of if you think so or not. No, I know you don't need that much. Shadowdarke's Darke Dungeon project is effectively infinite in size, and it doesn't need 40,000-some objects, or whatever it was you said. You're just ignorant of the proper ways to handle this stuff. I'd tell you some of these "elegant" solutions, except 1) I've already told you several, and 2) I don't know what your game is. *<font size=1>Well well well, it seems I am quite weak to the awe-inspiring power of your online thesaurus. Excuse me while I cower in fear at this might you possess.</font> | |
You haven't described any way with which to go about what I am trying to do. Don't thank an online thesaurus for my prodigious vocabulary. Thank my superfluously prolific English teacher. ; )
| |
So it most likely comes from a physical thesaurus. How quaint.
Anyways, I mentioned several ways here, if you could be so assed to read. Chances are, though, that you can't actually implement these methods given that you are a programming novice, but that doesn't make them any less available (especially since one of them has multiple libraries open to you). And I also have great doubts that your game is ~~~atypical~~~. What you've said so far just seems to reenforce that. | |
Popisfizzy wrote:
So it most likely comes from a physical thesaurus. How quaint. This conversation made me laugh out loud. Repeatedly. To the point: You cannot bypass the compile time object limit. For the time being, that is fact, and no amount of fancy words will change it. Pop provided you with a few alternative ways to approach this issue. Even if you choose to randomly generate parts of your map, you will still need to load/unload it dynamically. This can be done through the use of multiple libraries. DMP Writer and DMP Reader allow you to save your maps in the same format that BYOND does. This can be very helpful in a few ways, such as being able to make the maps using BYOND's built in map makers, and edit them after being saved in the same fashion. There are other libraries that serve this purpose, though I believe the two listed are the only ones that actually use BYOND's own map format (do not quote me on this. I in no way claim that what I'm saying is actually accurate) | |
I got bored of this thread around superfluous post #3. Once the vocabulary e-peen contest started, I sort of stopped reading.
That being said, I believe what everybody else is trying to tell you (And is too put off by your insistence of knowledge otherwise to actually help you properly), is that you don't NEED to have everything loaded at once. A pre-set map of that scale with that many objects at once is just wasteful. You really ought to try exporting your map sections, and loading them upon need. There are numerous DMP loaders out there, so just look up the topic of map loading/saving. This does open a whole new can of worms, though, in the subject of efficiency, etc. | |
Ninjafro wrote:
Finally. A solution. Thank you, good sir. I'd like to take credit for suggesting the first solution, but as noted by Pop, he did mention solutions here Granted they were mild and not entirely thorough, but a bit of assertion on your part would have lead you to where I directed you. :) Pop may be a bit coarse around the edges but you'll find (much to the dismay of those who argue with him) is he is often correct. | |
Ter13 wrote:
I got bored of this thread around superfluous post #3. Once the vocabulary e-peen contest started, I sort of stopped reading. I thought it was funny. That being said, I believe what everybody else is trying to tell you (And is too put off by your insistence of knowledge otherwise to actually help you properly), is that you don't NEED to have everything loaded at once. A pre-set map of that scale with that many objects at once is just wasteful. ^ Even a preset map of smaller proportions is wasteful. You really ought to try exporting your map sections, and loading them upon need. There are numerous DMP loaders out there, so just look up the topic of map loading/saving. This does open a whole new can of worms, though, in the subject of efficiency, etc. On this topic I'd suggest loading the map in small bits, delayed out to not cause lag. | |
Setting the map loading to a background process will alleviate a lot of the problems, this opens up a lot of issues with players being able to walk into unloaded segments of the map. This can be solved by locking the player in place for a short time while waiting to teleport to an unfinished layer.
There is also the issue of unloading areas to free up resources. You're going to have to write a system to determine which layers are in use, and which layers reference each area. You're also going to have to write a method to keep track of which areas are a higher priority than others, and which areas should stay loaded, and how long after all players leave the zone for them to stay loaded. It might also be beneficial to keep track of what state certain layers were left in, and how to determine how long new objects stay, and how long until old objects repopulate. | |
Ter13 wrote:
Setting the map loading to a background process will alleviate a lot of the problems, this opens up a lot of issues with players being able to walk into unloaded segments of the map. This can be solved by locking the player in place for a short time while waiting to teleport to an unfinished layer. Problem & Solution. There is also the issue of unloading areas to free up resources. You're going to have to write a system to determine which layers are in use, and which layers reference each area. You're also going to have to write a method to keep track of which areas are a higher priority than others, and which areas should stay loaded, and how long after all players leave the zone for them to stay loaded. Not super hard to determine the number of players in a given 'zone.' As for unloading, I personally would begin unloading it as soon as it was empty. Then if someone tried re-entering it, halt the unloading process, then start the reloading process. One of the points behind doing it in pieces instead of all at once. It might also be beneficial to keep track of what state certain layers were left in, and how to determine how long new objects stay, and how long until old objects repopulate. If you plan on letting generated zones stay after 0 population, then sure. I personally wouldn't do it, but that's just me. | |
That is quite excessive for any game.