![]() |
![]() |
![]() |
||
|
M. Noah Ward | Page 2 of 3
Play testing, often where the biggest programming problems are brought to light, has revealed that high end AI isn't designed to be as sophisticated as you think. Instead, it actually has to be very blunt and obvious for gamers to truly appreciate it. For instance, grunts in the game have a fear or anxiety meter that will affect their behavior. If they're moderately scared by the threat or firepower of you or your comrades, they'll run away, and if they're extremely petrified, they'll run towards their own friends and allies. One thing that raises this fear is the proximity of a threat to a grunt. If the threat gets closer, or if the distance between the threat and the grunt doesn't increase, the grunt becomes increasingly frightened. If you were to throw a sticky plasma grenade on a grunt, there's no way the grunt would be able to distance itself from the grenade and its fear meter would skyrocket, causing it to run towards its comrades and blow them all up in the process. Bungie's programmers set the aforementioned scenario to happen only 25% of the time, and play testers never even noticed. The programmers therefore increased the statistical odds of this behavior occurring, and only when raised to 100% of the time did even 30% of the play testers notice. This ultimately means for programmers a paradox: if players don't notice the AI, the AI essentially doesn't exist. Therefore, AI has to be very blunt and obvious, and not have much statistical probability, for gamers to appreciate it. Expect to see much of this ideology in Halo 2, and perhaps you might not have even noticed such an AI technique in Halo 1. When battling a squad of enemies, did you notice that by killing its leader, the rest of the squad would sometimes run away? Yes, that happens on purpose. ADDITIONAL PROGRAMMING SPEED BUMPS As for programming languages, Halo 1 was built in C, a procedural language, and getting the original team to write in object oriented C++ has proven a chore. While C++ is often much less refined than C, it's needed because it has the power to move the most amount of data through sheer brute force. Some may wonder why the sequel won't be programmed in Java, a much more refined object oriented language, but Perez dismissed this since it would be like trying to move the aforementioned massive data with a spoon instead of C++'s bulldozer approach.
Yet, interestingly, Bungie won't be going the route of Splinter Cell to accomplish its shadowing effects. The Ubi Soft title used "shadow buffering" for its in-game shadows, an unusual strategy of mapping lighted areas in a scene, rather than the shadowed portions. Bungie doesn't want to use this approach since their lighting system will be more dynamic and call for manipulation of shadowing caused by lights emanating from many directions. Bungie's answer to shadowing is a technique called "stencil shadowing." In this procedure, an in game model is rendered from the light source's perspective, and then this is used to create or "cast" a polygon with the same shape onto appropriate receptor surfaces. Or, in other words, this is actually casting a light volume that "falls" upon other polygons within view. This technique creates realistic lighting that even features perspective. Unfortunately, this procedure is taxing on system resources since multiple textures are being created on the fly, while multiple renders of the scene are being generated. Back to Page 1 | Proceed to Page 3
|
||||