ID:1641792
 
Not sure if to post this here or dev help.

I've heard a lot of rumors about map size and lag. How big maps create lag and what have you, so I want to know if its true. Do large maps create lag? How large can they be before they create lag? Does having a lot of objects like trees/bushes contribute to this lag if they're scattered across the large map? If it doesn't lag where do people get the notion that lag is created by having large maps (I assume confusing FPS for lag)?
Lag is caused by stuff happening. Objects that do nothing won't contribute to lag by just existing.

Large view sizes however are pretty laggy on the client side because of large numbers of objects being drawn. This has nothing to do with map size, though.
Large maps make the game's host files larger, and uses more of the host computer's resources to run the game. Its like Kaiochao said, the map itself will not directly create lag when nothing is happening, but can contribute to lag in a number of ways.

If you have a small map and do a for(var/turf/t in world) whatever you do inside the loop might not make any lag at all, but if you have a 1000 x 1000 y 3 z map, the loop will be checking 3 million turfs. Depending on what the loop is doing, it could create lag, possibly freezing the game for several seconds at a time, or worse.

The size of your icon files themselves can cause lag on the client side, if the client has to download large icons. This is one thing that causes the lag that freezes individual players, but does not effect players who are not downloading icons.
Gluscap wrote:
If it doesn't lag where do people get the notion that lag is created by having large maps (I assume confusing FPS for lag)?

It's probably because the larger your map size, the worse you are at programming.

In response to Magicsofa
Not necessarily. It's more like having a large map requires you to be smarter about programming.

An example is AIs.
What most bad people will do is add a bunch of monsters with AIs, and that's it. A better person will only enable AIs that are on the same map as a player.
In a small game these might be acceptable. If your game is a few 100x100 maps you probably wont have many enemies anyway and you'll never notice the CPU usage.

But once you have a 1000x1000 map it becomes harder to turn AIs on and off but more essential because a 1000x1000 map can fit thousands of enemies on it and still look empty.

Unless the game is well made, you cannot simply increase the map size to 1000x1000 and expect nothing to change. If you want to use maps this big, you need to accommodate for them.
Sorry, I was being sarcastic. And poking fun at a real phenomenon, where nooby BYONDers get all excited when they see the size settings, and crank it up to 11 JUST BECAUSE
In response to The Magic Man
I think a good way to deal with AI would be spawning the NPCs in a zone that isn't visible to the players when they enter certain area, this would look realistic to them, and if there is another client who can view the npcs spawning I suppose playing with alpha would be decent enough to make it look less crappy than having 100 npcs spawned on the same spot.
In response to The Magic Man
The Magic Man wrote:
What most bad people will do is add a bunch of monsters with AIs, and that's it. A better person will only enable AIs that are on the same map as a player.

Enable the AI within proximity of the user. There are more AI's than there are users. This is always true. Otherwise, it's strictly PVP and not PVE. If this is true, then you should have all AI turned off by default.

For every 3 - 5 steps (or whatever the hell floats your boat) check if there is an NPC nearby. If there is, then that NPC will check if there's a player nearby. It will perform it's actions (move, fart, etc), and then it will check if a player is near again. If not, it shuts down and does NOT repeat.

This can get more efficient, I know. The above is just more simple for someone just starting to do this method. Such as having all of the actions performed on the user. For instance, if an NPC is activated by a user, add that NPC to the user's "activeNPCList". When the distance between the referred to NPC, which is stored in activeNPCList, and the player is greater than.. idk.. 10? (You'll be iterating through the activeNPCList by the way) Just a little bit bigger than the view size (sudden pro-tip: Turn-off range should be a bit bigger than your turn-on range. Otherwise you'll just flick it on and off repeatedly).

Because it's referred to, you don't have to iterate through all mobs to find that sucker. This will save you time. Not only that, It saves you the trouble of having each active NPC check the view(), which uses more CPU, from what I am guessing, than whatever proc checks the distance between two locations (P.S. I have no idea what proc that is. Look it up. I haven't done this in a while). When the distance is great, obviously... turn the NPC off and remove it from the list. Don't forget to sleep your while loop that repeats the NPC function. Otherwise you're stupid.

Also, if you don't want an NPC just standing there because it got turned off when 1 person left but another person comes in.. Make a proc called "TurnOff()" that checks the vicinity for any extra players and ends the while() loop for the NPC. If there are extra players, add the NPC to the first player that shows up. Give it to their activeNPCList. Or, just do it the simple way that i mentioned first.

This way honestly just takes a lot of thinking... Hell, I've added a few things to this logic after writing it and rereading it. It's definitely worthwhile for a good game though.

As for the large maps. Nah. It doesn't bother your game. What really uses up resources is music. If you have the full friggin' barney song on your game along with 10 other full songs, like narto intro and stuff, then you're doing something wrong. A) Your songs should be about 20 seconds long and should be loopable. B) You shouldn't be using copyrighted stuff C) If you want to make a full song, make it in to pieces. Part 1. Part 2. Part 3. Part 1 is the beginning. Part 2 is the middle. Part 1 plays again. Part 3 ends it off. Think of Part 1 as the hook or w/e. Instead of repeating the crap needlessly, just play it again. You can make a proc to play certain files in certain orders to achieve something like that... That in which I will probably make a library for now.

Keep in mind, this is just logic. I've never done it. I've never had to do it. Why? Because I've never had a pixel artist.