Project Management

Working on a modpack can often be a marathon of a task. Depending on how high you set your sets, it can take months of steady consistent work to get to your pack in a playable state.

As with any project, your success is going to come down to how much time you put into it, and how well you organize that time will have a large impact on how soon you’ll be able to finish it.

This page covers a variety of miscellaneous topics on project management.

Basic overview

Once you start organizing your project you’re going to want to figure out where exactly you’re going. The Planning pageTODO_LINK has a more detailed breakdown of what this entails, but generally your end goal getting an idea of what you’re “Minimum Viable Project (MVP)” looks like.

If you’re not familiar, the term MVP refers to the bare minimum amount of features you can have to release your pack to the public. While a more ambitious and feature-filled pack sounds more fun to make, it’s often not realistic unless you have lots of experience making packs, or a large amount of reliable help. Doing a few good things really well is more impressive than doing a bunch of things very poorly, and this concept extends to any kind of project you can imagine.

Once your planning is complete, you should work on your pack until the point where you have a clear idea of what it will take to finish, and then break things down into a series of tasks. For example, if you’re making a tech pack with machine tiers, finish one tier in totality including any player documentation. You’ll then have a better idea of how much time each one will take and how many you’ll want to complete for the initial release of your pack.

TO BE CONTINUED

Working with mod devs

Mods are the life blood of your modpack, and it’s inevitable that you’ll need to work with a mod dev to report a critical issue or suggest a feature for their mod.

The first place you should go to is a given mod’s issue board. This can be hosted in a variety of different places, but usually it’ll be in a mod’s Github Repo. When reporting an issue or making a suggestion, it’s best to be as detailed as possible, including logs, mod versions, and other relevant issue.

Alternatively, mod devs may have a social platform such as Discord for issues and discussions, though their level of community involvement will vary. The dev may have dedicated channels or forums for getting help or reporting issues.

Using a platform’s DM/private messaging feature to contact a mod dev is generally advised against unless they’ve explicitly listed somewhere they are open to it. This includes pinging mod devs on their or other Discord servers.

Dealing with lack of support

Sometimes a mod author will not be available or wiling to work on a mod. This can often happen if you are developing a modpack on a version not actively maintained by its author. In this case, you’re essentially on your own as far as fixing issues goes.

This can mean removing items or blocks with critical bugs or even writing mixins if you’re familiar with modding. In the worst case, the issue might be so bad it will require you to remove the mod entirely.

Working with others

Getting help

Maintaining motivation

Avoiding Scope creep

As defined in the Planning page, scope is the sum total of features you are adding or plan to add in your modpack. Every mod you add, feature you design, or quest you plan to write increases the scope of your project in varying amounts.

Likewise, scope creep is when the scope of your project gradually increases by adding many small features over time.

With modpacks, this can easily happen just by browsing the mod platforms and adding any mod that seems interesting. In the short term, it adds content to your pack, but that content needs time and energy to vet. Some features of a mod may be broken and need to be disabled, and others might need proper integration in the form of recipes or progression. The fact of the matter is that adding mods increases the scope of your project, even if its only by a small amount.

The best way to avoid scope creep is by taking time to come up with a clear plan. Once you have a clear idea of what your released modpack will look like, it’s best to list out every feature you want to include in the initial release. Take the time to really think about this list, if you don’t have an idea of how long any one thing will take, do some of the legwork to ensure you aren’t doing too much for one feature.

Once you have a curated list, start cutting things out of it that aren’t necessary for your first release. Maybe you don’t need two tech mods that do mostly similar things. Maybe you have to choose between a skill tree and a research tree. You should cut down this list until you have what is called the Minimum Viable Project (MVP). Unlike games or movies, modpacks often do not have blockbuster releases where the audience only comes when the 1.0 version drops. Most modpacks are slow burns that will gradually get attention if they’re lucky, and there’s no harm in updating it as you go.

Now that you have the final state purely defined, you need to put strong limits on what you change with your plan. Deciding to add or remove small utility mods? Probably fine but be careful. Adding large magic mods? Absolutely not, stick to the plan. If you really do need to make a fundamental change to your pack, you might just need to go back to the experimentation phase for a bit and come up with a new list.

Playtesting

As you might expect, playing your own pack is extremely important for development. Once you have your first initial version of the pack, you should do a full playthrough from start to finish if you haven’t already. This is best done as the very last step, marking things down to be fixed before released.