Fribbels Epic 7 Optimizer: gearing tools for a mobile role playing game

The problem, and what the tool does about it

This is a tool for organising gear and optimising gear and unit builds for Epic Seven, and the reason it exists is stated in the first sentence of the readme: gearing units can be time consuming, and it is not easy to find optimal combinations of gear within the game.

That is a specific kind of tedious. It is not that the game is hard to play, it is that the game holds a large inventory of items with many attributes, and the player is expected to reason about which combination is best. The tool turns that into a search.

The feature list is worth reading as a list of the parts of that problem.

There is automatic import of the gear and the heroes from the game, so the tool starts from what you actually own rather than from a list you type in. There is filtering by main statistics, sub statistics, and sets. There are automatic data updates for new heroes, which matters because the game adds characters and the tool has to know what they are. There are the hero's bonus statistics from imprints, artifacts, and exclusive equipment. There is scoring of substat efficiency, which is the measure of how much of an item's potential is actually used. There is prediction and editing of the reforged statistics, that is, the statistics an item would have if it were rolled at its best. There is colour coded sorting of the results, and optimisation of substat modification, which is the in-game feature that lets you upgrade one statistic on an item at the cost of another.

So the tool covers the whole loop: get the data in, work out what a hero's statistics are with each candidate item, search for the combination that maximises something, and then let the player narrow the results by what they actually care about.

The requirements are modest for a desktop application: a 64 bit Windows or Mac system, and a 64 bit Java 8 or later installed. There is a video guide for the installation, which is what you would expect for an application that is distributed as a download rather than through a package manager.

The project is an Electron application with a Python backend, the last push was on 2026-10-11, and the release history shows a version in September 2025 after two in 2023.

The optimizer tab and the settings panel

The readme is organised as a tour of the interface, and the optimizer tab comes first, because that is where the work happens. The worked example used throughout is a tank build, and the panels are described in the order a person meets them.

The settings panel is the control surface for the other panels, and its contents are mostly the search controls. You pick the hero you want to optimise for from a dropdown, and then there are the buttons: start, to begin a search; filter, to narrow the results of a completed search by the statistics on the filter panels without running a new one; cancel, to interrupt a search that is running; load settings, to bring back the settings used for the last search with that hero; and reset settings, to put everything back to the defaults.

The last two of those are the ones that matter in practice, and they are a small design decision with a large effect. Loading the previous settings for a hero means that re-running an optimisation after a change in your roster is one click rather than a re-entry of twenty numbers. Resetting means that experimenting with filters does not leave the tool in a state where you cannot get back to a known baseline.

There is a statistics preview in the panel as well, described as showing the hero's current statistics on the left against the new ones on the right. That is a small detail with a large effect on how the results are read: the output of a search is not a list of items, it is a before and after, and the tool puts the two side by side.

The options group underneath holds the switches that decide what the search is allowed to use, and those are the subject of a later section because they are where the answer to your question is decided.

The structure of the readme is a good guide to the application itself: optimizer tab, then gear tab, then heroes tab, then importer tab, then the getting started material, then troubleshooting, then contributing. The order is roughly the order of use, with the configuration tabs first and the setup instructions last.

Filters, and the ratings the game does not show

The stat filters panel is the straightforward one. The left boxes are the minimum and the right boxes are the maximum, and both are inclusive. The example describes a build that needs at least twenty thousand health, at least two thousand four hundred defence, and a speed between one hundred and eighty and two hundred.

What matters about the design is when the filter applies. The filter runs on the results after the search has been submitted, and once the results exist you can tighten the numbers and press the filter button again, and the results narrow without another search. That is the difference between a filter that is an input to a search and a filter that is a view over a result set, and the second is far more useful, because the first means every time you change your mind you wait again.

The rating filters panel is the more interesting one, and it exists for a good reason: these are statistics you will not see in the game, but which can help you decide between builds.

The health times speed rating measures the combination of speed and raw health, and is for units where you want both. The effective health figure is calculated from the health multiplied by the defence divided by three hundred plus one, and it measures how much damage the unit can absorb before dying, which is a way of rating tankiness. Effective health times speed is the same measure with speed added.

The average damage rating is attack multiplied by critical chance multiplied by critical damage, and the readme adds the caveat that makes it useful rather than misleading: it takes critical chance into account, so lowering your critical chance lowers the rating because you will critical less often, even though your best hit is unchanged. That is a real property of an average, and the fact that the tool says so is the difference between a rating and a formula.

The damage per second rating is the same measure with speed factored in, and the readme's example cut off partway through that line, so the exact form is not given here.

So the filters come in two kinds, and the distinction is the one the readme draws: the ones the game shows you, and the ones it does not. And the second kind is where the interesting builds are, because the game shows you the components and the tool shows you the combination.

The options that decide the answer

The options group is the part of the settings panel that decides what a search is actually allowed to consider, and every one of them exists because of a specific way the answer could be wrong.

Using reforged statistics means the search predicts what the statistics would be on fully upgraded gear at the maximum level, rather than what they are on the item you have. That is a big difference in a game where gear can be upgraded, and it is the difference between optimising the gear you own and optimising what it could become.

