Dumbass #2

Progress of the week: lens-flares

Models, charts, diagrams, ... If you went to school... and still remember some of it, you may also remember those stupid business diagrams. Flowcharts, state diagrams, functional Heinz Ketchup charts, the dr.Eukaneuba sequence model, or whatever they were called. Don’t get me wrong, *some* of those models actually are very useful. But I got the impression that each and every person wanted his moment of fame by introducing yet another model, made of some circles and blocks. Typically made by the “management layer” to simplify complex structures, making your work look easy. Or to talk a lot about something without actually doing something.

By dr.Ricky mcPoopy

Most of those models make sense more or less, but… really. The model above was made within 2 minutes by using some fantasy. They aren’t some miraculous cure to solve complex problems, and do we really need to learn hundreds of those at school? The purpose of such diagrams is to illustrate difficult stuff in an easy way so an outsider could say “Crap, now I understand!”. And probably to let the managers understand themselves what they are selling, as they usually don’t know or don’t care about the deeper technical details.

Nothing wrong with that, not everyone is a technician, nor has time to dive deep into the matter. But the main beef I have with those models is that there are too many, and moreover, they usually just can’t cover the whole thing. Either they are so simple and obvious that drawing them is a waste of time as an ape could have guessed that as well, or they are incomplete. The security system of a nuclear powerplant can’t be written down in a few circles on a whiteboard, because it’s too fucking complex! Too bad if you don’t understand it then, but that’s why there are experts in the world, let them do their jobs.


IT studies often come with these diagrams as well. But of course, the examples are always too easy. say, how to make a vending machine?


The Snack-Swindler 3000

Nice, but useless. Drawing that diagram costed me 5 precious minutes that could have been used to directly program the damn thing. And though it’s easy to understand, it’s incomplete. What if we ran out of Snickers? How about sending a text-message to the vending service when it needs a refill? What if some asshole threw wooden coins into it? By the way, this program hangs if you insert a coin but don’t finish the selection or ran out of money (and you don’t get change then, screw you).

Sure I understand that books will use simple examples just to illustrate how it can be done. But then try to make the same model for a more advanced application. For example, how a harvesting machine with 200+ IO and 30 different functions should work. Nope, that wouldn’t fit on a single A3 paper, unless you just want to explain your customers that the machine can be switched on, off and drive. But you don’t need a paper for that.

Of course you can zoom in though. First make a simple overview diagram, then describe each of the sub-functions with another diagram, and eventual even deeper sub-diagrams. Now we get a more complete view. But… now it lost its simplicity. Sure the managers won't like that, non-technicians probably won’t read them, or they get lost in all the states, conditions and relations. Also, making those diagrams *correctly* is sometimes even harder than just programming it, and therefore takes a lot of extra time. And to ruin it completely, paperwork will always be outdated as soon as you start programming. Because in practice, things will always turn out different. No, I’m not a big fan of them.



Not only lamps, everything that shines (such as specular hightlights) can cause lensflares.


AI State Machines
But there are exceptions. If you work in a bigger team, or your product will be used by other technicians, you owe them proper documentation for a start. In that case the energy in (re)writing these diagrams may become a necessary evil. But what I really wanted to write about, are “State Machines” used for AI.

As explained in the first post, and a bit above here as well, AI is complex. Especially when trying to make it “imperfect” with fuzzy human logic. A common problem I ran into, is the AI trying to do two things at a time and getting confused, or not doing what you would like it to do. Not because of the computer having a free will, but because the conditions are getting strangled. Let’s make an example, coding a soldier. We start simple, he just stands and starts shooting at you when he sees you. So the code could look as follow:

If ( icansee( player ) ) then begin
....Shootbullets( @player, randomize a bit );
End;

It works. But now we get the brilliant idea to let the soldier run to a health-station in case his health drops below 50%:

If ( health < 50 ) then begin
....moveTo( nearbyHealthStation );
End else
If ( icansee( player ) ) then begin
....Shootbullets( @player, randomize a bit );
End;

It still works, but the soldier actually got easier to kill, as he turns his back to you when hurt him. Dumbass! We need to tweak some of the conditions before he starts walking. Like not just walking away as long as it sees the player.

If ( health < 50 ) and (NOT icansee( player ) ) then begin
....moveTo( nearbyHealthStation );
End else
If ( icansee( player ) ) then begin
....Shootbullets( @player, randomize a bit );
End;

Hmm… turns out soldiers never run to the healthstation in practice, or at least never reach it as the player keeps showing up and thus interrupting his journey. Besides, a soldier that immediately starts firing and only walks if he can’t see you doesn’t exactly act “human”. Maybe we should add some delays before the soldier starts firing or stops walking. And maybe it should be distance dependant. If the player is far away, it’s safer to walk to a health-station. Unless he is sniping. Unless the health-station is very nearby. Unless random(10) = 2. Unless…

