1. New map format
Right now, Spring uses a horrible horrible map format. Giant texture maps are NOT the way to go in a full 3D game, which is why you don't see that method in any other modern games. Right now I have a mere 8 maps in my Spring maps folder, and they are using 160 MB of space. THIS IS MORE THAN ALL OF THE MAPS RELEASED IN THE CC EXPANSION COMBINED. Obviously something needs to be done. Now, I'm nowhere near good enough to code anything remotely close to what I am going to suggest and I understand the difficulty of rewriting that entire part of the engine, but I think it should be done now before even more maps are made.
Basically, I say the metal and heightmap should be kept. Those aren't harming much, and they compress well enough to not make a difference. However, instead of having a massive texture map to go along with them, which has tons of redundant data (especially between maps that share similar textures), I think a more modern approach should be taken. Have sets of textures, such as a set of ice textures, a set of green, etc. Some of these could be distributed with the game itself (as the maps it ships with need textures as well), but it'd also be possible for mapmakers to create their own.
The mapmaker would then go into his .smd file (or a future map editor which doesn't exist yet) and do something like this:
[TexturePackageName.xxx\TextureName]
Zone1=1023 113 8402 2753 55 218;
Now, let me explain the numbers. The first and second numbers would be coordinates on the map at the locations to start the texture. The third and fourth numbers would be the end of the texture, forming a box on the map where the texture is applied. The final two numbers are the height constraints, so the texture would only be applied inside the box between the heights of 55 and 218. Of course, more detail could be given in this format: A zone's prevelance over other zones (maybe give each zone a "ranking" between 0-255, the higher the number the more it will show, so when two zones occupy the same coordinates the one with the higher prevelance would be shown). You could also make height exceptions, such as in the example above, have a tag that makes it so the texture will *not* show between 60 and 100. That's just giving the mapper more power.
Basically, this way you would just have a few moderately large texture packages. Yes, they'd be a pain to download, but that's the beauty: They would only need downloaded once! If Spring shipped with a greenworld texture package, any third party maps using those textures would only need to have their heightmap, metal map, and smd file distributed! It'd drastically cut filesize, bandwidth bills, hard drive space used, and wait times for those will slower connections in the long run. This should also easily accomodate hosts sending maps to clients in the battleroom, assuming everyone already has the texture packages.
The only downsides to this I can think of right now are:
-Load times. I imagine it'd take longer to load and apply the textures like that than just loading a premade texture map.
-Gathering coordinates. It'd be a pain to do without a proper visual map editor.
2. Mod Management
I actually posted this before the forum hack, but I'll go ahead and do so again. For this, I basically suggest taking a UT2004 style approach: each mod gets its own sub directory in the Spring folder. ALL of the mod's files will be stored in its directory. Each mod will ship with an ini file. This ini file will tell spring the mod name and the paths to look for files, such as this:
Code: Select all
[Mod]
ModName=Uberhack;
ModDescription=Lemmings ahoy!;
ModAuthor=Brave Sir Robin;
ModSite=http://www.planetta.com/bsr/;
[Paths]
Maps=../Maps/; //Look in the main Spring map folder, this wouldn't be required, so mods could easily ship with their own maps
Maps=./Maps/; //Look in the Uberhack/Maps/ folder
Data1=../; //Load the stuff from the main spring dir first so it doesn't have to be redistributed
Data2=./; //Load from the mod's folder now, which has the relevant files that make Uberhack Uberhack
DataFileExtension1=.hpi;
DataFileExtension2=.ufo;
DataFileExtension3=.ccx;
DataFileExtension4=.gp3; //This would allow the mod maker to define his own file extensions, however they would still use the HPI format. The higher the number the filetype is, the greater prevelance it will take, much like in TA. however, the mod maker could define as many types as he wanted in any order he wanted.
Inside of Spring.exe, and in the BattleRoom client, the user would be given the option to choose a mod from a simple drop down menu or something. In the case of the battleroom, there would be a column to tell users looking to join which mod it is. A user could also make a shortcut to the mod, in the format:
C:\Games\Spring\spring.exe -mod=Uberhack
Which would immediately load the game with Uberhack rather than having to choose it in the menu. The code for the -mod line would simply be the filename of the ini file for the mod.
This would make mod installation and uninstallation a breeze; to install or uninstall, you simply extract to the spring folder or delete the mod's folder respectively. There would be no loose files anywhere else, each mod would only get its one folder, with the ability to reference data from the main Spring folders.
That's pretty much it. Hope you guys like the ideas.