Archive: 13 posts

---

Without question, AI behavior is one of the most complex aspects of LBP2 programming. I thought it might be useful to start a discussion thread where we can bounce ideas and help each other deal with AI logic issues. This thread is open to discussion on all types of AI design, from sackbots to inanimate enemies or automated player actions. I'll start off the discussion with some of the behavior types I'm using for my upcoming heli shooter, and how I plan on implementing them. Omega Strike (working title) is loosely based off the Desert/Jungle Strike games. It's a scrolling shooter that has air and ground units in addition to fixed targets. My air units are mobile, but because the map terrain has possible collisions, I need to program safety paths for them to follow. Accordingly, I have realized that three behaviors need to be programmed, in a priority scheme ranked as follows: EVADE - avoid solid obstacles in the playfield (walls, buildings etc) while looking towards next waypoint ENGAGE - when the player is detected, navigate to and look at player, ignoring waypoints until player is destroyed NAVIGATE (waypoints) - look at and follow waypoint paths I plan on using a selector to implement my priority scheme, fed by sensors that detect objects proximal to the unit. For evade, I am going to try using followers set to flee, but retain my look at rotators fixed on waypoints. For engage, I use a prox sensor and look at rotator that detects the player. However, I want to program some sort of semi random movement that will periodically reposition the heli. For follow, I am using a tag driven follower that has a large minimum range to automatically select the next waypoint. Setting this to 270 degrees seems to solve the problem of the unit wanting to go back to the previous waypoint.

2011-03-11 18:57:00 Author: Thegide Posts: 1465

---

Ok for storters i seen your level in contraction and i know it's topdown level so you will need to build AI based on movers. I see you want different behaviours depending on situation, so i recomand to use microchip for each behavior and each of microchip being activated by selector via trigger that init the behavior. Selector is prioritized, feather states have bigger priority if there a signal triggering them, in other words if input 3 will get consistent (for example from player sensor) signal, other signal on input 1 wont change selector state. So you need to priotirze behaviors for example State 1 - Trigger: Nothing is around (Input 1 is feed by battery - Action: Patrol waypoint State 2 - Trigger: I see the player (Player/Tag Sensor with higher range on Input 2)- Action: Go to player direction State 3 - Trigger: Player is in firing range (Player/Tag sensor with closer range on Input 3) - Action: Fire in direction of player State 4 - Trigger: Low Heath (Sequencer on postional connected to Heath counter, feed battery on lower time line) - Action: Cover/Heal When Nothing around Sate 1 will be on if there player far it will go attack and when its close state 3 will activate and start fire. When player is destroyed signals on trigger dissapers and battery on lowerst priority takes over turning back to waypoint patroling Ofcorse thats only a example, plan this depending what gameplay you have, you can use any trigger you want but it would be good if it send consistent signal so selector propriety nature will work. I see yu already doing somethign similar Well with walls there a problem, you could need to have complex waypoint system avoiding this walls and make system react to player location or taget location. So for example player is in area 2, enemy in area 1 goes to waypoint that cary him to way to Area 2 and take on player.

2011-03-11 19:35:00 Author: Shadowriver Posts: 3991

---