You see, the conditions add up quickly. The code gets ugly, harder to debug, and at some point the soldier just doesn’t know what to do anymore because there is always some condition that blocks. Or the soldier acts nervously, changing his mind all the time and thus never actually completing a single task. I think in general it’s better to let an AI decide something and stick to his plan. But to prevent dumb actions, the decision should be a good one in the first place. Anyway, defining AI behavior is one of those situations that cries for some simplification. Well, check this out:

That's a State-Machine. Not quite as brilliant as the Mickey Mouse success model, but still usefull, and covering some AI fundamentals for pretty much any action game more or less. And because it’s so simple, it forces you to think and program simple to prevent scenario’s where Rambo keeps running while one leg was blown off by a landmine, Red Sonya picking up three machineguns at the same time, and Nick Nolte keep shouting after being killed 300 times. It doesn't tell quite yet how to make our "Soldier" from above act smarter, but starting with a clean way to code saves half the problems. Really. With a state-machine, each state basically defines the current behavior of your NPC, and the lines between them are possible transitions that have to be checked. If the conditions of a transition become true, the current state changes.


Let the battle begin
If you think about it, you will probably recognize the states described above in most action games. Make noise, and nearby guards that heard it, will react. But instead of directly shooting you, there should be some delay. “Fuzziness” would be to increase an awareness level, depending on how frequent and how loud our noises are. A single footstep shouldn’t make the alarm bells ring yet. Just a “huh?” from a guard. Firing a gun on the other hand makes the guards Alert. Once alerted, NPC’s will take action. They go towards the last heard sound position (with a random radius around it maybe to prevent exact magical tracking), pick binoculars, sound the alarm, call each other, arm their weapons, et cetera. As for Tower22, our monsters won’t radio Charlie Hotdog Echo base for howitzer support, but they will curiously check the area as well. Same thing in essence.

Alert isn’t the same as combat yet. The NPC knows there is a threat, but doesn’t know where (well, the computer of course knows, but don’t cheat!). But by moving into your position, chances get bigger they will detect you eventually, if you didn’t start shooting before already. To prevent all enemies dumbly coming around a corner to get shot, some scripting or hints can give a role to each NPC. “Scouts” will move to you, “Support” will back them up, “Guards” will move into a fixed fire position, and Spiderman will quickly swing to a roof.

Once a NPC saw you (or your buddies) good enough, the shit is on. Combat state will activate, and the careful Alert state will change into a faster, aggressive Combat state. NPC’s will shoot on sight, and also adjust their pathfinding tactics. Take short quick routes, from one covered spot to another. Then depending on their role, they will either stay on a distance, flank you, or engage as lunatics. Secundary needs such as reloading a weapon, retreating or healing can be done on special conditions.

Maybe not exactly what they teach you in the army, but it is an option.

The State Machine above is basically a sub-machine of the "Combat" state. Probably I missed some links (which is another problem with models, they quickly get a messy spaghetti), but it seems quite easy and fun to program AI this way. Too bad T22 monsters don't carry guns though, so this whole tactical plan can be thrown in the garbage bin :)

Dumbass #1

A scary amount of time and energy has always went to the graphical part of T22. And probably that counts for most other hobby or commercial games out there as well.... Only to found out your graphics are outdated a few months later again, when CryEngine 7 or UnrealEngine 6 billion releases. Kinda pathetic. And worse, you would almost forget about other elements in your game. Such as making a fun game.

So, between repainting the T22 corridors and programming other cosmetic features, it was time to pick up an old dusty AI modul. AI, what does that mean again? Oh yes, Artificial Intelligence. One of the 2013 targets is to play with monsters. Not scripted ones, but monsters that actually think, follow you, make (the right) decisions in a given context, and scare the player out of the damn building. And in case we don't have a cool looking animated monster by then, we just use our "Stickman":

isn't he awesome?

I have to admit that I'm not very familiar with making AI yet. Of course I've heard, read and played before with pathfinding, state machines, world awareness and fuzzy logic... and that's exactly what AI is to me; fuzzy.


Though AI might not be as large the graphical system, it's a tricky one. Not very strange if you realize how little we know about our own brains. You can walk to a Döner Kebab corner and buy a snack. But how come you know the route (or not)? What do you do to avoid getting killed in your little journey to that cafeteria? When and how late do you go? And for Döner sake, why?

Well you can fill in some answers here. Varying from simple scenarios, to utterly complicated ones. You know the route, cause you've heard about it and know the place globally. You can read signs, and smell roasted lamb + garlic sauce when approaching. You don't get killed cause you don't cross the roads if there are cars nearby. And you avoid dark alleys with man eating hobo’s. So for nothing special. But now it comes. It's 02:30 in the night, not a common time to score some food unless you're drunk-hungry. But in this case, you didn't get drunk or anything. Nah, your girl left you for the 12th time and she doesn’t answer the phone anymore. You can’t sleep so the only logical choice is to go out and eat Döner.


Bladibla. The good thing about games is that you don't need such complex scenarios usually (and otherwise you just script them), because the average game-foe doesn't live long enough to reach diner. Enemy soldier? Bang, bang, headshot, dead. Incoming monster crawling on the ceiling?! Rocket blast! Two arms, one leg and three eyeballs flying around. Just another day in game land, one of the most violent places in the virtual world.

