Making a Map Installer?
16 July 2016

Some folks think installing a custom map is easy, others feel it’s a problem. If a someone made a tool to build map installers, what would it need to do?
Note: for this I’ve decided to focus on installing maps as single player maps. For multiplayer maps that need to run on a server, I’m not going into that yet. I have thoughts, but I’ll keep them for another time.
Why is it needed?
First of all, I will address this point. Why is it needed?
When you know how to install a custom map in Minecraft, yes I can agree, it’s not that hard. If you have a little computer knowledge you should be able to do it.
Saying that, imagine if getting a Steam game didn’t automatically install into the right place.
Instead you had to manually download, unzip, and then copy the game into the correct folder buried
deep in some hidden AppData
directory. How would you feel about that? It’s entirely doable, but
do you think Steam would be so successful?
With Minecraft maps, the process gets a little more complicated when you also have to make sure the player uses the right version of Minecraft. 1.9.2? or 1.10+ or even 1.8.something?
Sure, it’s possible to create a new profile in the MC Launcher and choose the specific version of MC that you want to run. Sure it’s not rocket science. But isn’t it just another barrier?
So yeah, the existing situation is not terrible, but it can be much, much better.
What would be needed?
What we actually need is not actually just a ‘Map Installer’. What we really need is a tool to build Installers. A ‘Map Package Builder’ (if I can call it that for now - see how it just rolls off the tongue :P) would be used by map makers to package their maps as executable ‘Map Installers’.
This is what I imagine: the Builder should accept 4 things to create an Installer;
- the completed map (required)
- a
profile.json
file (optional) - an
options.txt
file (optional) - any number of resource packs (optional).
Let’s consider those…
(1) The Map
The completed map could be provided in an unzipped format. This would allow the Builder to zip up the file in a format that the Installer can later unzip.
(2) The Profile File
Game Directory in the Minecraft Launcher UI
The profile.json
file would include all of the required
data to create a new profile in the users launcher_profiles.json
file. For example,
it might look like this:
{
"profiles": {
"My Map Name": {
"name": "My Map Name",
"lastVersionId": "1.8.9",
"gameDir": "",
}
}
}
Using the lastVersionId
will allow map makers to set the correct version for their map to be played in.
That’s a big deal, because making sure your players use the right version of Minecraft is not easy.
Yet, the most important thing about packaging a custom profile with your map will be
how the gameDir
field can be used.
When you edit a profile in the MC Launcher, you can specific a different “Game Directory”
to run Minecraft from. This is saved in launcher_profiles.json
as gameDir
.
Allowing map makers to specify a different Game Directory opens up a load of options!
Firstly the map won’t appear on the players normal list of single player maps. So they can’t accidentally play it in the wrong version of MC.
Secondly (and this is the cool part!) it allows the map maker to include a custom options.txt
file
that could be used for their map.
Which leads me to…
(3) The Options File
No more having to change these pesky settings?
In the normal Minecraft game directory is an options.txt
file that includes all of the
players chosen settings. Settings such as render distance, difficulty, particles, and key bindings et cetera.
If map makers can include a custom options.txt
file, this will allow them to set up some of the
preferred settings for playing their map.
Since we don’t want all of the users settings to be overridden unnecessarily, I suggest that the
Installer should copy the players options.txt
file and then only change the settings specified by
the map makers options.txt
file. The map maker wouldn’t include all possible settings, just the
ones they want to change. For example:
renderDistance:12
renderClouds:false
resourcePacks:["my-resource-pack", "my-second-resource-pack"]
Notice that even the active resource packs can be set? Well that leads me to…
(4) Resource Packs
An example a redesigned menu using a resource pack
For single player maps, you can include a resource pack as resources.zip
in your world folder, and it will automatically apply when playing the map. But some maps makers may also want to redesign the main Minecraft menus. To do this currently you still have to get the player to apply the resource pack.
But, if you’ve got control over the options.txt
file (as we’ve established), then you can also set which resource packs are active, and in which order to apply them. As soon as Minecraft launches, the selected resource packs would be in use.
The Result?
If we had a Map Package Builder that could create Map Installers that would support all of these things; then we could release maps (at least single player maps, multiplayer maps for servers requires some more thought) that would:
- Automatically install into a pre-defined directory.
- Automatically launch the correct version of Minecraft to play the map in.
- Automatically launch the game with the correct settings for playing the map
- Automatically launch Minecraft with your resource pack(s) applied to completely change the look and feel of the game.
Final thoughts
I’m sure there would be things to iron out; what about multiplayer maps? Could this be cross-platform? Windows, OSX, Linux?
Please let me know your thoughts and ideas!