The optimizer is a tool for optimizing solutions of a level. It will reduce the number of moves and/or pushes of a solution. If you don't want to reduce the moves or pushes of solutions you don't need the optimizer tool. It's a tool for professional players.
You can open the optimizer by pressing F5 or through the optimizer menu.
The optimizer GUI (click image to see an enlarged version of the image) shows the level at the top left, so you can always see which level is currently opened for optimizing.
At the top right a log is displayed showing information about the optimizer process.
Below the level display and log display there are several input elements which can be used to adjust the optimizer.
At the top right a log is displayed:
While the optimizer is running some information are displayed in the log. When the optimizer is opened deadlocked box configurations that can occur in the level are identified in a background task. You can see the progress in the log. If the deadlock detection has finished the message "Deadlock detection has finished." is displayed. The detection runs at most 3 seconds. Howerver, it's possible to start the optimizer even when the deadlock detection hasn't finished, yet (prior to version 1.69 this isn't possible).
The deadlock detection has only to be done once when the optimizer has been opened.
In the "Solutions" list all solutions of the level are shown:
You must select a solution here for optimizing it. The list has the same context menu as the solutions sidebar. See description of solutions sidebar for more information.
The optimizer uses the selected solution as basis for the search for a new better solution. You can select more than one solution at a time. Then the optimizer tries to combine them while searching for a better solution.
Note: selecting multiple solutions at once for optimizing them needs a lot of RAM and the optimizing run takes a long time.
After the optimizer has finished the optimizing process the new found solution is added to the solutions list and automatically selected. If the new found solution is already stored in the solutions list the new solution isn't added but the already stored one is selected.
The optimizer can optimize a solution for the shown metrics:
- Moves/Pushes optimizes a solution for moves and as second metric for pushes.
- Pushes/Moves optimizes a solution for pushes and as second metric for moves
- Pushes/Moves/BL/BC/PS optimizes a solution for 1. moves, 2. pushes, 3. box lines, 4. box changes and 5. pushing sessions (since JSoko version 1.71)
- Pushes/Moves/BL/BC/PS optimizes a solution for 1. pushes, 2. moves, 3. box lines, 4. box changes and 5. pushing sessions (since JSoko version 1.69)
- Box lines only can be used to "shuffle" a solution. This results in a new solution having a different structure than the solution selected to be optimized. Sometimes this new solution having a different structure can be optimized further and results in new best solutions. You can "shuffle" a solution if the optimizer doesn't find new best solutions anymore when letting it optimize some of the available solutions.
- Box changes can be used to quickly reduce the number of box changes.
Restricting the search
The optimizer algorithm searches all possible path to a new better solution. However, such a search would take far too long in most of the levels. Hence, this search must be restricted. This can be done by setting the "vicinity squares":
This restricts the search to the "vicinity" of the basis solution which has been selected to be improved. The more boxes and the more vicinity squares the more RAM the optimizer will use and the longer the search will last. For huge levels only one box should be selected. For smaller levels 2 boxes with a small setting for the vicinity squares may be a good choice. For instance: 2 boxes which each have 10 vicinity squares.
The program can't automatically determine the perfect settings for a level. The perfect setting depends on the available RAM, on the level and on the solution. Hence, it's necessary to try several different settings for optimizing a solution.
Note: the more boxes and the higher the vicinity squares values are the better the results will be (but the longer the search will take). For a quick result use low values and just one box. Then increase the values and the number of selected boxes. If the optimizer log should display the message "Insufficient memory. Optimizing is done in stages." you should stop the optimizer and use lower values / less boxes until the optimizer doesn't show this message anymore.
The following topics are only for users who want to tweak the optimizer to its best. It's not necessary to understand or use these features for optimizing solutions when you are only interested in "quite good" solutions.
Restricting the pushes range
The optimizer normally optimizes the whole solution. If for instance it's sure that the first 10 pushes of a solution are already perfectly optimized, it's possible to set the pushes range to be optimized from 11 - "end of solution".
The "optimize pushes range" can be used to restrict the search for a better solutions to a part of a solution which can be set by a "from" push and a "to" push.
The optimizer automatically creates a new level from the pushes in the selected range. Boxes which aren't pushed in this pushes range of the solution are converted to walls in order to reduce the number of boxes in the level.
Maximum number of box configurations
JSoko tries to calculate the needed RAM before the optimizer starts. Depending on this the maximum number of box configurations is calculated. However, usually this calculation is just a rough estimation. In the log the optimizer displays the available free RAM after the optimization has been done. If there is still a lot of RAM free after the optimization has finished, it may result in better solutions when the maximum box configurations is manually set to a higher value.
Note: Due to 32 bit variables used in the program JSoko has internal limits. Hence, the maximum number of box configurations used by the optimizer may be less than the manually set value. The log shows which value is used in the search.
For the new optimizer methods Pushes/Moves/BL/BC/PS and Pushes/Moves/BL/BC/PS there is no 32bit restriction. JSoko tries to use as much RAM as available. Hence, it's recommended to start JSoko with a high RAM setting. The available amout of RAM must be set when JSoko is started. This can be done in the files: Start_JSoko_Linux.sh and Start_JSoko_Windows.bat (depending on your operating system). These files contain the start command for JSoko which looks something like this: java -Xmx512m -jar JSoko.jar
"512m" is the maximum amout of RAM to use. You can set it to a higher value when your system has more available RAM. For instance this sets a maximum RAM usage for JSoko of 5GB:
java -Xmx5000m -jar JSoko.jar
If the optimizer finds a new solution having less or equal metrics compared to the best selected solution this new solution is saved for the level. It's possible to use this new solution as new basis solution the optimizer should use for searching for further improvements. This iterative optimizing is done automatically when "Iterative optimizing" is selected. The optimizer then will optimize the selected solution and all better solutions it will find as long as further improvements can be found.
While doing this the optimizer will save all found solutions by adding them to the solutions of the level. This may result in a lot of new solutions. If "Only save last solution" is selected the optimizer will only save the last (=best) found solution.
Note: the optimizer also continues the search when the new found solution has the same metrics as the solution that has been selected to be optimized. This is due to the fact that even small changes in a solution can result in further improvements in the next iteration run.
However, the optimizer will of course stop immediately if the new found solution is identical to the solution selected to be optimized.
Preserve player end position
This is a special checkbox for users who split levels manually for a better optimizing result. In these cases it may be helpful to set this flag:
If this flag is set, all new solutions the optimizer will find have the same player position at the end of the solution (= when the level is solved) as in the selected solution to be optimized.
Number of CPUs to use (since JSoko version 1.69)
The optimizer can use multiple CPUs/cores while generating box configurations and for the "Pushes/Moves/BL/BC/PS" and "Moves/Pushes/BL/BC/PS" optimizer methods. As default JSoko uses all CPUs for these tasks. However, if this slows done the computer too much the maximum number of CPUs JSoko is allowed to use can be set here.
Restricting the area to be optimized
Some levels are very huge and contain many boxes. Therefore the optimizer can only be used with small settings for the vicinity squares.
However, often improvements of a solution can be found by only rearranging pushes of boxes in a small area.
It's possible to mark the area the optimizer shall use for optimizing. This can be done by simply marking an area in the displayed level graphic at the top left of the optimizer GUI.
To select an area to be optimized just click into the level graphic and while holding the mouse button down move the mouse. This way a rectangle is drawn representing the area that will be marked. When the mouse button is released the selected area will shown highlighted.
When at least one square has been selected this way and the optimizer is started then the optimizer will only optimize the selected area. Due to the smaller area to be optimized the number of generated box configurations is lower than it would be when optimizing the whole level. Hence, it's possible to increase the settings for the vicinity squares without increasing the number of generated box configurations too much.
A selection of an area can be removed by using the right mouse button or the ctrl-key while selecting an area.