A House Built on Sand: Engineering Stable and Reliable AI
ฝัง
- เผยแพร่เมื่อ 1 ก.ค. 2021
- In this 2019 GDC talk, Havok's Ben Sunshine-Hill shows you how to engineer AI systems which remain stable and robust even in the face of changing requirements.
Register for the all-digital GDC 2021: gdconf.com/passes-prices?_mc=...
Join the GDC mailing list: www.gdconf.com/subscribe
Follow GDC on Twitter: / official_gdc
GDC talks cover a range of developmental topics including game design, programming, audio, visual arts, business management, production, online games, and much more. We post a fresh GDC video every day. Subscribe to the channel to stay on top of regular updates, and check out GDC Vault for thousands of more in-depth talks from our archives.
Great talk, not specifically about AI but in general about programming.
Especially documenting intent that's something that's missing way too often.
Pathfinder in general is a far more convoluted thing. When you are proving a math theorem, you're basically finding a path from axioms to the theorem's statement. So it has to know about all the axioms. For example, given an obstacle, do you have the means to overcome it (that red door theorem requires a red key lemma, which you have to prove in another part of the dungeon)? Same way, if you use say LLM to control your chickens (because the game, like Minecraft, got too complex for exact solution), it has to know what are the chickens and if they can open a barn door to look for food outside, and if chicken will look for food in water, like ducks, and it must also know your local constrained toy definition of a homebound chicken, who wont leave the farm.
Wow, one of the best talks I've ever seen. Adressing the lack of motivation to comment the code is cherry on top !
Still at 1/3 of the thing and already wishing I could like it twice. Its one of those talks. Its goin' in the playlist.
As a devleoper in a large corporation, I can say that documentation is always lacking and has been at every job.
Bad documentation can also be a problem, if its not what the code is doing and become misleading for what functions do.
So pure text comments have limited usefulness , the real gain are Assertions and functional documentation, that actually checks themselves if their assumptions are still true or not, and get tested automatically, especially if changes are made (as too often, changes are made, but the old-documentation stays, so the new code does not do what the docu says, and that makes it just more difficult to understand and debug).
Dyl
will always be the case, use ai on it
That was one hell of a talk - funny but technically solid, specific but broadly applicable. I came for the game AI but stayed for the canny discussion of the problems I face every day in my non-game job. Would love to hear more by this speaker.
Oh wow Ive had both of the problems described here on my game, so they are very much real practical issues.
I fixed the optimal attack distance by having a range, say the enemy wants to be between 0.5 and 1 units away from you and when it asks for a position it asks at the middle of this range, so 0.75 units away from the player, this way you get consistent attacks when you cross the 1 unit distance barrier (super necessary for melee combat).
Problem two required an AI director, that takes information from the enemies on the field and picks one to engage then I use a table to calculate when to switch to another enemy (after the engaged enemy has attacked, or been hurt, or enough time has passed)
AI director is a great solution! I think that's probably what he meant when he said a "squad system", though his squad system example looked like the player doing all the calculations while a true AI director is a separate game object entirely. And you're right, enemies shouldn't be deciding who attacks based on who's closest anyway ;)
15:56 Melee-ing
This is a good talk about thinking about programming.
As someone who did some CS but was mostly Electrical Engineering this has been helpful. I’m good at creative side of doing my own game programming, but lack some higher level programming thought process with some low level specific examples.
I love this talk because for once it's very technical and specific.
Not boring at all, very eye-opening. Interesting and informative. Great one!
great video and great presenter. The principles described here are definitely applicable outside of game programming too!
Extremely useful talk. Some of the problems illustrated here were actual roadblocks in my development. Cleary scoped concerns of each part of a system are so important.
One of the best talks of this year IMO. I'm not sure how related it was to AI all in all, but it definitely was very interesting!
Hysteresis is a great concept for the error-band that was discussed! Like a thermostat: if you approached not attacking, start attacking when you've passed through the error band. If you're retreating, stop attacking when you've passed through the band in the other direction.
Aircon systems work using liquid nitrogen and fusion plasma alternately. When you're too warm, the liquid nitrogen is dispensed until you're too cold; then the plasma ball cruises the room. The time it leaves you suffering for, is a consequence of the bandgap, and the installers ability to hide the thermostat far from the victims... I may have had too much coffee...
The problem with using hysteresis -- which I agree is a powerful tool -- to encourage stability is that it adds latent, uncontrollable state to your simulation. Suppose that you're testing out an air conditioning system (which I'm, uh, pretty sure doesn't work that way), and suppose a bug has been reported which only occurs at 23 degrees celsius, when the setpoint is 25 degrees. If it didn't use hysteresis, those temperatures would be the only thing you'd need to know to repro the bug. But with hysteresis, you also need to know the recent *history* of the temperature: was it currently on or off? At what temperature would it have turned off or on? In the context of AI, that latent dimensionality grows very quickly, making it difficult to reason about the potential behavior of the simulation in a given visible state, and very difficult to reconstruct a set of events leading to a given full latent state.
@@bensunshine-hill2050 I'm pretty sure I'm a latent uncontrollable state that was added to The Simulation... I must have history...
I have never done any programming but i find this fascinating.
@23:50 nice example of "Chesterton's fence", and issues around it. Communicating a good explanation for something makes that thing "stronger" than it otherwise would have been.
This is great - reminds me of Hardware Abstraction Layers :)
spectacular talk
I'm not a coder, but love logic, perception and anthropology... I know this sounds weird, but this talk was excellent.
13:20 lol, this can happen not only due to floating point imprecission but also by implementing target range. So enemy is set up so it treats ArriveToTargetPosition to be true if enemy is within 0.5 unit range. Seen that often for example to ignore small and jerky movement requests when enemy clearly has enough attack range. But breaks use case when you need to move enemy to exact position due to scripted sequence which comes in months after this loose ArriveToTargetPosition already became fundamental part of whole AI framework xD
very helpful, not only for AI
Once you get used to documenting, it's great!
Document intent before writing code!
That way, you get to thrash out the ideas and think about the bigger picture which often affects the implementation, while you're developing a hunger for watching the code do it's thing for real!
Think of it as foreplay...
Thank you! // edited for spelling
Well, maybe i'm wrong but most of the problems he raised here are solved by applying Solid principles to the architecture, especially on the lowest levels
A few of them, certainly! Game AI does often work well with an OOP approach, and proper layering benefits from an understanding of the various dimensions of separation and interdependency. I wouldn't say that SOLID principles are a panacea for reliable AI engineering (or reliable code in general) though, just a good start. They don't have much to say about defining semantics, for instance.
@@bensunshine-hill2050
If your architecture is bleeding up and down - it's a Solid violation, if each of your enemy instances decides whether it attacks first - it's Solid violation, if you need to know some intentions beside the code itself and a comment it's a Solid violation, if you need to change the code it's again Solid violation - you extend the established code not change it.
While catching errors because of != instead of < is just a bad programming in both cases, imho)
Solid is not a panacea certainly but it provides some basic rules that help you to keep your architecture together) Better use it or something similar than not.
After few moments i realized that SOLID(or any other similar principles) is an architecture for a your code architecture. Some meta stuff :D
Great talk as an illustration for a first commandment violation - mistakes and inaccuracies on the architecture design phase are almost impossible to fix the later you notice the misconception. It's snowballing the faster the lower it lies and you are doomed to fix the never ending consequences of a flawed foundation)
Think of an example of bad AI
*thinks of Cyberpunk* 🤣
0:15 - 🎼 Hello my baby, Hello my honey, Hello my ragtime gal....
1:19 can I use this to roast someone?
This was excellent! As a solo dev I still feel all of this applies to me, because I forget why I did stuff!
Leaky abstractions can be so much worse than 'no' abstractions
1:19 And that is how skynet became evil.
I'm not mad, I'm just disappointed in you, AI 😃
12:09 maybe for determining whether 0.999997m is good enough fuzzy logic must be applied. It's what its called for Xd
It's incredible and bothersome how often you need to tell "professional programmers" to actually produce professional code/docs... it bothers me to no end. That's why I'm "The Bad Guy" ™ during code reviews.
Especially with agile being hip and commenting being out of style (because well written code shouldn't need it, or so is the reasoning). It's also hard to enforce, because once you tie it to metrics and enforcement etc, people often write tons of comments that just look good when it comes to coverage but says nothing about the quality.
@@EelcoHillenius in many cases, the reasoning is sound, in that... if code needs comments on what it is doing, it should make you think... "What can I do to make this intent clearer"? Refactoring into smaller sections with descriptive identifier naming?
A great book, "Clean Code", implies comments should be somewhat painful. Not to say no comments ever, pointing to designs and "why" code is doing something is a perfect case. But describing "what" code is doing is generally a smell resolved by refactoring into something easier to read.
That's all folks are probably getting at. At least those that understand this concept.
Useful comments describe the why, and even the best structured code needs some of that. Things you can't read from the code, like what alternatives were considered and why was this approach picked, and what might be an alternative when that breaks down. I also like to document when I went for a solution that works to get something done but we might revisit in the future (with a reference to a backlog ticket), and while I generally agree that you should be able to read what code does just by following good naming conventions and such, sometimes if you have to do something fairly complex (say write a parser) it's not always helpful to break that down to the max, but keep the code compact and guide the reader with some extra remarks. It's fairly subjective in the end what makes good documentation, but the effort should be made (as Ben says in his talk).
@@EelcoHillenius I think the example of a parser is pretty interesting, as it's generally one of the most hilariously self documenting pieces of large amounts of code you're likely to see. At most, you will have a top level documentation about the approach and preferably a grammar spec, some usage information on the input and maybe helpers, but then the main body is just a million parse_foo() functions that all clearly and obviously map to the syntax.
Assuming you're writing a recursive descent parser, if you're using yacc or something I feel sorry for you.
I think the video guidance: roughly, documentation doesn't have to be comments, and use comments to tell a story about why this code exists, is the best advice I've heard on it. Most of the time: there's *some* story about why the code exists, even just "// bleep bloop, standard input loop" tells you that there's nothing clever that's supposed to be in there.
@@SimonBuchanNz hah, you're right actually, maybe a poor example I picked. I just checked the last parser I wrote (custom code), and the documentation mostly just explains the DSL it's parsing and what the target is.
great talk, though it is not named appropriately
Cyberpunk AI
Basically SOLID :)
That whole section on the combat system checking the distance to the player - why is combat checking distance itself? Shouldn't that be a call to the pathing system? Because then the pathing system can return a consistent result every time. You can have a pathing function getDistance() that returns how far the caller is from a destination. Then the AI isn't doing its own separate calculation, and the pathing system won't return hasArrived=true until getDistance() is actually 1m (unless the player is moving, but I digress). Part of that layers thing. AI shouldn't be using raycasting distance anyway, it should be using path distance - otherwise you'll have AI attacking players through walls and your AI team starts having to do occlusion checks and all of this is already happening in the pathing system anyway.
There should also be tolerances in AI movement, and there should also be squad systems so only one object (the player) is doing the distance calculations. But don't have AI doing stuff that pathing should be doing.
Me over here just repeating the first half of the talk.
Alien Isolation is considered stable and reliable?! It was just me stuck in a locker for 10 minutes waiting for the "stable genius" to pass?
There was a typo in the script that fucked up the Alien AI. The Alien AI was quite good before the typo.
@@chikato7106 That's regarding Aliens: Colonial Marines, not Isolation. And fixing it doesn't really help that much.
Get the f#ck off) Lockers are making noise, lockers are in the closest proximity to the Alien anyway, Alien hear you breathing if you aren't constantly holding S and RMB, maybe you were using the tracker while sitting there - it lures the Alien. 10 minutes sitting in the locker clearly shows you have no idea how to play this game and it's not teh AI to blame.
@@yrussq Go back to your fanboy closet XD
@@jonathanxdoe pfff)) it's you who were hiding for 10 minutes in your "i don't know how to play" closet))
No more slides
- Go away
The talk says it's about AI, but really it's all about working in and coping with a tech debt laden code base - and that gets more and more obvious as the talk goes on.
I, in the speakers shoes, would have called the talk something else and just said "I'm using AI as an example because that's what I'm familiar with". There's not much to learn here about making good AI specifically.
I agree that almost everything I covered is applicable outside AI. Nevertheless, the set of topics was selected specifically for AI; those are the points I felt would make the most practical difference in the time I had. (If I were talking about coding in general, nearly the entire talk would have focused on defining/naming concepts and testing.)
In the original outline for the talk, I did go into some specifics about utility functions, hysteresis, and latent state (the floating point tolerance stuff originally led into it), but I ultimately cut that topic because I didn't feel I had the time to get far enough into it to give people really useful takeaways.
I disagree, though, that the talk is specific only to "tech debt laden code bases". The notion of tech debt implies the logical possibility of objectively optimal design, which a team could get to if only they'd spend the time. But practical software development involves compromises, not just between quality and ship date but between independent and irreconcilable measures of quality, meaning you can run into problems even if everyone's doing everything right.
@@bensunshine-hill2050 well said, and thanks for the talk
First comment :P
how come，i was just about to type
cum
& in RPG MAKER you just create a region system where & add # & if number one NPC can't pass, region one whole area around farm, then you can maybe add a condition branch for region one to let npcs move pass if not chicken, more of a region block event if X.
No need for a smart AI or smart Chicken.
The other option is Chick AI track event X.
Chick will move towards/face direct + only
step forward if facing the Chicken Coop.
ITs the chicks job to search its surrounding for
objects it like for XYZ reasons, food/shelter...
The you can add behavior change based on
time of day/night for the chickens to apply.
Goblins attacking scripted event, that sounds funny. So you could try this.
I'd code the AI to harass & stalk(move away from if to close) the player but
not attack if player controls disabled, which should be during scripted scene.
I'd probably solve that melee out of range with a HIT & A HIT SYSYEM.
if the attack won't go off or is set to miss if out of range that is bad design.
I'd allow the attack to go forward & add a step towards function, you take
a small step closer to the target the recalculate if your close enough to hit.
If you were close enough for it to be a hit it will hit if you were just out of range
well if that step factor didn't getting you all the way there then the missing
is justified. I'd call this extended reach.
If enemies are waiting turns it better be for a good reason, & lets say there is one
such as the game crashes if the player is hit by multiple attacks so you added
frames to stop additional attacks until first attack finishes, SO NO COMBOS.
Which enemy should attack first, distance, damage, defense, check who is
closer with more damage output & higher def/hp% ratio if countered.
You'd likely not see anyone standing around in this scenario, on the off chance they were
the same enemy with the same weapon & armor/hp, well that is where good game design
fixes the issue, if your damage output has a random 1% variance, same for armor, the two monsters would likely not be in total sync after each check so maybe a 2 sec delay, which is not noticeable or exploitable by the player.
I like documenting errors but keep it basic, you write the line of code & make a fix & while keeping the unfixed code there but # hashed/greyed out not as code but as comment, this way you can always go back to the OG, the downside is it bloats the size & might slow it down abit but not enough to make in a game format very much & they can be removed later if you want once everything just works.
documentation is the key. This sound quite clear today, don't be the same tomorrow.