I’ve been a huge fan of Minecraft for about seven years now. However, the basic game, while fun for a while, does tend to lose its interest after a while. Fortunately, there’s a huge universe of free add-ons, called “mods”, created by the community at large. In fact, there are so many that you couldn’t possibly just add them all to your game. So, the question is, how do you select which ones you’d like to have in your “mod pack”?

1. Choose a theme

I always start by choosing a theme. The easiest theme is to pick one mod you especially want to try out, and then select a bunch of other mods which complement that mod. So, for example, the last modpack I built started with a very realistic railroading mod called Immersive Railroading. From there, I picked a mod which adds a bunch of Victorian-age technology, some mods which add more food and crops, some which add more realistic biomes, and so forth. However, everything I added was required to fit the theme of Victorian-age railroading.

There are, of course, a lot of other ways to select themes. Perhaps you want a modpack based around space exploration, or one based upon super realistic wilderness survival, or exploring magical realms. Whatever you pick, let that be the guiding principle around all the rest of the choices you make, because there will be a lot of choices!

2. Select your Minecraft & Forge versions

Minecraft releases updates periodically which then requires the authors of each individual mod to make adjustments to their mods. For minor version updates, these are usually minor changes, but between major version updates, these can be quite substantial. For example, the changes between versions 1.7 and 1.8 were so substantial that the massive Lord of the Rings Mod is still only compatible for Minecraft 1.7.10, which was released in June 2014! All else being equal, my rule of thumb is to pick the newest version of Minecraft which has been out for 6 months. However, if a certain mod I really want to use is only available for older versions, I’ll fall back to the newest version it supports.

Nearly all mods these days rely on Minecraft Forge, a low-level interface for mod programmers to interface with the game itself. If you’re interested in building your own custom modpack, you’ll also need to pick which version of Forge to use. My rule of thumb here is to pick the most recent “stable” version available for my chosen Minecraft version.

3. Select candidate mods

The first phase of your many, many choices will be to pick out a bunch of mods which might be a good fit. I usually do this by going to the CurseForge Mods List, filtering by the Minecraft version I’m using, and sorting by most popular. I’ll briefly consider whether each mod might be a good fit with the theme of my modpack. If so, I’ll download the version which fits my Minecraft version.

In this phase, I almost always wind up with way more mods than I could reasonably fit into the modpack. I also wind up with a bunch of mods which might seem to fit the theme, but wind up not. Or, I might wind up with a bunch of mods which provide nearly identical functionality. Thats fine at this stage, but we’ll want to start narrowing things down in the next stage.

4. Mod exploration

Next, I’ll take each mod, one at a time, or in small groups which are closely related, and try them out. I often do this in creative mode so I can just tinker with the stuff the mod adds, and form my own ideas about how well it fits the modpack, and whether it’s a fun addition to the rest of the pack. I particularly try to weed out anything which seems too buggy, poorly balanced, or duplicates too much from another mod I like better.

As you’re working through this stage, you’ll often find a variety of errors and problems. Frequently, it will be that the mod you selected requires some other mod which you now need to go find and install. Sometimes, this will turn up a mod which requires a newer / older version of Forge than you’ve selected. In that case, you need to be very careful about upgrading / downgrading as you might run into even more problems with other mods which were happy with the version you already had!

I also try to make sure I fully understand what each mod does during this stage. This will often require tinkering with the config files to see what options are available, whether items I don’t like can be eliminated, and whether various things can be made easier or harder. I’m also looking for how well each mod interacts with related mods. For example, if I’m adding a mod which uses electrical power, I try to figure out if it can interact well with the primary mod(s) I’m using to provide it.

5. Down selection

By this point, I’ve got a pretty good idea of what each of the mods do, and how well they integrate with the other mods I’m considering. At this point, I’m trying to pick one and only one mod to serve each of a bunch of various functions in the game:

• tweak the game’s UI
• alter fundamental game dynamics
• control terrain generation
• control ore generation & add new ores
• add additional biomes / control biome selection
• add additional mobs: passive & active
• additional trees, plants, flowers, crops, etc.
• control mob spawning
• add electrical power (if applicable)
• add a system of magic (if applicable)
• add helpful items to the game
• customize recipes & remove items

Of course, one can’t always isolate each of these functions to a single mod, but the goal is to at least get down to a set which don’t directly compete with one another in strange ways (e.g., Dynamic Trees adds cool growing trees… but they don’t work with trees added by the Forestry mod).

This is the stage where you make the hard choices of which ones win out, and which get removed. It is often the case that a whole bunch of mods all work together very well, and some one mod has a bad interaction with just one of them. Sadly, this pretty much always means that you have to nix the “some one mod”.

6. Configuring by layers

If you take all the mods you’ve selected and activate them all at once, you pretty much always run into a mess of errors and incompatibilities. I like to tackle this problem one layer at a time. Using the list from step 5, I add in all the mods which deal with each item in the list at once, and then start up the game. Hopefully, you already worked out the hard crashes and incompatibles abck in step 4, so the problems you run into now are just ways in which these mods interact that you simply don’t like. Go back to the config files for each mod, and fine-tune the settings until that layer is working just as you like. Then proceed to the next layer.

With each layer that you get working to your satisfaction, backup your complete setup. It’s very easy to accidentally introduce problems which don’t become apparent for a while, so you definitely want to be able start over from the last thing you had working pretty often.

7. Play testing

Once you have the configs all set, it’s time to really test things out. There are a number of things I’m looking for at this stage. Some of them can be tested in a creative world (usually much faster and easier), but many can only be tested in survival (where the availability of resources and chains of recipes become important). Here’s a list of things I’m looking for as I do my play testing:

• Is it easy to stay alive in survival through the first full day?
• If certain resources are key to your various mods, are they readily accessible?
• Are resources which are intended to be rare actually hard to find?
• Do mods which are supposed to interact with one another actually do so successfully (e.g., do the HarvestCraft plants work with your Agricraft crop sticks)
• Do mobs (active & passive) show up where and when they are supposed to, and in acceptable numbers?
• Do you get crashes when you do anything, or visit certain places?
• Does the overall world generation match your expectations / purposes for the modpack?

Ideally, you’ll be able to pull together a few people to play the modpack a bit on their own (both in creative and survival) before committing to using it on your server world.

✧✧✧

I hope this helps make the rather daunting process of putting together a substantial modpack a bit easier! It usually takes me about 20–30 hours to get all the way through this process for modpacks with around 100 mods in them. For an example of a modpack I put together this way, check out Brunel on GitHub. Enjoy!