Using substat modification means the search assumes you will apply the in-game stones that upgrade one statistic at the cost of another. The readme notes that each hero's optimisation settings must be selected on the heroes tab before this can be used, which is a dependency rather than an afterthought: the tools you have and the hero you are optimising for determine which upgrades make sense.

Only maxed gear restricts the search to items that cannot be upgraded or reforged further, which is the setting for a player who wants to know what their current gear can achieve rather than what a future drop could achieve.

Locked items and equipped items are two more permissions, and the equipped one has a carve-out that reveals the design. When equipped items are excluded, they are still used for the unit's own equipped slots. So you can ask the tool to imagine a completely different set of gear for a hero while keeping the pieces that hero is wearing in the slots it is wearing them in, and the readme points out the consequence in the exclude list, which is that a hero added to it has its gear ignored so that other heroes cannot take it.

That last one is a piece of multi-character bookkeeping, and it is worth noting that it only works when equipped items are being considered. The tool is not just solving a knapsack problem; it is solving it with a notion of ownership between characters.

The keep current option is the opposite in spirit: it forces the unit to use the gear it has and only optimises the slots it has left unequipped, which is the setting for a player who has decided what a unit wears and wants the rest sorted around it.

The import, which is the hard part

The importer tab has a short description, and the getting started section is mostly about the importer, which tells you where the difficulty in this project actually sits.

The problem is that a game on a phone does not offer an export. So the tool has to get the data out of the game somehow, and the readme documents a set of paths for doing it, differentiated by how the game is running: from the automatic importer on a desktop, from the automatic importer on a phone, and from a specific case for running the importer on a Google Play Games beta, an emulator, or a particular kind of Mac.

The setup instructions are split by operating system as well, with a first time setup section for the automatic importer on Windows and a separate one for the Mac, and then a section on using the importer, and then a separate note about the cases where the game is running somewhere unusual.

The structure of that is a good indicator of what the tool is. Almost all of the documentation is about getting the data in, and relatively little is about the search itself, because the search is a solved problem and the extraction is not. The optimiser tab has a handful of panels; the importer has four separate setup paths and a troubleshooting section of its own, and the readme has a second troubleshooting section specifically for the importer.

The rest of the getting started material is the ordinary part: how to install the application on Windows and on the Mac, how to optimise a unit, how to update your gear, and some tips for getting good results out of the optimisation. The importer tab also has a save and load function for all of the optimiser data, so the settings and the searches survive a restart, and the tips section is the one to read before you complain that the results are bad, because a search with the wrong permissions or the wrong bonus statistics will give you an answer that is technically correct and practically useless.

The repository, and a stack that tells you the story

The repository is an Electron application with a React renderer, a Python backend, and a lot of directories that each mean something.

There is an app directory for the renderer, a backend directory, a configs directory for the build, an internals directory, a data directory, and a resources directory. There is also an out directory, which is where the built application lands, and a couple of files that are not code at all: a test gear file in two formats, and a file with the name scraps, which is the sort of file that accumulates the notes of somebody thinking through a problem.

There is a new readme file alongside the main one, which is a common pattern when a project is rewriting its documentation and keeps the old one around during the transition.

The manifest tells you the history of the project, because its description is the boilerplate of the template the project started from. It says the application is an Electron application boilerplate based on React, React Router, Webpack, and a hot reloading library, for rapid application development. The name and the product name are the real ones, and the author is the person who built it, but the description was never changed.

That is worth reading as a signal, because it tells you the project is a fork of a well known template rather than something written from scratch, and the build scripts are the template's. The development command starts by checking whether a port is in use and then runs the renderer development server with hot reloading. The build splits into a main process build and a renderer build, run in parallel, with separate development and production configurations.

The packaging scripts are the interesting ones, because there are five of them and they tell you where the project expects its users to be. There is a general package command, one for all platforms at once, one for continuous integration that publishes, and three individual ones for the Mac, for Linux, and for Windows on 64 bit. The Windows one is the important one, because the requirements say a 64 bit Windows or Mac system, and the application is a desktop program for a game that people play on phones and on desktops.

There is a native rebuild command, which is the standard way to deal with a native module that has to be compiled for the specific version of the runtime, and a lint setup with separate scripts for the source and for the styles, and the styles are linted with a syntax that assumes the preprocessor dialect.

So the stack is a React renderer over an Electron shell with a Python backend doing the search, built with Webpack from a template, and packaged for three desktop platforms. The one thing that does not fit the template is the Python backend, and that is the part that does the actual work.

Editorial conclusion

The Fribbels optimizer fits a player who has accumulated a large inventory of items and no way to reason about all of them at once, and who wants to know what a search for a better build would actually find. It does not fit a player with a dozen items, where the game's own interface is enough. Verify first which items the search is allowed to use, since the options about locked, equipped, and already maxed gear change the answer completely, that the bonus statistics for the hero are entered before you optimise, because several options depend on them, and that the ratings you filter on are the ones the tool calculates rather than the ones the game displays, since the difference between a displayed stat and a calculated one is where the interesting builds are.

Frequently asked questions

Official sources

1. fribbels/Fribbels-Epic-7-Optimizer on GitHub
2. Issues
3. README
4. Releases