I began with a large ambition: an expert Minecraft modpack whose progression would be hard because its systems depended on one another, not because every ordinary action was punished. I worked through the big choices one at a time—starting region, technology sequence, quests, recovery after death—before adding mods to a smaller development instance.
The practical checks then challenged the design. A mod could install and still fail to behave as the plan assumed. I reported one death-recovery check working, while other compatibility and progression questions needed more testing. That is why the quest direction became a guide to decisions rather than a list of chores: it should help a player understand what a step proves. The notes record a pack under construction and specific checks, with balance and release still ahead.
Difficulty through systems, not punishment everywhere
Several late decisions narrowed what “hardcore” should mean. I said to keep weather vanilla. I also pushed back on trying to prevent every possible use of vanilla mechanics as an exploit. Players choosing an expert pack were responsible for their own enjoyment; the design did not need an endless anti-exploitation layer.
When a proposed industrial-site system became too elaborate, I asked whether existing mods already handled the relevant behavior. The clarified direction was to let their machinery and spatial requirements create the factories. There was no need for a separate generic system that registered facilities, dictated footprints, or demanded decorative service corridors.
That kept the pack focused on engineering problems the player could recognize. A permanent outpost should earn its place through extraction, buffering, power, and freight, rather than satisfying a hidden checklist about the shape of the building.
Quests as a guide
I also questioned the reward-heavy questbook pattern. Quests could explain what to do without handing out unrelated prizes.
The revised FTB Quests direction was guide-first, with little or no material reward. One example described a frontier district that the main base could not support continuously. The objective was to establish a persistent industrial outpost and reliable two-way freight; success meant demonstrating extraction, buffering, and return transport.
The new capability was the reward. There was no need for a reward chest full of ingots or a quest currency shop. Recipes belonged in the recipe browser, current machine information in diagnostics, and detailed mechanics in their own documentation. The questbook should explain the current problem and why solving it opens the next stage.
Assemble a smaller instance first
The proposed initial slice was a volcanic nickel-sulfide district, positioned around a transition from late Era III to early Era IV. Instead of installing the eventual 175–275-mod candidate collection at once, the assistant proposed a smaller development instance.
Its industrial roles included Create for mechanical automation, Productive Metalworks for casting, Immersive Engineering for heavy machinery, Electrodynamics for the electrical grid, Mekanism for chemical processing, and PneumaticCraft for pressure-based processes. Storage Drawers, Super Factory Manager, recipe/diagnostic tools, and scripting/unification mods filled supporting roles.
These are the historical selections from the design session, not a freshly checked compatibility list. The proposed custom core mod was still absent; it would need to connect strategic geography, district and survey state, hazards/stabilization, and proofs of capability. The download list alone could not supply the pack’s entire progression design.
Magic and dimensions were added in further batches. I reported testing the magic mods individually before providing the combined log. Later I explicitly reported that Aether death recovery worked. That establishes a useful check of one behavior, not completion of the pack.
Compatibility tests needed to be understandable
The later phase moved from seeing whether individual mods loaded to testing how selected systems worked together. I asked for tests I could actually run.
The first electrical interoperability instructions were too broad. I reported that things kept blowing up. The assistant then acknowledged that it had failed to account for Electrodynamics’ voltage behavior. I also corrected the proposed PneumaticCraft target: its machinery uses compressed air, so a direct electrical-machine test was the wrong description.
The revised plan separated ordinary electrical interoperation from a later power-to-pressure conversion test and promised exact blocks, connections, settings, and expected results. That exchange is as important as the successful startup checks. A compatibility test is not useful if the person running it cannot distinguish an intentional mechanic from an integration failure.
A separate brainstorm also considered literal one-block starts, supplied starter tools, fungus growth, and familiar sieving. I made clear that these were alternatives being explored, not successive changes already locked into the main campaign.
I had worked out a demanding direction and begun checking it in a smaller instance. The reported death-recovery result proved one chosen part, not the balance of the entire pack. The next useful tests were the ones that would tell me whether the planned dependencies survived contact with the actual mod versions.