0
\$\begingroup\$

In this thread, it tells that in 2d platformer games, I should pre-define and connect node to find the correct path.

But I don't understand how to find the node's children. In my program, I define map as following, 0=free space, 1=solid terrain, 2=node

the original map definition is:

numpy.array([ [0,0,0,0,0,0,0,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,1,1],
              [1,1,1,1,1,1,1,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,0,0],
              [1,1,1,1,1,1,1,1,1,1,1], ])

the map after adding nodes

numpy.array([ [0,0,0,0,0,0,0,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,2,2],
              [2,2,2,2,2,2,2,0,0,1,1],
              [1,1,1,1,1,1,1,0,0,0,0],
              [0,0,0,0,0,0,0,0,0,0,0],
              [2,2,2,2,2,2,2,2,2,2,2],
              [1,1,1,1,1,1,1,1,1,1,1], ])

so the map should be so enter image description here

In the original A* (A star) algorithm, it searches 8 directions and every direction checks only one node if available.

But in a platfomer, I don't know how to deal with this, there are too many possibilities. For example, assuming the character's jump value is 3, then we go to left now I can:

  • jump to left using 200% power, (keep pressing left while jumping and falling, move 6 steps actually)
  • jump to left using 166% power
  • jump to left using 133% power
  • jump to left using 100% power
  • jump to left using 66% power
  • jump to left using 33% power
  • just walk (the paths 1-7 in the pic)

enter image description here

8 directions and bigger jump value lead to more possibilities. What's more, there are countless possibilities when falling from a high solid terrain.

For every possibility, in order to connect the nodes, I need to check the corresponding coordinate in the map (array) if existing node.

So I am confused. Am I over-complicating / misunderstanding A* or did I miss something because it requires a huge calculation for every node in a big map like 500*500?

\$\endgroup\$
  • \$\begingroup\$ Welcome to GDSE. In the future, please post code & code like things (array contents, etc) as text rather than screen shots. \$\endgroup\$ – Pikalek Aug 2 at 15:12
  • \$\begingroup\$ I believe that this question gamedev.stackexchange.com/questions/118912/… answers your question as well. \$\endgroup\$ – Jody Sowald Aug 2 at 15:41
0
\$\begingroup\$

am I overcomplicating/misunderstanding

I'm afraid, you are (to some extent). All you really need to build the graph is to walk through all of your nodes (2) and connect them using a mask like this.

--UJU--
-UUJUU-
U0W*W0U

where

  • * -- Anchor point, that's the position of the node we are currently testing
  • - -- nodes we can't reach (directly) from the current one, so we won't connect to them
  • J -- if there is the node -- you can jump to it if you can jump through the blocks
  • U -- nodes you can jump up on (or from, it works both ways) to
  • W -- nodes you can walk to
\$\endgroup\$
0
\$\begingroup\$

You are correct in your understanding that increasing the number of choices will significantly increase the problem size. Whether or not it increases it too much depends on many factors. For instance, I've seen A* extended all tiles within a distance of three (Directional-48 search) in order to path find with turning radius constraints. That doesn't necessarily mean that your problem won't grow out of scope - the only way to know that is to either build and test or do the math / theory needed to determine the time required.

Regarding your representation, I'm not sure I agree with your distinction between nodes & empty space. For one thing, it doesn't account for jumping to get power-ups, avoid enemies, etc. It also seems like to be accurate you either need to calculate it all by hand or already have made reachbility calculations. If it works well enough for your needs, that's great, but it's something you might need to revisit later on.

I my limited experience with platformer AI, the problem space is somewhat restricted by reducing the look-ahead. For instance, the solver might only consider one screen's worth of the level at a time rather than the entire map. This could be scaled up or down depending on the performance.

It may be the case that A* is not a good fit for this problem or may need additional techniques to make it competitive. The previous research I've seen tended to focus more on heuristic search algorithms such as Monte Carlo methods, but that may just have been a consequence of what I was working on at the time. There's a lot of great research connected to Mario AI Compitition & they have a code framework available. Because the research is geared toward competition, it tends to be more practical & results oriented and less theoretical & hand wavy.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.