some of the navigation problems can be solved before any AI is built, by making the basic follow and target work as well as it can (a tank on the ground would obviously need a little slower following rotator than the turret to make it seem like it's moving, then aiming and tracking realistically especially for the Strike games), and then just seeing how it behaves with some bounce and zero friction on the enemy vehicle bodies or surfaces. Chances are some really solid 'dumb' following can be achieved that way, and eliminate all the corner snags you'll come into later if you decide to enhance it with smarter driving. impact and holo is a great way to tell any object what it's colliding with, and if you divide your movement into 4 parts (4 directional movers, rather than an advance mover) it's easier to tell them they can't go 'that way' without the behavior hitch that makes moving objects seem like they're afraid of the object and panicking, rather than navigating away from it, and then returning to follow. there's alot to it, where once you've built your foundations, you can layer the way your enemy reacts to what you do... follow faster, flee and retreat when being fired upon, alternate fire patterns in different circumstances and volley different weapons from different ranges etc you're already full steam ahead and know what you're in for

2011-03-11 19:43:00 Author: Unknown User

---

this would be a nice addition to the Tutorials section.

2011-03-11 20:10:00 Author: GribbleGrunger Posts: 3910

---

Ok for storters i seen your level in contraction and i know it's topdown level so you will need to build AI based on movers. I see you want different behaviours depending on situation, so i recomand to use microchip for each behavior and each of microchip being activated by selector via trigger that init the behavior. Selector is prioritized, feather states have bigger priority if there a signal triggering them, in other words if input 3 will get consistent (for example from player sensor) signal, other signal on input 1 wont change selector state. So you need to priotirze behaviors for example Yep, I already have this in place and it works superbly. Right now I'm trying to figure out the EVADE state. Setting a follower to flee does work, but is a bit on the stupid side. My next approach will probably combine quadrant-based sensors to figure out which direction the unit should turn to avoid repeatedly slamming into the obstacle. Bah... gotta run... will post more later.

2011-03-11 22:34:00 Author: Thegide Posts: 1465

---

I can only program ai up to my own intelligence level. On that note, I have a sackbot that can almost tie its shoes.

2011-03-12 01:08:00 Author: Deftmute Posts: 730

---

this would be a nice addition to the Tutorials section. If the discussion proves productive, I will likely write up an article for the tutorials section.

2011-03-12 01:13:00 Author: Thegide Posts: 1465

---

I would recommend reading up on subsumption, for anyone who is interested in developing ai systems in lbp. It's biologically inspired and was specifically designed around low power electronics of the 70s, so lends itself to lightweight concurrent networks, which is basically what we have in lbp. It was also largely developed around robotics, which is pretty much you largely want to achieve in lbp, it's just that your robots are virtual. There are a few other aspects of lbp logic that lend itself to to subsumption. One of the main advantages of subsumption is that it is build up in layers orf simple behaviours that can interact to create sophisticated emergant behaviours. It's also very simple to understand at the higher levels. Edit: Mid 80s, not 70s. My bad. Also Wiki link (http://en.wikipedia.org/wiki/Subsumption_architecture), not that it has much detail but is a start. Not that I expect anyone will bother going out and buying textbooks on the subject, but if anyone is really This book (http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=3776) is a really good resource on Robotic AI and not too difficult to read (this was my reading material on holiday a few years ago, because I'm kewl )

2011-03-12 01:58:00 Author: rtm223 Posts: 6497

---

I've been playing around with sackbot AI a lot recently, and the main issue I've found in programming their behaviours is the fact that flying sackbots (with movers/followers guiding their movements) get so easily squashed when touching any acute, obtuse and right angles in the environment. So, if a flying sackbot moves into the right angled space where a wall meets a floor or celing, there's a good chance that he will die. Has anyone else found this issue extremely frustrating or come up with a viable solution to it?

2011-03-12 13:26:00 Author: Ungreth Posts: 2130

---

It doesn't even matter if they are flying or not, the movers you need to use to get sackbots to become mobile enough just apply too much force on them. My primary method of avoidance is to detect surfaces all around and cancel any mover moving towards that surface and also normally push away slightly. It has prevented the vast majority of squishes on my penguins in penguin turf war, but it's still not 100% An indestructable tweak would be awesome.

2011-03-12 13:33:00 Author: rtm223 Posts: 6497

---

It doesn't even matter if they are flying or not, the movers you need to use to get sackbots to become mobile enough just apply too much force on them. My primary method of avoidance is to detect surfaces all around and cancel any mover moving towards that surface and also normally push away slightly. It has prevented the vast majority of squishes on my penguins in penguin turf war, but it's still not 100% An indestructable tweak would be awesome. When the entire progression of a level depends on "assassinating" sackbots by triggering novel, creative death scenes for them, 100% dependability is an absolute necessity. I don't wannna give away much about my current WIP, but I have a scene where a hawk-bot swoops down from a tree and kills you, then returns to it's perch again. There's a certain method of outsmarting and destroying the creature, so when it accidentally gets squished in a corner of the scenery and the intended death scene fails to trigger, then the whole level becomes uncompletable. It's been a nightmare trying to work around this issue.

2011-03-12 13:47:00 Author: Ungreth Posts: 2130

---

I don't suppose gluing a softly curved piece of invisible material into the corner would work?

2011-03-12 15:12:00 Author: Unknown User

---

It doesn't even matter if they are flying or not, the movers you need to use to get sackbots to become mobile enough just apply too much force on them. My primary method of avoidance is to detect surfaces all around and cancel any mover moving towards that surface and also normally push away slightly. It has prevented the vast majority of squishes on my penguins in penguin turf war, but it's still not 100% An indestructable tweak would be awesome. This is what I ended up doing yesterday to program my EVADE behavior. Blocks of invisible holo set with impact sensors that respond to the environment (use tags) can be used to trigger changes in behavior before it's too late. I took this one step further and broke my detection holo into four quadrants (front, sides, rear) and apply different changes in my mover patterns accordingly. A front detection initiates a rotator that turns my object 90 degrees - I also take into account if either side is impacted to determine which direction my object should turn. A side-only detection keeps my object traveling in a straight line, and rear detection initiates a flee follower. Otherwise, my bot follows whatever tag I tell it. I'll try to post pictures next time I'm on so you can see the circuit.

2011-03-12 18:31:00 Author: Thegide Posts: 1465

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.