Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (591)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Help making enemies more aware of walls.  (Read 4056 times)
0 Members and 1 Guest are viewing this topic.
Offline Pungsnigel

Junior Newbie





« Posted 2012-05-11 09:48:07 »

Hi!

I'm currently part of project group, writing a shoot 'em up java 2D game. Using the A* algorithm, I managed to sort out the basic enemy pathfinding, and they have no problem finding the players position and start attacking. While implementing the pathfinding, I didn't take into account that the actual enemies would have collision boxes, not just a position to keep track of, resulting in a enemy behavior that doesn't handle walls very well.

Basically, the calculated path is correct, but since the enemy only makes sure their upper left corner (their position) never enter a wall-tile, problems occur when any other corner is the one close to the walls. I don't really know how to handle this, and would be grateful for any tips I could get.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2012-05-11 10:01:41 »

Modify your pathing algorithm such that when standing next to a wall, they cannot make diagonal movements. Currently you are probably allowing every grid tile to allow all 8 neighbours as nodes in your A*; simply don't add ones which would cause the gid to walk through a wall.

Cas Smiley

Offline Pungsnigel

Junior Newbie





« Reply #2 - Posted 2012-05-11 10:06:23 »

Thanks for your answer:)

I made sure they don't walk diagonaly close to walls, they consider themselves as standing in the tile the upper left corner of their collision box is positioned in. The problem is that the enemies think they are walking from one tile to another, while most part of their actual collision box is located in another. So while the upper left corner will never collide (thanks to them never walking diagonaly while close to a wall), the rest of the body will Sad
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline krasse
« Reply #3 - Posted 2012-05-11 11:28:06 »

I always combine the path planning with a simple obstacle avoidance when the path is followed.
It is often quite easy to compute an extra movement offset by setting up repulsive "fields" around objects.

I did so in this (without path planning) and this (with path planning) game.

Offline Pungsnigel

Junior Newbie





« Reply #4 - Posted 2012-05-11 14:56:11 »

Sounds quite a bit like what I'd like to achieve! Do you mean that I should try to make the walls "push" the enemies away, or find some way for the enemies to behave a bit differently when close to walls?
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #5 - Posted 2012-05-11 18:48:57 »

Why not just change things to use their center rather than their top left corner?

Actually now that I think about it, that shouldn't matter. If I want to move to (3,5) on the grid then that means my top left corner wants to move to the top left of (3,5). So unless your walls are jutting halfway between grid positions I don't see the issue if you're being consistent.

See my work:
OTC Software
Offline krasse
« Reply #6 - Posted 2012-05-11 18:52:36 »

Sounds quite a bit like what I'd like to achieve! Do you mean that I should try to make the walls "push" the enemies away, or find some way for the enemies to behave a bit differently when close to walls?

The basic idea is to use several sources to define the movement.
The path following (or where the bot wants to be/go) will provide the basic movement vector and then you simply add contributions from obstacles and other things you want to avoid (grenades, projectiles, team members and enemies). A moving vehicle could contribute in such a way that it makes the bot move out of the way,  but should not contribute at all if the bot is behind it etc.
Then you simply normalize the resulting vector and use it as the new movement direction. Often this gives a nice and rather natural behavior, I think.

Offline Pungsnigel

Junior Newbie





« Reply #7 - Posted 2012-05-11 21:55:15 »

I feel I might have been a bit unclear, I didn't know what information would be needed. The reason I can't calculate the correct vector in the manner you describe is because we designed the game so that there would only be 8 directions. I do like the idea though, thanks:)
Offline Pungsnigel

Junior Newbie





« Reply #8 - Posted 2012-05-11 22:00:04 »

Thanks for answering:)
I gave that a go, and while they are closer to managing corners and such, they still can't. As of now, the corner of their collision box will still hit the corner of the walls. They consider themselves to be standing in the tile that the center point of their collision box is positioned in. This of course means that they may believe that they should go left, from tile (3,5) to tile (3,4), even though parts of their collision box could reside in tile (4,5). If tile (4,4) is a wall, I got myself a problem:(
Offline Pungsnigel

Junior Newbie





« Reply #9 - Posted 2012-05-15 15:17:54 »

Finally got it working! Had to change quite a bit of code, but now it's behaving:)
Thanks for all the answers!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline krasse
« Reply #10 - Posted 2012-05-15 18:57:51 »

Great!

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #11 - Posted 2012-05-18 17:24:33 »

Good stuff. Did you ever figure out the issue or did you just find it working when you redid everything?

See my work:
OTC Software
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (34 views)
2014-11-22 12:13:56

xFryIx (73 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50

digdugdiggy (46 views)
2014-11-12 21:10:15

digdugdiggy (40 views)
2014-11-12 21:09:33

kovacsa (66 views)
2014-11-07 19:57:14

TehJavaDev (70 views)
2014-11-03 22:04:50

BurntPizza (68 views)
2014-11-03 18:54:52

moogie (83 views)
2014-11-03 06:22:04

CopyableCougar4 (82 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!