The 60MB Rule - Why is it good to follow?

[Katsu! :3]

The 60MB Rule is something that I've been trying to posit to mappers for a few months now; In this, I will explain what it is, and why it's a good thing to keep in mind.

What is the 60MB Rule?

The 60MB Rule is a guideline when making a map to not let a map's filesize exceed 60.0 MB. This is a reasonably comfortable filesize for most maps (even larger-scale gamemodes such as Payload) once they're around the final bits of development.

Why should I (as a mapper) follow this rule?
To put it simply, it's to make your map more accessible to players. What do I mean by this? Well, if your map's filesize is somewhere in the 90MB or even 100MB range, it's going to take players a longer time to download your map. The reason this can present a problem is, let's face it: A lot of people are really impatient, especially when looking at a download bar slowly go up. There are a lot of people who see a download get one or two bars in 10 seconds and immediately go "I'm not waiting for this!", which while sad is a reality we just have to live with. By making your map's filesize smaller, you reduce the number of people who will say something to this effect when joining a server with your map on it. This means that more people play your map, and your map has a larger audience to potentially enjoy it!

What about custom assets?
Sometimes if you have to go over, you just have to go over. It's okay to do this, but it's always a good idea to keep the filesize as small as we can while keeping the map's integrity. A good way to efficiently use custom assets around your map is to pre-plan what assets you want to use in your map, as if you have a plan for it, you are much more likely to be able to re-use assets when making your map. Additionally, a lot of the filesize of the custom asset side of mapmaking usually comes from large or redundant textures, such as an overly large cubemap, a prop with high-resolution textures, or a model with a bunch of skins. If you're able to, try to reduce texture sizes when possible! Also, always remember to pack and repack your map so its filesize is as low as it can get!

 

[dabmasterars]

THIS. I'm tired of maps that use a bunch of custom objects for no reason. This was especially bad with a lot of jungle maps. I can understand Enclosure being a 90 MB map, since it's really big and also has 3 stages, but Lasarus? And don't get me started on their optimization...

A bunch of tips on how to optimize your map:

• Use BspZip compression (this should be obvious)
• Use less custom objects (this should be obvious too)
• Optimize lightmaps using
  
  "Toggle texture application" (my template is: 64 for ceilings and roofs, 32 for low contrast brushes, 16 for everything else, you can check how lightmap shadows look by enabling "3D Lighting Preview" in the View menu)
• Apply the
  
  "nodraw" texture on faces that are out of bounds
• Don't place too many"env_cubemap" entities (or decrease their resolution to 16)
• Do a proper skybox. Not a literal box around the map.

 

[Tiftid]

This tutorial from 2008 has a few extra tips on how to cut down on lightmap usage:

[TUTORIAL] Understanding lightmaps

The goal of this tutorial is to provide a basic understanding of lightmaps, how they work, and how one can minimize their load on texture memory. You can find the map and associated assets here: Tutorial Map and Model Lightmaps are an often forgotten part of map optimization. It's true that...

tf2maps.net

You can also monitor the exact filesize of your map's individual elements by opening the BSP file in GCFScape and navigating to this "lumps" folder:

As you can see here, the bulk of cp_bruhstbowl_b6's filesize is split roughly evenly between LDR lightmaps, HDR lightmaps and Pakfile.
LDR and HDR lightmaps will basically never get heavier than 16 MB - I know this, because pl_boatload_b2a has 16 MB of each lightmap, and adding any more would cause an engine hunk overflow.

Spoiler: Engine hunk overflow nerdy stuff

Curiously, I've seen a map with 20 MB of lightmaps that didn't run into engine hunk overflow - I think this is because it used a luxel size of 1 on some surfaces, and cp_bruhstbowl_b6 and pl_boatload_b2a instead use a luxel size of 4/8 across numerous surfaces.
This indicates that engine hunk overflow is actually based on the number of lightmap textures rather than the raw number of luxels.

There are some terrifying maps out there where the pakfile alone is heavier than 60 MB!

Here's the thread where I learned how to do this: https://nodraw.net/2010/01/some-secrets-of-binary-space-partition-files/

This method also lets you open the map's pakfile as a .zip file, so you can see if anything is being accidentally packed into your map that shouldn't be, as is common with CompilePal.

 

[Brokkhouse]

Bonus: Unpack the map using bspsrc (including packed content) or GCFscape, then use a file size visualizer like TreeSize to quickly see what uses up all this valuable space.
Here's Rotunda:

Unpacked it is 91 megabytes, packed it's roughly 53, which is okay.
As you can see, the largest filesize hoggers are textures. In other maps it might also be soundfiles, but this one doesn't have custom ones. When creating new textures, use the smallest resolution you can get away with, in addition to Tiftid's lightmap advice.

 

[Sonoma]

Candyland currently is only 49KB despite being entirely made out of custom assets plus custom mp3s, I always find if funny when there is a map that uses little custom assets somehow surpasses that.

 

[Brokkhouse]

Candyland currently is only 49KB despite being entirely made out of custom assets plus custom mp3s, I always find if funny when there is a map that uses little custom assets somehow surpasses that.

Megabyte. Candyland is 49MB.
Oh, and unpacked it is 182 megabytes. You have the advantage of most of that being materials, which are easy to compress. Only 500KB sounds.

 

[Sonoma]

Regardless, still find it funny when a map surpasses Candyland in file size because it is entirely bespoke, though I imagine this might not be the case for too much longer when we get further along in artpassing with new assets + stage 3

 

[Lacry]

That was actually one of my goals with Bound, it's only 9,26MB, which if it was official, it would be the lighter map in TF2 (except for background01, itemtest and cp_cloak, but I'm not counting those).

I guess thats the good side of making a map completly indoors, also I think people puts wayyyy too much decoration in TF2 maps, and now the bar for decorations in maps it's so high you have to put small details in every corner. I mean, Hydro is one of TF2 biggest maps and its 24,4MB, not much bigger than 2Fort, and nowdays we have maps that are way smaller than Hydro but the filesize is 5 times bigger.

 

[Brokkhouse]

Note that this is mainly because Valve maps don't need any assets packed into them. They exclusively feature the actual BSP tree, lightdata, and cubemaps. Everything else is in the TF2 VPKs. Custom maps, especially with custom themes are gamemodes, are bound to be heavier since they can't just use the stock TF2 assets.