4

I have a game system that can be represented as an undirected, unweighted graph where each vertex has one (relevant) property: a color. The goal of the game in terms of the graph representation is to reduce it down to one vertex in the fewest "steps" possible. In each step, the player can change the color of any one vertex, and all adjacent vertices of the same color are merged with it. (Note that in the example below I just happened to show the user only changing one specific vertex the whole game, but the user can pick any vertex in each step.)

graph diagram

What I am after is a way to compute the fewest amount of steps necessary to "beat" a given graph per the procedure described above, and also provide the specific moves needed to do so. I'm familiar with the basics of path-finding, BFS, and things of that nature, but I'm having a hard time framing this problem in terms of a "fastest path" solution.

I am unable to find this same problem anywhere on Google, or even a graph-theory term that encapsulates the problem. Does anyone have an idea of at least how to get started approaching this problem? Can anyone point me in the right direction?

EDIT Since this problem seems to be really difficult to solve efficiently, perhaps I could change the aim of my question. Could someone describe how I would even set up a brute force, breadth first search for this? (Brute force could possibly be okay, since in practice these graphs will only be 20 vertices at most.) I know how to write a BFS for a normal linked graph data structure... but in this case it seems quite weird since each vertex would have to contain a whole graph within itself, and the next vertices in the search graph would have to be generated based on possible moves to make in the graph within the vertex. How would one setup the data structure and search algorithm to accomplish this?

EDIT 2 This is an old question, but I figured it might help to just state outright what the game was. The game was essentially to be a rip-off of Kami 2 for iOS, except my custom puzzle editor would automatically figure out the quickest possible way to solve your puzzle, instead of having to find the shortest move number by trial and error yourself. I'm not sure if Kami was a completely original game concept, or if there is a whole class of games like it with the same "flood-fill" mechanic that I'm unaware of. If this is a common type of game, perhaps knowing the name of it could allow finding more literature on the algorithm I'm seeking.

EDIT 3 This Stack Overflow question seems like it may have some relevant insights.

V. Rubinetti
  • 1,324
  • 13
  • 21
  • 2
    Pretty complex because everything matters, color, removal order etc. I think you can brute force it in O(c^n * n!). – maraca May 19 '17 at 20:21
  • Is it a interactive game like a candy crash or you wanted a complete automation. In case of user interaction, the part of which color change to be suggested so that user can reach end of game easily. Can you elaborate which part needs to be automated or build with intelligence to finish the game optimally? – arunk2 May 20 '17 at 03:17
  • @ArunKumar The whole challenge of the game is to reduce the graph under a certain number of moves. Allowing unlimited/many moves would make the game trivial for the user and make designing a hint system trivial as well. So I kind of need to know the smallest number of moves mathematically possible for the maximum amount of challenge. And the reason I want an algorithm as opposed to determining it manually by trial and error for each level, is mainly because there is an editor for user-made levels. So I want to calculate it for them to avoid impossible move limits and ensure a fun challenge. – V. Rubinetti May 21 '17 at 17:24
  • Does the user pick the colour to merge (so could find an optimum solution) or do the colours alternate in a fixed/predictable order or is it a random order? – MT0 May 22 '17 at 13:41
  • @MT0 In each step, the player can choose one vertex and change it to any color within the finite set of different colors that existed in the starting graph. – V. Rubinetti May 23 '17 at 23:16

3 Answers3

2

Intuitively, the solution seems global. If you take a larger graph, for example, which dot you select first will have an impact on the direct neighbours which will have an impact on their neighbours and so on.

It sounds as if it were of the same breed of problems as the map colouring problem. Not because of the colours but because of the implications of a local selection to the other end of the graph down the road. In the map colouring, you have to decide what colour to draw a country and its neighbouring countries so two countries that touch don't have the same colour. That first set of selections have an impact on whether there is a solution in the subsequent iterations.

Ronald
  • 719
  • 1
  • 6
  • 6
2

Just to show how complex problem is.

Lets check simpler problem where graph is changed with a tree, and only root vertex can change a colour. In that case path to a leaf can be represented as a sequence of colours of vertices on that path. Sequence A of colour changes collapses a leaf if leaf's sequence is subsequence of A.

Problem can be stated that for given set of sequences problem is to find minimal length sequence (S) so that each initial sequence is contained in S. That is called shortest common supersequence problem, and it is NP-complete.

Your problem is for sure more complex than this one :-/

Edit * This is a comment on question's edit. Check this page for a terms.

Number of minimal possible moves is >= than graph radius. With that it seems good strategy to:

  • use central vertices for moves,
  • use moves that reduce graph radius, or at least reduce distance from central vertices to 'large' set of vertices.

I would go with a strategy that keeps track of central vertices and distances of all graph vertices to these central vertices. Step is to check all meaningful moves and choose one that reduce radius or distance to central vertices the most. I think BFS can be used for distance calculation and how move influences them. There are tricky parts, like when central vertices changes after moves. Maybe it is good idea to use not only central vertices but also vertices close to central.

