Odd Glitch in Company of Heroes
Labels: cheating, Chris Jurney, Company of Heroes, logical error, Opposing Fronts
| Feedback and ratings: |
|
|
|
|
IA Information
Communication
Dave Mark's book,
Previous Posts
Archives
|
Post-Play'em - Observations on Game AI Thursday, February 11, 2010 Odd Glitch in Company of Heroes
Just to be clear, I really like Company of Heroes. I have always been an RTS fan since the original Warcraft and progressing through Starcraft, Age of Empires/Kings and especially Empire Earth. That being said, CoH is very well done.
I only recently got around to grabbing the full version of the original CoH and the expansion, Opposing Fronts. (Thank you Valve weekend sales!) My prior posts here were only about the downloadable demo. Obviously, there are some significant differences in the full release version. I like them all. Rather than continuing through the script-fest that campaign maps usually are, I have been playing a lot of skirmishes against the computer. I find a lot of the tactics by the computer to be pretty familiar for RTS games. For example, as I mentioned in a prior post, it is obvious that there is a lot of influence mapping going on. If I find myself a little behind on producing units, I will often be drawn into a series of dashing from defense point to defense point as the computer picks on whatever is currently the weak spot. My only question in this situation is how much is the AI cheating with knowledge about my force disposition. I know that it is not that easy to discern what the computer has placed and entrenched... it seems like he knows where my weak spots are even if they are deep within my territory. Anyway, as I was playing a skirmish map, I ran across something very odd. Normally, I had been playing against the "normal" level of difficulty. I had been winning fairly regularly against that level, however, and decided to ratchet it up one level. I was playing the Lyon map against the computer on "hard." Because this was a control point map, I was quite used to meeting the "normal" AI at the river as we battled for those 3 points. I figured that the "hard" AI would be just as quick to get to the river. However, I captured the first point... then the second... without seeing the AI at all. I began to suspect that either something was dreadfully wrong or that "hard" used a different tactic than "normal" - such as "build up and crush him" rather than "dash for the control points". Not too long after that, it became obvious that something was indeed seriously amiss. Thanks to the wonders of replay files, I was able to go back and witness what the computer did... or did not do. A video is included below. I sent the video privately to my friend and colleague, Chris Jurney, who did much of the excellent AI work on CoH. He thought it was amusing as well. His speculation was that the Lua script exploded somehow. It obviously didn't cease working entirely because we see some orders trickling through at times. He invited me to send him the replay file so that he could forward it on to the Relic programmer who is responsible for it now. It doesn't seem to be a problem with the map itself as I did go on to play a new match on that map on "hard" and it proceeded to hand me my buttocks as I expected. On the other hand, it may be a problem with a combination of that map, that difficulty level, and a randomly selected tactical approach that knocked a variable out of bounds or something. Regardless of the cause, this is a great example of how important testing is... and yet things still slip through. Anyway, I will try to do more video captures of some games later - especially the view that shows how the computer is moving throughout the map during the game. That has been very interesting to analyze because it shows how the influence mapping and even the pathfinding is working as part of the decision making. Labels: cheating, Chris Jurney, Company of Heroes, logical error, Opposing Fronts
Monday, February 11, 2008 Civ 4 and Bioshock updates A month ago, I mentioned that I was going to be doing analyses of Civ 4 and Bioshock. Well, I have decided to wait until after the GDC next week. The reasons are clear...1) I will be attending a lecture at GDC by none other than the man behind the AI on Civ 4, Soren Johnson entitled Playing to Lose: AI and "CIVILIZATION". From the description of the session: Artificial intelligence performs a crucial role for any strategy game, providing a compelling opponent for solo play. While many of the challenges of AI development are technical, there are also significant design challenges as well. Can the AI behave like a human? Should it? Should the game design be adjusted to accommodate the limitations of the AI? Should the AI be exposed to modders? How do we make the AI fun? Should the AI cheat? If so, how much? Do we even want the AI to win? [...snip] And from Soren's own blog, "Designer Notes" on a post entitled "A Farewell to Civ": Essentially, I will be talking about the difference between thinking of the AI as the player’s opponent and thinking of it as simply an extension of the core game design (what one might call the difference between “good” AI and “fun” AI). There will also be a long section on AI cheating - the bane of my existence for many years - concerning which type of cheats are acceptable to players and which type are not, using Civ as an extensive case study. Further, I hope to prove that, for Civ at least, there is no such thing as - and never could be - a “fair” difficulty level where the AI is playing the same game as the human. Your mileage , of course, might vary. Given that I will be getting a peek into what he was actually doing in the AI design, I don't want to stick my neck out and make comments about how wonderful this or that was and find out that it was either unintentional or cheating. That would be embarrassing. Also, I'm hoping to have the opportunity to interview him - or at least hang out with him to some extent. That would provide a lot of great material for a Post-Play'em entry. 2) On a similar note, I received this email a few weeks back under the subject of "Bioshock on Post-Play'em": Oh yeah... that wasn't even remotely intimidating! I've talked to John a bit since that point... he's actually really cool about the whole thing. It's not like I was planning on ripping his work apart anyway. I'm actually quite impressed with some of the things I've seen in the game so far (I'm still not terribly far in.) We are planning on getting together for a while during GDC. I'm very much looking forward to meeting him and talking shop. In fact, I hope to pick his brain a little on some of the much heralded AI in the game.So that's what's holding me back on doing those two games right now. I hope to be giving you some juicy tidbits... if not next week during GDC, then possibly the week after I get back. Remember to keep an eye on the IA News blog next week as I report from the GDC and let you know all the nifty stuff I see and do (complete with pictures!). ... if I make it home without going into a coma. What a week GDC is! Labels: Bioshock, cheating, Civ 4, GDC, John Abercrombie, Soren Johnson
Thursday, December 13, 2007 Doom 3: Pretty Wind-up Toys
I dug out my Doom 3 again specifically for this blog. I hadn't ever finished it when I started playing it about a year ago. It sure was purty, but it just didn't engage me the way that I was hoping it would. Anyway, my thought as I returned to my saved progress was "pay attention to the AI so I can review it." As I played, I became a little unsettled - not by my progress in the game, but by my progress in my quest for AI. I finally had to come to a realization that seemed almost blasphemous or sacrilegious.
Doom 3 doesn't have AI. Sure, I know that statement is a little over the top. Let's face it, the AI in Doom 3is better than that of games from when I was a kid in the 80s. But that is also the heart of the problem. Doom 3's AI isn't much better than what was in the original Doom in 1993. Considering the related concept of Moore's Law, you would think thought that AI would have increased at a geometric rate similar to that of anything else in computing. It is with that expectation that I claim that Doom 3 "doesn't have AI". Looking backwards down a Moore's Law curve of AI, one could make the statement that the AIs in the past approach zero... therefore being zero for all intents and purposes - especially in a relative sense to where they should be today. So... my statement is now qualified somewhat. (Why do I feel like I'm going to end up having an uncomfortable beer with someone from id at the GDC in February?) The comparison to the original Doom (or Quake, et al) is not far from the truth, however. The state machine has to look something along the lines of:
That's it. In the newer versions, you can splice in something towards the end that involves a side-step. The bad guy marines especially will do this. To me, the player, this makes me do the very involved strategic and tactical process of... uh... re-aiming my gun. Wow. Admittedly, there are some baddies that give me more fits than others because they are not approaching me in a straight line. Lost Souls tend to zip around like gnats once they get close to you which is mildly annoying and Cacodemons will float around as you shoot them - but that means they have as much AI as a helium-filled piñata. There are other differences as well. The half baby/half fly Cherubs will back off a bit, prepare a moment, and then leap. Of course, so do the little spider things. This is a major let down. I remember seeing some in-game clips at a game conference during an interview with Carmack. (I believe it was at E3.) The scene where the pink baddie tried to beat down the door, gave up and instead came crashing through the window was terrifying! "Wow! It gave up and used the window!" I told myself. When I played the game... and that exact same sequence happened, I realized that the whole thing was scripted. Oh. Bummer. Again, it wasn't AI. Unlike F.E.A.R, where the agents do use their environment and re-plan when faced with obstacles such as the door above, the Doom solution was a movie crafted for my benefit. I have been flanked by the computer, however. This I admit. Often! But that has nothing to do with the AI and everything to do with the placement of triggers. In true horror movie fashion, the computer does come up behind you often - but only because a designer placed a trigger on the floor that says "when player gets here, spawn evil dude behind him". That isn't AI. It isn't even fake AI. In fact, it's getting rather tiresome to know that every step I take is likely to Really, the movement and attack logic for the enemy is not much more advanced than the little table-top wind-up toys. They will chatter away in my general direction, but there isn't much purpose or reactivity to their actions. That gets very disappointing. There does seem to be a bit of cheating going on, as well. The first time I fought a Mancubus, I was doing my best to flank him around walls. Despite having moved at least 60° off to the side, when I poked my nose around the wall to take another shot, I found he was already facing right at me. The explanation would have to be that there is omniscience on my position. Here, I had decided to do a simple, but what I thought clever, evasive maneuver only to have the game say "tough... I don't care". It's deflating to have that happen.There also may be some cheating going on for my benefit as well. This doesn't fall exactly into AI, but it is relevant nonetheless. I swear that I take less damage per attack when I am almost dead. I haven't done the math yet, but it seems that I can be in the teens or single-digit health for far longer than I spend in any other 10-number range. A hit that takes me down from 100 to 80, for example, may also only take me from 15 to 10. The result is that I spend a ton of time between 0 and about 40. Of course, if this is happening, this is a great device for creating tension in the game - and is a variant on rubber-banding. It's rather artificial and arbitrary, though.
I have always respected John Carmack for his vision - and the "visions" that his games have provided for me. I just can't help wondering what would happen if they were to put a bit more focus on AI. I notice on the Wikipedia site that Johnathan Wright is listed as an "AI Programmer" but that in the credits for Doom 3, he is just listed as a "programmer". I would love to sit with him at a GDC party and have that beer. "What's up, dog? Is there anything else you could be doing?" I can't blame him, necessarily. Given the depth of the graphics rendering, he may very well just be out of clock cycles. *shrug* I hope that he has a better chance in the future. I would very much like to see an id offering that does "speak to me." Until then... there's more than enough to challenge me elsewhere. Labels: cheating, Doom, Doom 3, F.E.A.R., fake AI, FPS, id, scripting, The Sims
Friday, November 30, 2007 Call of Duty 2: "I saw that grenade coming!" Another quick observation from my perusal of "Call of Duty 2" for Xbox 360. I've noticed rather often that, when I toss a grenade, the intended "recipients" seem to know that it is coming as soon as it leaves my hand. They will yell some German variant of "Holy crap, there is a grenade! Run, dude!" This is all well and good if they are seeing the grenade coming and would like to amscray prior to its arrival. However, the quirky behavior comes in when I am doing something like bouncing it off a wall around a corner. I will hear them shout prior to the offending pineapple even making it to the corner that I am trying to circumnavigate. In other words, they either saw the grenade through the wall, or there is some sort of mirror-like sheen on the wall that allows them to see it coming. The programmers seem to be using a messaging architecture wherein an event triggers a reaction in all agents within range. For example, if the grenade were to explode in front of them, the explosion itself would send a message out to nearby agents saying "if in range, die violently". Messaging architectures are opposed to polling architectures where the agent is constantly looking through his environment to see if there is something to react to. Using the same example, the agent would constantly have to scan the nearby world to see if a grenade has exploded. Since grenade explosions are relatively rare, this would be a lot of wasted CPU. As you can see, messaging architectures are more efficient for event based situations.In this case, the landing area of the grenade is roughly calculated. If the projected landing spot is near an agent, they react appropriately. They yell out warnings and move away if necessary. However, the programmers would have faced a quandary as to when the grenade itself should send a message. If you wait until it lands or bounces off of something, it would discount the very possible scenario that they could have seen it flying through the air in the first place. If it is triggered when it is thrown, it creates the issue I observed above - that they know it is there despite the fact that they should not be able to see it at all. One solution (albeit not a very efficient one) would be line of sight checks along the path of the grenade. Once a grenade launch has happened - and a message dispatched to the agent - the agent would now have to do a line of sight (LOS) check. If the grenade is visible, all is well - react appropriately. If it is not visible, the agent would have to change techniques to a polling architecture specifically doing periodic LOS checks at the grenade. When you consider that there may be 10 or 20 agents (friend and foe) in the area, multiple grenades in the area, and each agent-grenade LOS check would need to be done many times per second, the computational overhead adds up very quickly.Another potential workaround would be to create a plane that is the intersection point of the path of the grenade and the visible area of the agent. At that point, the "see grenade" event can be triggered once the grenade passes that point. That seems to be not much of an improvement since there would be as many planes as there are agents and the grenade would now have to poll the planes many times per second. The overhead would be similar to the first example. There is another way of handling that, however. Once the plane is generated, the distance from the source to the intersection of the plane can be calculated. Since the velocity of the grenade is near constant, the time delay until the projectile reaches the plane can be established. The message can be sent with a delay of x number of frames (or any other way that the game loop timer is built) so that the message is delivered and activated at the point that the grenade would have come into sight. No polling is necessary at this point. Just like before, a single event message is sent. The only additional overhead would be creating the planes representing the lines of sight for the agents in the area. In fact, if the LOS check is successful at the beginning of the throw, the plane creation is not even necessary. If an agent is going to yell to his squadmates about the throw, you don't need to do LOS checks for them at all - they already know. It would take some testing to find out how much overhead this eats up, but the result would be that you could do stealth/surprise grenades in a much more realistic fashion rather than the current "I saw it coming around the corner" effect.(More observations of "Call of Duty 2" for Xbox 360) Labels: Call of Duty, Call of Duty 2, cheating, event, FPS, line of sight, LOS, messaging, polling, vision, XBox 360
Wednesday, November 28, 2007 Call of Duty 2: Omniscience and Invulnerability Enemy Invulnerability: "I can't be bothered right now." I was on the level where your convoy through the town in Tunisia gets ambushed. I had to start it over and over because I was getting pelted by the guys on top of the walls. I finally got down where I should hide and who I should tag first. One thing kept bugging me. There was a string of guys appearing on one wall in order. Most of them were gunners shooting at me - but there was one that had a Panzerschreck. I would try to shoot him over and over and he wouldn't die until he had fired at one of the tanks/trucks in my convoy and blown it up. In the mean time, another one would pop up and take me down. I realized that it was pointless to try to kill this dude at all. He wasn't going to kill me and that tank/truck was going to blow up anyway. It was part of the level. What annoys me, however, is that it took me a number of times before I realized that, until that guy got his shot off, he was invulnerable. As soon as he was done with his job (that I was trying to prevent) he was now able to be shot. I wasted valuable time and got very frustrated by the fact that the level designers had decided that this was such a required series of actions on the level that they would break the rules. I have found other instances where I have tried to peg some dude that was threatening me and was dead in my sights only to find that he had some sort of mission that couldn't be stopped. That really exposes the scripting in the game. I understand why the scripting is there - and, in general, it is very well done in the game. I very much love some of the actions that happen despite the fact that I can tell you the exact line I crossed in order to trigger the action - but usually they are too fast for me to react to or something that is meant to be just watched anyway. Don't let me point at a guy and unload an entire clip into his spleen while he doesn't seem to care that I am there.To me, it seems like this is a case of the "anti-sandbox" concept. Sure, a somewhat linear game like CoD isn't meant to be a sandbox - and there are certain things that have to happen to advance the plot. That's fine, but I always feel cheated when I can't change the series of events even if I do the right thing to disrupt it. Enemy Omniscience: "Am I wearing an orange hunting vest?" A possible solution to this is to measure how much of me is visible and then combine that with a coefficient based on how far "off center" I am from their current direction of vision. Perhaps another factor based on movement. I know that is a bit expensive to calculate for each AI (since their fields of view would all be different). Another potential solution is to cast multiple rays to different parts of my body - perhaps shoulders, head and a couple of lower torso spots. If more than ONE is visible, then I can be seen. Not knowing exactly what mechanism they are using, it's difficult to know how to improve upon it. This is even more alarming when it is obvious that there is a bias towards firing at ME. I may have 10 squad members all hidden behind objects and taking pot shots at the enemy - or even running around in the open, but damn it if the AI doesn't want to fire at me instead. It doesn't happen all the time, but it is obviously biased more towards me than my squad-mates. This is an obvious design decision to make it more exciting. I understand that. However, when combined with the omniscience above, it's kinda creepy. [note: I've realized that waiting to write one complete writeup on a game is sometimes prohibitive - so I will write as I think of things... and tag them by game so you can find all relevant stuff] Labels: Call of Duty, Call of Duty 2, cheating, FPS, scripting, vision, XBox 360
Friday, November 9, 2007 Mario Kart: Double Dash
One of the obvious characteristics of the AI is its use of FSMs. This is something that is in use in most games today on some level or another. However, there were some distinct points where it was very noticeable that the AI was switching. For example, once you crossed the finish line, your team either went into “celebrate” mode or “whiny pout” mode. These were simply repeating animations that continued throughout the duration of the post-race promenade (for example, while you are waiting for your wife to finish because you left an ocean of banana peels for her to wade through causing her to look strikingly like Kristi Yamaguchi doing non-stop toe loops down the final stretch). However, if you are to get whacked in the behind by an errant shell, you will immediately transition into the crash state, then the “stunned recovery” state for a few cycles of the animation (about 2 seconds). Then, magically, you will begin to celebrate once again. It makes it very easy to see that there are very defined edges to the states (and likewise the animations).
There are some sub-states mixed in there for the more subtle animations, but they are usually very short-lived. The driving mode, especially, has extra states for turning, sliding, punching, taunting or even just looking around because there’s nothing going on. ![]() The reason that this became apparent to me was the first time that I saw two opponents in front of me fighting for the exact same stretch of road. There was more than enough room for them to maneuver, but they insisted on being in the same spot for some reason. What’s more, that “spot” was meandering back and forth along the course… as one car drifted left, the other went right along with him. As they drifted back, they did so together like Ben Hur’s chariot trying to dice up his competitor’s wheels. Not only was the path dumb and the colliding dumb, they were being dumb in sync with each other. Solution? Put a repulsion vector on each other so that following the path is not as high a priority as keeping from scraping paint.I’m not entirely sure what causes the AI to switch paths. Obviously an event like a spin or crash would cause the AI to pick up a new line. However, it is difficult to tell of the AI changes lines when nothing else is happening – like a cross-country skier stepping into a new pair of tracks. This does, happen, however. I’m just curious as to when and why. Certainly not when they are bumping and grinding down the straightaway, however. There is another factor, it seems, behind why the paths are the way they are. Not all paths are created for all cars. If the AI is in one of the big heavy cars, for example, they will tend to pick a path that wanders back and forth across the track. This is very noticeable with Wario’s purple beast. He drives like he has imbibed heavily. This is an interesting balancing mechanism – Wario’s car, like other larger cars, is fast once it gets up to speed. If that were left unchecked, once he passed you, he would be a bitch to catch up with. However, if that speed were spent meandering all over non-optimum lines, it slows down his progress and makes for a neat stylistic appearance as to what we get out of ol’ Wario’s character. It is difficult to know what exactly is happening behind you in the race except on such short tracks as Baby Park. Does Wario drive like a drunk moron when he’s 3 places back or only when he’s in front of you?That brings me to another point… rubber banding. The Search For Equality… Rubber banding is one of the most misunderstood aspects of Double Dash – and probably many other games that utilize this technique. Really, it is also a point that blurs the lines between AI, simulation modeling and the basic game design decisions. There is a staggering amount of this going on in DD.First there is the speed of the cars. In general, when you start a new “Cup” (group of races) and the game “picks teams”, the AI will also assign a general skill level for each car. Throughout that cup, the running order will generally be the same give or take a couple of places. The same 2 cars will generally be in the top 3 and the same two cars will generally be in the back of the pack. This is obvious after having finished a 16-race cup and having one car have a single-digit score – which is only possible if you are continually finishing either last or 7th. Also, if you are a trained professional like I am (I have to look into some form of Mario Kart accreditation or certificate), you will realize by about the 2nd lap of Luigi circuit which of the cars you will have to put up with for all 16 races. [misc. editorial rant: Damn big, fat Peety-head!]There seems to be three ways they go about stringing out the pack like this: 1) By simply using the published speed of the cars. The fast cars will tend to be toward the front, whereas the putt-putt-mobiles will be in the rear. That means that those first two cars you have to contend with as a good driver will be the big, fast cars. Labels: cheating, FSM, Mario Kart, Mario Kart DD, racing, rubber banding
|
![]() |
Looking for the GDC AI Roundtable notes and audio? Content ©2002-2008 by Intrinsic Algorithm L.L.C. |
|
|
|
||