Several puzzle games include a specific type of optimization problem: given components that produce and consume different resources and a grid of squares, find the optimal way to place the components to maximize output. I developed a method to evaluate potential solutions quickly and automated the solving of the problem using a genetic algorithm

Ebert, Michael W

English

DigitalCommons@CalPoly

Optimal Layout for a Component GridMichael EbertComputer ScienceCalifornia Polytechnic State University, San Luis ObispoDecember 2017c© 2017 Michael Ebert1Optimal Layout for a Component GridMichael EbertAbstract—Several puzzle games include a specific type of optimization problem: given components that produce and consumedifferent resources and a grid of squares, find the optimal way to place the components to maximize output. I developed a method toevaluate potential solutions quickly and automated the solving of the problem using a genetic algorithm.Index Terms—Combinatorial Mathematics, Genetic Algorithms, Simulation.F1 INTRODUCTIONS EVERAL strategy and puzzle games have a placementpuzzle in them where you must place components on agrid in order to achieve some result. In two of these games,Reactor Idle [1] and IndustrialCraft2 [2], the puzzle is power-themed. The goal of the puzzle in these two games is togenerate electricity from a variety of components that canbe put into four categories: Generators, which generate afixed amount of heat; Amplifiers, which increase the effectsof adjacent generators; Distributors, which distribute heatbetween adjacent components, and Boilers, which turn heatinto electricity. If too much heat accumulates in a compo-nent, that component will break. The challenge, therefore,is to find a design of generators, amplifiers, distributors,and boilers that, in a limited amount of space and withoutexploding, will produce the most amount of power.This is a NP problem; for C components and N tiles,there are (C + 1)N possible layouts for a given problem.Taking a fairly tiny problem size of 4 different componentsand 20 tiles of space, this is approximately 9.5 × 1013combinations. If 1 million layouts were tested per second,this would take 3 years to brute force. Some of these puzzleshave up to 10 components, and 100 tiles of space. Clearly, abetter method is needed.However, checking a layout is not fast. The way that thegame runs is in discrete ”ticks”. Every tick, each componentdoes its action once. Because of this, heat takes time topropagate across the design. An unstable design may notinitially show any problems. A nearly stable design mayslowly build up heat for several thousand ticks before beingdestroyed by excess heat. Additionally, components interactwith each other, such as amplifiers and generators, or dis-tributors and adjacent components. Because some of theiractions depend on the heat levels of adjacent components,they remove the possibility of a simple O(1) confirmationthat a layout is valid. A naı¨ve simulation (and the ones usedto check designs in games) simulates designs for hundredsor thousands of ticks to determine what happens to alayout. Simulating a design this way can take hundreds ofmicroseconds. In order to efficiently find a good design, it isnecessary to first construct an algorithm that can simulate adesign several orders of magnitude faster.M. Ebert, Computer Science, California Polytechnic State University, SanLuis ObispoE-mail: mebert@pacbell.netc© 2017 Michael EbertI have been interested in these games for a while andfind them fun. The problem also seems like a good candidatefor a computer solution – discrete components and values,deterministic outcomes, and a clear grading algorithm inpower produced.1.1 Literature OverviewWith regards to efficiently simulating a single layout, themost relevant area of research is flow maximization. Thereare several algorithms to do this, such as the Edmonds-Karpalgorithm [3], which runs in O(V E2), and the push-relabelalgorithm [4], which runs in O(V 2E), and can run fasterwith optimizations. A modified push-relabel is needed tocope with the unique constraints of my problem, namelythat 1) there are ’dumb’ nodes that emit the same amount toall downstream nodes, which is not possible with the basicalgorithms, and 2) the input is given in discrete steps, nota continuum. Max-flow algorithms assume that the flow iseffectively continuous – that the total possible flow is aninteger multiple of the potential input. With my puzzle,source components (generators) produce 100% output allthe time, and the design is invalid if the component networkcannot handle it.With regards to finding an optimal layout of compo-nents, most placement optimization research is focused intwo areas: very large integrated circuit (VLSI) placementand the facility layout problem (FLP). Unfortunately, bothareas operate under a different set of assumptions. Usually,there is a known number of components to place in alarger area, and crucially, the components are separatedfrom each other. This allows the efficiency of the design to beproportional to the distance between components on smallscales. In the problem that I am trying to solve, componentshave very strict placement requirements, and there is a verycomplex relationship between component placement andefficiency.Most placement optimization solutions rely on simu-lated annealing or genetic algorithms [5], [6]. Even thoughthe details of the problems are not commutative, thesealgorithms are good places to start.2 IMPLEMENTATIONAs there are several different puzzles that vary only slightlyfrom each other, I decided to create a solution that would2work for all of them with some tweaking. I wanted to avoidbuilding my implementation around assumptions that werepresent in a single puzzle, but would cause my solver tobe useless if used for an other, slightly different puzzle.As a result, I divided the puzzle-specific elements(numberof components, what each component does, global prop-erties of the environment, etc.) from the more general ele-ments of the code (general setup and run drivers, solutiongeneration algorithm, etc.), which would interact with thepuzzle-specific elements through template instantiation andmetaprogramming. Although separate, the puzzle specificelements are still defined at compile time for speed. Buildingthis flexibility dynamically into my solver at runtime ispossible, but would be inefficient, as constants, branches,and even the effects of entire functions would have to beevaluated at runtime instead of compile time. This coulddramatically reduce the performance of the code (for ex-ample, the effects of the ”empty” component: If evaluatedat compile time, it can compile to a no-op, whereas atruntime, the function still has to be called). Additionally,since so much more time is spent running the algorithmthan compiling it (hours vs minutes), one of the majoradvantages of runtime configuration, being able to makechanges quickly, is rendered meaningless.2.1 Layout Evaluation2.1.1 OptimizationsOne of the two algorithms that I had to design was a wayto evaluate the performance of a layout. In order to test alayout quickly, I allowed some inaccuracy in the simulation.All correct layouts are recognized as correct, but someincorrect designs are also marked as correct. These can beeasily filtered out in a more rigorous simulation once a smallgroup of candidate solutions are generated.There were 4 techniques that I used to speed up thesimulation that had a major impact on how the project waswritten.The main speedup in the simulation comes from elimi-nating the multiple ticks of simulation needed in the naı¨vedesign, effectively simulating the design in a single step. Thebasic idea is that I simulate one tick propagating through thesystem and see what resources are left over. This requiressome careful planning in order to avoid problems with loopsand isolated parts of the design.Secondly, I wrote the code with speed in mind. I usedC++ with heavy use of templates and compile-time con-stants. This allows for elimination of unnecessary branchingand function calls, resulting in a smaller and faster binary.Furthermore, most of the code is in header files, compilingin a single compilation unit. This allowes constant propaga-tion, inlining, and other optimization techniques to happenthroughout most of the code (This sped up the runtime by20% when using GCC 6.1.0 -O3).Thirdly, I wanted to enable concurrent and out-of-order execution wherever possible. To do this, I dividedup each component’s functionality into two steps: com-ponent setup() and component action(). All the compo-nent setup()’s can run in parallel, and same is true of thecomponent action()’s. After all the component have beenG1 G2B1 B2D1 D2Fig. 1. Valid layout that may be marked as faultyrun, usually a grading function is run in order to score thedesign.A fourth decision that I made was that instead of thetraditional setup of a grid of contiguous component prop-erties, I instead relied on a series of grids, one for eachcomponent property. For example, there is a grid storingthe type of each component, a separate grid storing theheat of each component, and a third grid storing the energyproduction of each component. By storing properties bytype instead of by component, memory access is optimized,as the simulation code tends to access one or two propertiesof all components rather than all the properties of a singlecomponent.2.1.2 Major problems encountered and solvedOne problem that I ran in to was that blindly traversinga layout is costly because of potential backtracking andloops. To solve this, I grouped the boilers into ”networks”of boilers connected by distributors. Since all boilers in anetwork are connected, the entire block acts as one largeboiler. I did this by having each valid component (boileror distributor) either connect to an adjacent component’snetwork or create a new network if one doesn’t exist. If twodifferent networks are adjacent to a single valid component,then the two networks are merged. This makes the heatdistribution work much better and have less error cases.Another problem that I ran into was misallocation ofresources. As an example, take the layout in figure 1. G1and G2 generate 10 heat per tick, D1 and D2 are distributors(that distributes heat), and B1 and B2 are boilers that absorb10 heat per tick. This layout would work in the actualsimulation, but not in a single passthrough simulation like Iam doing. This is because in a single pass, D1 will distribute5 heat to B1 and B2, and then D2 will distribute 10 moreheat to B2. This will result in 15 heat in B2 and only 5 inB1. As a result, B2 will not be able to remove all of theheat and the design will be marked as failed. In the actualsim, this would happen on the first tick, but on the secondand subsequent ticks, the excess heat from B2 would bemoved over to B1, allowing the design to succeed. It is notpossible to simply sum up the total number of boilers inthe design, as disconnected boilers would be included whenthey should not be. This problem prompted me to introducea modified push-relabel maximum flow algorithm into thesimulation. If the max flow can remove all the heat, then the3num designs = number of designs in each generationnum top = number of top designs to copy, unmodified,into the next generationnum new designs = number of designs to generate neweach generation (num designs− num top)num generations = number of generations to simulatemutate chance = chance of a spontaneous mutationoccuringend ix =last index of a design (size of a design in places- 1)for num generations doscore all designscopy top num top designs into next generationfor num new designs doselect parents A,B using exponential distributionselect a uniformly random spot R in the middle of thedesign 0 ≤ R < end ixN [0, R) = A[0, R)N [R, end ix) = B[R, end ix)select random float S between 0 and 1if S < mutate chance thenselect a random component in N and change it toa random componentend ifend forend forFig. 2. Genetic algorithm pseudocodedesign may work. If not, then the design is guaranteed tofail.2.2 Layout OptimizationAfter I developed a faster evaluator, I used it along with agenetic algorithm to try to find the optimal layout.I chose to use a genetic algorithm as it seemed bestaligned with the design of the problem that I was tryingto solve. Layouts already have a authorative score in theamount of electricity they produce, and this scoring al-gorithm is an essential part of the simulation itself. Fur-thermore, this problem does not lend itself to simulatedannealing, as good, bad, and invalid layouts are extremelyclose to each other, and there isn’t a linear path betweenthem.My genetic algorithm is fairly simple, and a high leveloverview is given in figure 2. I was able to parallelize thesimulation of designs, making the algorithm scale nearlylinearly with the number of cores.3 RESULTS3.1 Layout EvaluationThe work on designing an algorithm that would evaluatedesigns quickly was a massive success. I achieved a 1000-fold increase in the evaluation speed with only a few sub-tly flawed invalid designs being misidentified. Additionalspeedup may be possible by simple checking of grids to seeif they look invalid – for example, if the total heat emitted byreactors is greater than the total amount of heat that couldbe absorbed by every component on the board, regardlessof connectivity, it can be thrown out immediately.Additionally, my goal of allowing modification of thecomponents and their behavior was a success. The codeis very modular. Additional components can be addedin a few minutes, and properties of components can bechanged without having to rewrite significant parts of thecode. Additionally, the grading algorithm can be replacedor modified with minimal effort (Integrating the maximumflow algorithm into the code took only a day or so). Thesame code framework, slightly modified, could be used tosimulate tower defense designs, for example.3.2 Layout OptimizationWith regards to generating an optimal solution, there ismuch more work to be done. While I was able to generatevalid designs, I was never able to produce a design thatwas significantly better than what a human could producemanually in the same amount of time. What would helpwould be pruning the space that the genetic algorithmexplored, which I struggled with.REFERENCES[1] Baldurans. (2015, Nov.) Reactor idle. [Online]. Available:http://reactoridle.com/[2] Alblaka and IC2 Dev Team. (2011, Oct.) Industrialcraft 2. [Online].Available: http://www.industrial-craft.net/[3] J. Edmonds and R. M. Karp, “Theoretical improvements inalgorithmic efficiency for network flow problems,” J. ACM,vol. 19, no. 2, pp. 248–264, Apr. 1972. [Online]. Available:http://doi.acm.org/10.1145/321694.321699[4] A. V. Goldberg and R. E. Tarjan, “A new approach to themaximum-flow problem,” J. ACM, vol. 35, no. 4, pp. 921–940, Oct.1988. [Online]. Available: http://doi.acm.org/10.1145/48014.61051[5] C. L. Valenzuela and P. Y. Wang, “Vlsi placement and areaoptimization using a genetic algorithm to breed normalizedpostfix expressions,” IEEE Transactions on Evolutionary Computation,vol. 6, no. 4, pp. 390 – 401, Aug. 2002. [Online]. Available:http://doi.acm.org/10.1145/48014.61051[6] T. D. Mavridou and P. M. Pardalos, “Simulated annealingand genetic algorithms for the facility layout problem:A survey,” Computational Optimization and Applications,vol. 7, no. 1, pp. 111–126, Jan 1997. [Online]. Available:https://doi.org/10.1023/A:1008623913524

Optimal Layout for a Component Grid

https://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1144&amp;context=cscsp

Optimal Layout for a Component Grid

Abstract

Similar works

Full text

Available Versions

DigitalCommons@CalPoly