Because of that rapid pace, human-like activities such as sleeping, eating, operating a device, or chatting with another NPC are fairly simple and often 100% scripted. That doesn't mean that acting like a human (or animal, or monster, or alien, or ...) isn't important. If all foes would just stand still waiting until you enter the scene, the AI would be predictable, and appear very "computerish". And boring. Shooting aliens that were taking a dump in Duke Nukem was more fun than stirring up the neighborhood filled with "statue" monsters, waiting on your appearance. Immersion has become crucial in games, so the general advice is to let each enemy do *something* when not fighting you. However, as I was trying to explain, because of the tempo and short lives, just a single scripted sequence per NPC is usually enough to let the player think something useful is happening in that military camp, factory, or city. Let them rest, tinker a car wheel, chat, walk circles, whatever.


One of the awesome surprises in Half life was the arrival of soldiers. A welcome variation on the dumber alien opponents. Compared to other games of that time, the soldiers appeared really smart and "human like". Not that they studied at Harvard, but their manouvres, (scripted) events and endless noisy "Bravo Zulu, Sector clear" radio chats made them appear "smart".


Instead of making a drama soap, most engines focus the AI on giving the player a hard time. That means shooting, chasing, hiding, seeking cover, and eventually doing teamwork (let a few guys give cover fire while another flanks you). This involves path-finding (= able to find you without getting stuck in a wall or drowning in a river), shooting and sensing you. These last two elements are kinda funny though. I'll explain.

Computers cheat. No matter how much Punkbuster software you install, your CPU enemies will always know your exact location, see you though a thick layer of foliage, and fire their guns 100% accurate 1 nanosecond after they saw you. It’s not their fault though. Computer foes were born in shared RAM memory, thus having telepathic powers, and are driven by a processor that doesn't make mistakes. Computers don’t doubt, it’s either yes or no. And it happens they decide very, VERY quickly.

But obviously, a game where the AI can find you in a maze and shoots immediately, isn't fun. Players must be given a fair chance, and experience a learning curve as they get better and better in exploiting AI weaknesses. Why else would you play a game?! So, it's up to the programmers to "dumb down" the enemies. In (shooter) games this is often done by reducing the enemy accuracy, delaying their ear & eye sensors, and/or just by giving the player a ridiculously long health bar so it will survive attacks. But this still makes the AI a bit, you know, inhuman. Instead of applying cheap tricks, AI programmers look more and more to replicate actual human behavior. They mask the 100% accurate (cheating) computer capabilities with a layer of clumsy, fuzzy, stupid human logic.

A computer enemy losing his gun and surrender, yeah right. As if the CPU gives a shit about his virtual life. Yet seeing this for the first time in (N64) Perfect Dark was another step closer to more realistic AI.


Humans think and handle way different than a computer. A computer uses exact numbers, coordinates and yes/no conditions. Humans on the other hand base their actions on experiences stored in your upper-harddisc. Hand in toaster = ouch! = not good. So don’t touch it. Hand in girlfriend = ... never mind. The brain is a blurry archive of audiovisual memoires. If we see or hear something, we connect it (megafast) with certain memories. This brings us in a mood, let us do things, warns us, pleases or annoys us, et cetera.

Doing this learning process in a game would be tedious though. Besides, your opponents usually don't get a chance to learn anyway. If they don't react "smart" right away, they'll be dead. So instead we give the AI a set of functions that apply on the game. Call it Instinct. Being able to find cover, to reload a gun, or to close in without running through the open field. Or, to kick back a ball in case of a Soccer game. Shooters are a classical example to explain AI as the opponents need tactics, but of course there are other types of games as well.


Graphics slowly getting a bit better in this corridor. Now put some AI in it...

About that, Tower22 monsters won't exactly be Power Rangers. They won't be dodging bullets since you won't be firing a lot (if at all), neither do they fire back. They don't operate in large teams, and from an ugly monster you can't expect genius behavior anyway. Well... what can they do then?! Uhm... walking. Maybe climbing or swimming. Sneak up on you. Use the environment against you (yes, that sounds interesting). Sleep. Eat (you).

Sounds easy. And yes, compared to shooters with soldiers, this game won't be on the cutting edge when it comes to AI. I admit. But that doesn't make the monster behavior less challenging though. They will "shine" in different ways. For one thing, T22 monsters actually do have a long live so using simple scripted animations just before you storm in a room, are a no-no here. They have act “useful” in the T22 world instead of just wandering around. And they have to do it in a freaky, spooky, scary way. And yep, that’s difficult. Maybe not in programming terms, but from an artistic horror perspective, it is a challenge. A monster that just walks and roars isn't scary. Merging all elements in a disturbing horrific whole is the key here, and also the AI behavior is part of that.


Enough fuzzy talk. In “Dumbass #2” I’ll explain a bit more about some technical AI aspects; State Machines. Now let's play chess and act smart.

Different than action games, but a very good AI showcase. By using "need meters", the AI would search and use objects to fulfill their highest priority needs... such as blocking the way for firemen.