Ante
  • 5,350
  • 6
  • 23
  • 46
  • Nice idea, and I think you're probably right, but this isn't quite a reduction yet as you are constraining not only the input (which is allowed) but also the moves you can perform (not allowed for a reduction). Can you think of a way to modify the input (i.e., a gadget) to force the situation that the optimal sequence of vertices to change always changes the current root at each step? – j_random_hacker May 20 '17 at 20:44
  • Alternatively, you could try to show that choosing changing the root vertex will always turn out to be an optimal solution -- but that's not the case here. Suppose we have a 4-vertex tree with A at the root, representing the two paths ABA and AC. Your algorithm would first change the root A to either B or C, necessitating a further 2 changes -- but changing the B to A as a first step would mean that only 1 further change is required. – j_random_hacker May 20 '17 at 20:55
  • @j_random_hacker I do not have an idea how to solve this problem :-) Reduction to a tree and supersequence problem, maybe helps. Since problem is NP-complete, I would go with some greedy approach and heuristics. – Ante May 20 '17 at 21:01
  • 2
    @j_random_hacker so if we could prove that only changing the root makes the problem simpler (which is likely the case) then the problem is at least as complex as the shortest common supersequence poblem? – maraca May 20 '17 at 23:28
  • 1
    @Ante: You have not (yet) shown that the OP's problem is NP-complete, because the problem that you *have* shown to be NP-complete is not a special case of the OP's problem (due to the added restriction on where the next vertex change must occur). – j_random_hacker May 21 '17 at 08:22
  • 1
    @Ante: By analogy: Consider the problem in which we have a connected graph, and our task is to choose a sequence of vertices that contains each vertex exactly once and such that each vertex is adjacent to some previously chosen vertex. This is can be solved with a (Minimum) Spanning Tree in poly time. Suppose now we add the additional restriction that each chosen vertex must be adjacent to the *previous* chosen vertex: now the problem is equivalent to Hamiltonian Path, which is NP-hard. Reducing some problem to the latter problem does not prove that the former problem is NP-hard! – j_random_hacker May 21 '17 at 08:24
  • @maraca: Yes. The way to show that it is simpler (or at least no harder) is to demonstrate a mechanical way (that is, an algorithm) for converting any instance of it into an instance of the original problem in such a way that the answer to the latter (i.e., constructed) instance is the same as the answer to the former instance. It turns out that we can simplify this kind of proof by only considering 2 possible answers, "yes" and "no", which is possible because we can frame the question as "Is it possible to reduce all vertices to a single vertex using at most k colour changes?" – j_random_hacker May 21 '17 at 08:42
  • @maraca: Since the inputs to the 2 problem types (original and restricted) are identical, we might hope that the simplest possible conversion process -- simply leaving the input unchanged -- could work. But the counterexample I gave in my second comment shows that there is at least one input for which this doesn't work. So if such a conversion process (called a "reduction") does exist, it will need to be a bit more involved. – j_random_hacker May 21 '17 at 09:03
  • @j_random_hacker Very good analogy. As I see it, main problem to construct reduction is to transfer general case results which are global to local results in rooted tree case. – Ante May 21 '17 at 09:44
  • Not sure if this was clear or affects what you guys are saying here, but... In each step, the user can choose *any* single vertex to choose the color of; the vertex doesn't have to remain the same for the whole game. So there is no "central" or "root" vertex. I've added a clarification to the original post. Also, I've added an edit to the end, changing the aim of the question, if you guys can take a look at it. – V. Rubinetti May 21 '17 at 16:35
  • @V.Rubinetti: Ante's aim was to show that even a very restricted version of your problem is already hard, the implication being that the original "full version" is necessarily at least as hard. (If we can show that it's hard to build an engine out of scrap metal, then it must be at least as hard to build a car out of scrap metal.) But by adding the restriction you mention, s/he actually causes the problem to no longer be a special case of your original problem, meaning that it's still possible that your problem is still "easy". – j_random_hacker May 21 '17 at 17:07
1

I think the graph term you are looking for is the "valence" of a graph, which is the number of edges that a node is connected to. It looks like you want to change the color based on what node has the highest valence. Then in the resulting graph change the color for the node that has the highest valence, etc. until you have just one node left.

J. Michael Wuerth
  • 272
  • 1
  • 6
  • 2
    This won't work in general. Imagine the blue node in the picture being purple too and an additional edge with a single purple node from the green node. Now you would start by changing the green node to purple which requires 3 steps in total, but starting by changing the green node to red only requires 2 steps in total. – maraca May 19 '17 at 20:35
  • This is an interesting idea and perhaps the real solution will involve the "valence" in someway, but as @maraca said, that strategy wont work. – V. Rubinetti May 19 '17 at 21:16