Thanks for the answers, I'll try to reply to some of the comments.
What do you mean you can't use pointers? You said you're using Java. All non-primitives (any class you make, anything made with "new", etc) are all 'pointers'. They're references. You're not copying things every time you pass them to a method.
Didn't know that (or had forgotten about it), thanks.
What does an optimal path in pacman have to do with finding all combinations?
When you say you need to find all combinations, the examples you showed were permutations (ie: order matters. {1,2,3} != {3,2,1}). Also curly braces {} usually indicates sets, which means order would not matter. Which is it? Do you want to find
permutations, or combinations? Do they need to be the same length as the input set?
What exactly are you trying to do?
Technically you're finding permutations, not combinations. Also, it looks like you're looking for permutations that contain all n elements. The number of n element permutations for a set of n (distinct) elements is equal to n factorial.
So, for n = 10, you would have 3628800 lists. It should be clear that generating all these lists is not going to scale.
Iterating through all the permutations would only require n iterators, but you will probably want to cull out permutations with some kind of heuristic (for instance merging some elements into a single element) because looping through all the permutations will be expensive time-wise.
You're right, I was looking for permutations, and square brackets would have been better.
I was indeed trying to find the optimal path for PacMan to eat all the dots using a somehow brute force approach.
However, in this case (n >= 10) the pathfinding algorithm didn't even start, the program run out of memory just by generating all the permutations of the order in which to eat the dots.
I thought my approach was less "brute force" than it actually is, but it seems it's not.
My guess is that this is an optimal path-finding problem where every dot is an element.
I would forget about optimal and instead look for a good enough solution. Probably make only the big dots, straight line segments of little dots, and dots at intersections into elements, and then try to form groups based on proximity to the big dots (have groupings prefer little dots that are far away from other big dots).
In my problem there are no big dots.
Like, finding the optimal path that hits every pellet from the get-go? Basically a hamiltonian path? But the pellets don't come anywhere close to forming a fully-connected graph. The vast majority of pellets cannot be adjacent in such a path. Most pellets only connect to 2 others.
If that's indeed what FerranMG is trying to do, then yeah I would definitely abandon that brute-force approach. In fact, it can't even work because afaik you can't actually create such a path on most pacman boards. It's impossible to visit every pellet only once; you'll have to occasionally walk over spots where you've already eaten the pellet. Intersections contain a pellet in the middle of them, which means you could never visit an intersection twice. Since there are multiple intersections, and they have more than 2 ways in/out, you cannot solve a pacman board by visiting every pellet-vertex only one time.
In other words, I don't think that's a good way to model the problem, as I understand it. I'm sure I'm missing something since not much was explained.
I'm looking for an optimal path that hits every pellet, yeah.
It's not a hamiltonian path, though. Depending on how you look at it (I mean, depending on what is the definition of a state in this problem):
1) if the states are just the PacMan location, then you are allowed to be in the same state twice.
2) if the states contain, for example, the PacMan location and the location of all the remaining dots, then you would not be allowed to revisit a state, but also you would not need to visit all the nodes in the tree that represents the state space.
Just wanted to chime in here and say that this problem is more difficult than you probably think it is and usually just a good approximation is fine. That being said, if you really want to do pathfinding for pacman eating n dots, then you should represent each "edge dot" (dots that have no neighbour on one side or junction points) on your map as a node with edge weights between them being a tuple storing the amount of squares to move through to get there and dots that exists on the path between. Then you can just run normal pathfinding using
Djikstra. You'll need to mark each node with the cost of movement and dots eaten to get there via each path. Once a node has been visited with a number of dots eaten > n, you don't need to move on from it. Your solution is the path to the node with the smallest dot count >= n.
Quick and dirty explanation and there's probably a cleaner way to explain and implement but whatever, it's not a trivial problem. If you just want decent behaviour, you could do a greedy algorithm, just pick the path that minimises distance and dots eaten each time.
It's not really but you can definitely model each sequence of dots as a path. It gets messier than standard pathfinding also because path cost effectively increases after traversing once.
I'm required to find the optimal solution, and I've also to use A*. I know a good approximation would be easier, but for this case it's ok if the algorithm spends even hours finding the optimal path for a large number of dots in the board.
So, what I'm going to try now is to ditch the former approach (ie, create and store all the permutations of n dots).
Instead, I will try to define each state as the location of the PacMan and the remaining number of dots. Each state (or node) will have a g values (number of moves that takes for the PacMan to get to that state), and h value (an heuristic, that would be for example the number of remaining dots, or maybe the minimum Manhattan distance to eat all dots (both of them are admissible)), and run the A* algorithm using as the final state one of the n possible states in that PacMan eats the last dot on the board.
I anyone is interested, I'll let you know how it goes.

If I haven't made myself clear in any point, feel free to ask.