Map System Goals

[Spirited]

Hey there,

As you might know, I'm working on a new source to release to the community. The source is going to use it's own map system, and so I'm faced with two options on how I can make the map system. I could make a map system that's very small or one that is very complete. So, information about the options:

1. Small Map System: The system compresses data maps (dmaps) into extremely small files that are very quick to load. Running the map system takes an extremely small amount of RAM since only bits make up the system. Limitations: Does not load tile elevation and other small features (which most servers don't use anyways).
   
   
2. Large Map System: The system compresses data maps (dmaps) into smallish files that are quick to load. The system includes tile elevation, portal checks (which can be done as an external system), and market shop checks (which can be done as an external system), but at the cost of RAM consumption. My bit technique for RAM compression from the small map system will not work on the larger system (or not as well), taking more than x20 more ram to run (standard for today's servers, I suppose).

Most servers don't even need the larger system, so please help me by telling me which sounds like a better deal for you.

Kind Regards,
Spirited

[marcbacor6666]

small map system

[Y u k i]

Large, ram is cheap and we are in 2014 by now.

Btw, why dont you create a Dev Thread like we all do instead of posting new threads over and over?

Mods should be able to change polls on threads so...

[Spirited]

Originally Posted by Y u k i

Large, ram is cheap and we are in 2014 by now.

Btw, why dont you create a Dev Thread like we all do instead of posting new threads over and over?

Mods should be able to change polls on threads so...

Moderators cannot change polls.

[FatalError-]

In my opinion, be as conservative as you can with resources. Go with the smaller system for now. If you find a need for the larger later on, have some use for the elevation etc, then you could implement that later on. I see no reason for the extra's really.

[Spirited]

The larger system's design is from my Burning Skies project. It takes a bit less than 200 MBs to load all of the maps (with action and elevation checks on each tile). The way I compensate is by loading only the maps I need to have loaded at that time. The smaller system would take ~1/24th of that, which is ~8 to 12 MBs. It's something to think about. I'll start on other systems until I get more feedback about this.

[DataTime]

Smaller Map System

[LordGragen.]

i am voting for Small Map System.

[Spirited]

I should say, though the larger system takes up more memory, it is more efficient. The smaller system is just slightly less efficient (but not by much). The efficiency of both is still very high performance. The smaller system was originally designed for an Android server I was going to make (where RAM isn't disposable).

[Spirited]

Hey guys. This is the second edit I'm making to this post. After really thinking about the smaller system, item and monster overlap checks would take up too much processing to check. I would also have to be constantly compressing the smaller system (which isn't that big of a deal as I mentioned, but the other things would be). The larger map system I designed for Burning Skies is more efficient, and since this is pretty tied, I will be going for the larger system. The small system will have its use some day, but probably not today. I have to refine the idea more before I implement it. Anyways, thanks for your feedback. It at least shows me that a smaller system has some desire. I'll keep thinking about it. Cheers.