Sunday, March 28, 2010

Groovy sound bytes

Another week wasted. No poop for me this time though, Nah, this weeks turn was for our little daughter. The doctor sais she has an ear infection (again), but so far the antibiotics aren't really working, and she has a serious ugly cough. As if she smoked cigars for 16 years. Problem is that she can't really tell what's going on yet. One hour she is happily destroying the house as usual, 10 minutes later she sits there as a zombie, throwing up on daddy's new shirt.

So, I spend a few days at home. And while she was asleep I still got a chance to research a few things. Maybe one of the reasons many game-programmers are always focusing on the visuals is because they are, well, pressentable. If you want to impress or motivate yourself, create some new shaders or 3D maps and capture a screenshot. However, many game aspects are invisible techniques. Enemy AI, path-finding algorithms, entity structures, editors, scripting, and how about sound?

So, this week I can't really show you something again. But I found quite interesting stuff about sound. So far, sound was just a matter of playing .WAV files or streaming some music. Later on OpenAL added 3D sound to my engine, including some cool reverb ("EAX") effects like firing a shotgun in a sewerpipe or underwater. But there is more than that. Managing the many sound resources in the limited memory is a challenge. And how about 'true' 3D sound? Did you ever notice the noise dims when you close a door?

As you may have noticed, most parts of the game will be indoor. Meaning there will be a lot of occlusion by walls, doors, and thick ceilings. Basic 3D roll-off calculations like OpenAL offer are not enough to get a realistic soundbyte. It matters a whole lot if you shout in the open-air or inside a closed complex. Not only for you as a listener; also enemies who use their ears to detect threats.

I'm pretty sure OpenAL can be tweaked to do this kind of stuff, but I also had a look at FMOD this week, another Sound API used in commercial games, including Crysis. Commercial usage requires a license, but you can still download the full thing, including a handy tool called "Designer". So far I always had to create my own editor for defining sounds, properties, channels and so on. Possibly that was a waste of time, because Designer offers a nice toolset and testing environment to create a sound library.

Besides that, FMOD has functions to setup a 3D world-mesh to do the occlusion I discussed earlier. Too bad it doesn't have functions to test if AI enemies can hear you as well at a certain position, so I still have to figure something out. We don't want the enemies to cheat by hearing your squeezy farts through a 6 meter concrete wall of course. But nevertheless, I'm impressed by FMOD. In fact, I'm creating a wrapper DLL right now. Time to finish, I hear cigar coughs...

Sunday, March 21, 2010

Annoying

Not much productivity again this week. I thought my toilet adventures were over, but the shit still hits the fan, literally! And after almost exploding a few times last week, another parasite infected me: "Vista Security Tool 2010". Spend the whole damn weekend fixing my laptop. I hope the creator of that thing gets a real Ebola virus for wasting my, oops, F#ck!ing time.

I didn't had any viruses last ~9 years (neeeeeever visited any dirty sites, I pizza-promise), but all of a sudden a typical Windows Vista screen was popping up and showing several severe virusses. Thanks for reporting, now fix it will you? "In order to protect your computer, you must purchase Windows Security Tool". Purchase? Fuck you. But the virus warnings kept coming, and that annoying "Security Tool" kept prompting me to buy it. I got suspicious. Microsoft certainly knows how to earn money, but not this way. Of course, my other guards were playing poker and didn't notice anything. Anti-Vir couldn't detect any virus, Ad-Aware didn't even start. Thanks for nothing.

Turned out that the virus warnings are fake, BUT that "Vista Security Tool" itself is a very real threat. CPU was busy 100% all the time, continous (fake) warnings, no internet access, and even a few blue screens. Extremely annoying. I managed to download Spyhunter and Spyware Docter. But of course, these assholes also first detect and then ask money before you can fix anything. Finally a potion of Spybot free), Anti-Malware, and CrapCleaner(what a coincidence) seemed to kill the threat. If you are pulling your hair out for the same symptoms, check this out:
http://www.malwarehelp.org/win-7-security-removal-2010.html



I can't leave you with empty hands again, so I did manage to produce some pretty nice
screenshost this week, if I may see so. I moved to another test apartment with a better view on my Soviet style city. The textures are stolen from Halflife2, but I think it's a pretty good job for someone who is A: not a modeller or architect. B: not a texture artist. C: has diarrhea.

Programming progress is hidden in the small details. The roof antenna's and foliage on the balcony are transparent surfaces with double-sided lighting and can also cast shadows and scatter the lightrays now. Whoopie.

Sunday, March 14, 2010

Blueprints

Hmm, nothing fancy to report this week. I spend most of my precious time on the toilet this week. Too much jalapeenos or something. And fixed a few software bugs that were at least as annoying as my endless sanitary visit. Just one of those weeks where nothing works well.

I did some stuff on paper though; map design. At some point you need to proceed and create some actual game-content, or at least a prototype of it. Making a single good looking, isolated test-map is pretty easy. But how the hell to create a complete world that should cover hours of solid gameplay? Games are for little kids, bla bla, but the design process is at least as complicated as writing a book or moviescript. Not only the technical part. Choosing fascinating scenes (filmset), making up a game idea that is enjoyable (plot/genre), writing a smart story (script), using cool characters (actors), supportive graphics, sound and music, and so on.

That's why most games (and movies) copy proven concepts from each other. For example, it turned out that 2 hands in front of a camera, a shotgun, and a bunch of demons or chattering soldiers is a guarantee for success. But what if you're trying something new? Not that every single piece I had in mind has never been done before, but there is not much reference when it comes to some of the key gameplay elements, and neither for the environment. When making a map, you deal with lots of factors at the same time. Especially when doing an adventure/puzzle game like Zelda, Metroid or Resident Evil (earlier versions). To give you an idea:

- Not too small, not too big
When I buy a game, I'd like to be entertained for ~12 hours, AT LEAST. Games tend to get shorter and easier though. Developers get lazy, and/or games are targetted for the "casual gamer" (bleh) instead of hardcore Japanese who can finish Super Metroid within 20 minutes while doing a sushi contest. But yet another reason, making high quality content has become a lot harder. 30 years ago a hobbyist could draw Pac-Man out of 6 pixels on a sunday evening. These days each model, map, sound effect or texture is a piece of art on its own.

In some cases the player needs to feel attached to the maps as well. To give you that "honey, I'm home" feeling (Zelda villages). Or in case of a horror game, to provide the player with (false) knowledge of the environment. Fear often lies in the knowledge something bad may happen, rather than the graphic scenes them selves. However, the bigger the maps, the less knowledge the player has about the individual locations. Bigger is not always better.

- Let the maps Serve your type of gameplay
When making an action shooter, you need obstacles, objects to take cover, and eventually multiple routes to assault the enemy. When making Super Mario, you need platforms, pits and plumbing pipes. A race game requires a curvy circuit. If you don't, the gameplay will fail, completely.

- Serve the story / set the athmosphere
When the story plays an important role, the maps will need to support that as well of course. Resident Evil cannot do without the scary underground labs. And what would Star Wars be without the wild variation of planets?

- Please the eye
As you may have noticed, this game will take place in a skyscraper. But making 100 levels made of appartments, elevators and corridors is... boring. Make sure there is enough variation and "wows!" to drag the player through the game. Screenshots of dusty corridors alone won't attract anyone.

- Respect the theme
At the same time, stay close enough with the main theme. You don't want Star Destroyers in cowboy games. Silent Hill is scary, Metroid is a lonely sci-fi adventure, Zelda feels like a fairy tail, WO II: "Battle of the Bulge" is about... WO II, Battle of the Bulge. And guess what "Need for Speed is all about". Mixing up just any idea you may have is not going to work. Keep consistent. Sounds logical, but at the design phase you often get biased on ideas that may not really fit in the story.

- Horrific
As for our horror theme, well, it needs to keep you feel unpleasant all the time. Resident Evil 5 is a fun game, but I won't call it horror anymore. Zombies on motorcycles with rocket launchers? Come on. And how many scary movies have there been made the last 10 years anyway? In fact there were 2 or 3 "Scary Movies", but let's forget those quickly. Making someone feel truly scared is maybe even more difficult than making someone cry or laugh his pants off. The game maps needs to build constant tension. But one wrong decision can break this feeling. Just making a bloody stinky map doesn't work for long either. Humans quickly adapt to the situation you know.

- Make it smart
Just like in Metroid or Zelda, this game has puzzle elements and backtracing. Find a grapple beam on one side of the world, use it on the other side. The placement of items, locked doors and hidden sections must be done with great care. In some games the puzzles or secret sections are too obvious, resulting in an easy, not challenging game. At the same time, make sure backtracing doesn't get annoying. Make sure the already visited area's will keep surprising by introducing new stuff or allowing you to use your new abilities / items each time you return.

- Spread the butter
When drawing your first map, be carefull not to put all the cream here already, or you will run out of ammo soon. People don't like movies that start spectacular and then fall back long-winded. Create a couple of climaxes and let the game/maps bring you there smoothly.


Well, imagine to keep all those factors in mind at the same time, then draw a map... Good luck! Allright, another long post finished. I didn't have new graphical content, so here's a screenshot from my earlier engine. The shot is more than 3 years old, but still a nice one.

Saturday, March 6, 2010

From dusk till dawn

Everyone has his memories. Christmas, first girlfriend, being drunk and puking pizza's over a car for the first time. Happy joy joy. As for game memoires, Zelda: Occarina of Time (N64) was one of those milestones. It's not my favourite of all Zelda's, but it sure brought loads of beautiness at that time. Asides from the usual Zelda magic and the fact it was the first 3D release, being able to walk free in a "big" open world was epic. This is what 3D was supposed to be. Not only freedom on the XYZ axis, but also freedom in the things you do. This was one of the first games that didn't push you through. You could take a break and enjoy the sight at the Lon Lon Farm with a bottle of milk.

One of the effects that made my mouth fall open was the day / night cycle. Those days I didn't had internet articles spoiling all game details before even buying it, so it was a big surprise when the sun suddenly arised after my first night stroll on the Hyrule fields. I didn't believe my eyes... Did this game had a realtime clock? Yes, and not only that, the environment was dynamic. It could also start raining or thunderstorming at a random moment. People would go in and lights inside houses went on at night. I spent lots of time just visiting the villages at different settings to check how it would look and feel.

Damn, I really whish I could experience such a "Wow!" feeling again. These days games do not really surprise anymore. Not even the almost photorealistic sunrises at the beach in Crysis. Been there, done that. I'd like to see it again in Virtual Reality maybe, but I guess that still takes a while.

Yet, day/night cycles or dynamic weather aren't used that much. Of course, GTA and Zelda have them. The Sims a little bit, although somewhat poorly done (buy expansion pack #1234). Crysis can do it, but does not have the clock running by default. There are two reasons I can think of why not doing it. A:) Not needed / desired. If you want a night mission, it shouldn't go daytime after 5 minutes. B:) Technically not possible... due static ambient lighting / lightMaps. Graphics fine-tuned on a single setting.

Like discussed in an earlier post, having dynamic light is not so easy. Outdoor area's such as the Crysis jungles or GTA cities have somewhat predictable lighting(sun, duh). Indoor scenes on the other hand often have a more complex setting that is difficult to compute. Rendering the sky and clouds is difficult enough already, but doing the lighting properly might be even more of a challenge. Still, I think a day / night cycle can add value in my game. In fact, you're looking at it on these shots. There are no clouds yet, but the sky changes, stars fade in, overall contrast/brightness is adjusted, fog changes and a light-scatter effect is applied on the sun. Too bad the view outside is dull with those 2 ugly buildings. But imagine what you can do with forests or a city skyline...

It's not only about the visuals though. Watching the clock will be an important aspect in this game... And since 90% of the horror games/movies are always at night, this might give some variation. One of the reasons that makes me curious about Alan Wake. And the only somewhat scary scenes of Resident Evil 4 were at daytime, just because it gave an eerie surrueal feeling. In other words, this game won't be dark with thunders on the background all the time.

Sunday, February 28, 2010

Shady techniques

Post arrives a little bit late this week. Yesterday we had a party in Highstreet, a club in Belgium. It has been ages we went there. Last time "Push me, satisfact me" was on the radio, I didn't had a daughter or girlfriend, and the average videocards didn't had pixelshaders yet. That must have been 140 years B.C. or something. Let's do some history.

Lightmaps
I was already trying to make a game those days though. MD2 morphing animations, terrain rendering, and fixed lightmaps. Wait a minute, I did attempt to make a dynamic light with shadowMapping back then, but it was way too blocky for practical usage. Like most other games, lightMapping was the way to roll. Quake 1 was one of the games that made first use of it. Calculating realtime lighting for multiple sources was way too heavy those days, so instead game maps ussually had their lighting pre-calculated by "baking" an image with all light information. This image(lightMap) was typically made while creating the maps and it could take hours to calculate such an image. The shot below was from my previous engine, using "radiosity normalMapping" (fancy way to do lightMapping). The light spots on the ground and shady walls were all calculated and baked into an image in the map building phase.

LightMaps did service for many years. Quake 1/2/3, Halflife 1/2, Goldeneye, just a few examples. And it is still used. For a good reason, because once the image is created, it is a very simple and high-performance way to do quality lighting, including indirect lighting (ambient / global illumination / radiosity). In fact, most games still cannot do without because calculating ambient light at realtime is still extremely difficult, if not impossible for some scenario's... although CryEngine 3.0 may bring a revolution in ambi lighting soon...

Ignoring the indirect light portion is not a good idea either. The pitch black shaded regions in Doom 3 received many criticism. Its graphical competitor Halflife 2 looked more natural. However, Doom3 still had an important role when it comes to graphics evolution: realtime lighting with correct shadows. Halflife 2 may had the realistic renders, it still used the ancient lightMapping method, bringing some serious limitations with it. Popular bumpMapping shaders do not apply very well on a lightMap since this image only contains colors (light that falls onto that pixel), but not info about where it came from (direction vectors). Valve did a smart trick with their "radiosity normalMapping", but in the end it's still an approximation, not true correct lighting.

But more important, LightMaps are static. That means they won't change when you move a light. A day/night cycle, shooting lights, or using light switches is not possible with lightMaps. You have to recalculate the map whenever something changes. That is not so difficult, if it wasn't it takes seconds, minutes or even hours to do so. Updating lightMaps realtime = too slow. Unless you do low quality lightMapping maybe. I tried that, with success, but it's quality is way too low for accurate lighting. It can be used for dirty ambient lighting maybe, but not for direct lighting. Swinging your flashlight for example requires a spotlight with sharp shadows, but you can certainly not achieve that with low quality lightMaps.


Shadowmaps
Like I said earlier, ~eight years ago I tried dynamic shadows with shadowMapping already. This is a relative fast way to calculate shadows at realtime. Here's the idea: in the background, render your scenery from a light-point-of-view. Imagine you are a lamppost, put the camera in it, and render the street below you. Every pixel you'll see is litten by you. All others are shaded. We do not render colors, but the depth (distance between light and pixel) into a target texture. This depth image can now be used for lighting. When rendering your normal scene, check for each pixel if it was litten. Simple, if the distance between that pixel and the lightsource is equal or smaller than the projected depth image pixel on that location, it receives light.

This technique is called shadowmapping. Nowadays hardware is fast enough to generate multiple shadowmaps hundreds of times per second. And because images lend them selves for blurring, it is possible to create "soft edges". Another problem with Doom3 were the razorsharp shadow edges. In reality shadows are somewhat smoother due light scattering and stuff. Doom3 did stencil shading. Basically the CPU calculated silhouettes around each occluding object/surface and cut them out the buffer to prevent lighting behind them. ShadowMaps can be blurred more easily, and another advantage is the hardware acceleration. Instead of using the CPU, shadowMaps can be made entirely on the specialized graphics GPU. Well, no wonder that most engines are using shadowMaps these days, and so does mine. Here's a shot of my first test results, 3 years ago already. Notice there is no ambient lightig in the dark sections.


Cascaded Shadowmaps
~Eight years later, I still have that "blocky shadows" problem though. I'm not using lightMaps or fixed OpenGL lighting anymore, but shadows mapping techniques still tend to be "blocky" when distances between the lightsource and occluders grow. Makes sense, because stuff in the background receives less or none pixels in the depth image. This makes the shadows from objects far away from a light ugly or even invisible. Luckily there are always a bunch of smart guys who fix these things. Not me, I'm too dumb for all that mathemtical stuff. But at least I'm a persister, so after many Steve Irwin crocodile fights, I finally have "Cascaded Shadow Maps" working.

See that balcony railing shadow? Pretty sharp huh? It is casted by the sun, but the sun is pretty far away. With normal shadowMapping, this railing was probably invisible in the depth texture and therefore not casting any shadows at all. CSM is a technique to create multiple shadowMaps (see the 4 gray images at the bottom). The first one only covers a small section; the stuff you are looking at. The last image covers the entire scene. Now when shading, pixels pick the proper map based on their disances related to the camera. Neat, isn't it? Crysis and GTA IV used it as well to cast accurate shadows in dense (concrete) jungles. Allrighty, enough for this week.

Friday, February 19, 2010

Game concept document

Like Mick Jagger said, "you can't, always get, what you want". Programming can be very satisfying (for the ego) when conquering new techniques or reaching milestones. At other moments programming can leave you restless in bed with a displeased feeling. I was hoping to finish the skeleton animations this week, but I kept seeing artifacts, missing triangles, and broken legs as if Steven Seagal just went by. Luckily someone on gamedev helped me out a little bit. Did I already say how much I love www.gamedev.net?

I was also distracted by an article from the GPU Gems 3 book, "Light scattering as a post process". One of the effects I certainly want are light shafts. I know how to do it with shadowsmaps & quad slices, but this technique seemed way cheaper and easier to implement. But again, I wasn't pleased. It works, but only for background light such as the skybox & sun. As expected, it doesn't cast correct light shafts either, as the whole effect is just blurry streaks towards a lightpoint. I bet it looks cool when the sun shines through the foliage in a forest (Crysis had this effect), or when being underwater ("God rays"). But for a game that is mostly indoor, it's pretty useless. And not accurate enough to simualate the dusty lightshafts that fall through the apartment or corridor windows.

So, I achieved nothing concrete this week. Being grumpy already, the test-maps Í've seen thousands of times to try stuff like this also looked more ugly than usual. Depressing. I dried my tears and cheered myself up by implementing a cheap but effective motion blur (post processing) at the last moment. Not essential, but a nice addition to make the movement feel smoother anyway. And for a budget price. It still doesn't do motion blur on moving objects though, but that should be easy to add.

But hey! There is some good news as well. I'm making a "Game Concept Document", or whatever such paperwork is called. Anyway, it already contains more than 50 pages japping about gameplay elements, level design and the story. Nice to have such a thing if there ever comes someone with interest for the project. I'm quite excited about the story. The last year I made about six different stories, but each time it would feel "copied" or just not right after a while.

* Here's some advice: don't get blinded by your own enthusiasm. Write down the story. Then wait a few weeks to cool down. Let it read by a friend, and then judge again. Probably you're not that excited anymore. But if you're still in love... then you know you got it.

I would like to share my story, but even though I probably had zero visitors on this blog so far, I'm too keen on it. Every detail is a spoiler, and I don't want EA or others to rape it. Hard to prove this way, but I think it is quite unique. Most horror games contain the default ingredients:
- A lab experiment went terribly wrong, as always. Stupid researchers.
- The final boss is one cool/charming/wisely talking, bad motherfucker
- As a child you was abused / the mysterious youth syndrom.
- You was created by reverse biological engineering; you are your own grandma.
- All the enemies hate you, and want you horribly dead.
- The gates of hell (or dimension Xenoz 43) have been opened
- Open end... for sequel 2, 3, 4 and maybe 5,6,7 and 8.
But NONE of that! The whole game is a 'variant' on a well known existing story... You'll find out which one bit by bit. Things are not always what they seem, and who knows what is best for you? I'm sorry, but I won't give anymore hints.


At a particular day, the factory director said to his wife "Hey, let's make something!". "What my dear?", his wife asked. "I don't know. Maybe something with cars... or cigars. Just something!".

It's important to have a good story and game ideas as a back-up. It drives you into making concrete things, instead of keeping testing around with loose maps. I did a few hobby/amateur game (attempts) in a team in the past, but it would ussually get stuck in this phase. Everyone likes to add ideas, but in the end nothing gets done as nobody knows what to make exactly. Logical, you need a clear goal. So here it is, the holy grail of this project; the game concept document.

Saturday, February 13, 2010

Heads-Up for the Display

Hey, time for a weekly update. Carnival started, and probably 90% of the province Brabant/Limburg is already dressed up, drunk, and/or sharing the bed with the neighbour. But still no costume here. Coming up with a custume was ussually more fun than carnival itself. Last eight years we went as cheesepeople, grandpa's, Samual Jacksons, superheros (painted myself blue, weared "external underpants" like Batman always does, and called myself "Plutonium boy"). And previous year we went as a bunch of rockers.

But this year... Everyone is on vacation or busy, no brilliant ideas for costumes, and to be honest... Being packed together with 600 drunken idiots into a tiny bar with "hoempapa" music isn't exactly my cup of tea anymore. Maybe we'll do something tonight, maybe visit the carnival parade with my daughter tomorrow. Maybe I'm getting old and boring.


Maybe I was too busy with making that damn game anyway. Added all kinds of tiny things to make this game feel more like a... game. The monster in the maze finally tries to catch you, makes scary sounds borrowed from Doom3, and the earth trembles with every step he takes. When I tested it for the first time, it was quite impressive to hear and feel the heavy footsteps approaching while not seeing the enemy due the thick layer of fog.

The monster approaches me dangerously, quicker than I thought. With a button-bash mechanism I try to run as fast as I can, but then I suddenly bump onto a wall. Fuck, cornered! I turn around but its already too late; A big silhouette appears out the fog. A few more steps towards me... so I could stroke and give him a treat. Of course, nothing happens. My player doesn't have health yet, there is no GAME-OVER! screen. What an anti-climax. So, I added a simple health bar as well, and all kinds of crazy sounds fade in when the enemy approaches.


I'm not a big fan of extensive bars and meters. Come on, do you have a Head-Up-Display in front of your eyes that tell you how much cigarettes are left, how many percent there is left until you fall asleep? And how the hell does someone know how many bullets are left when firing a MG42 3.24 seconds?

On the other hand, HUD and bars can stimulate or encourage things. It's nice to see your stamina bar growing when your Magic Goblin buys a new potion. In Farcry I actually cared about coverage as I would peek continuously at the "stealth meter". In case of The Sims, the whole house would be full of shit, puke and starving Sims if there were no bladder/hunger/comfort bars.

At my work I learned to keep user-interfaces as simple and clear as possible. The driver doesn't care if there is 15%, 16% or 45% fuel left. He just wants to know when to refuel, so an indicator + beep is enough. Same thing for games. There are often many (invisible) factors that influence your stealth, speed, aiming or enemy resistance. But what use is it if the player is not even aware of it? Why bothering camouflage if the effect is nearly noticeable? In these cases, the HUD can be your friend.

For now, a simple health and "mental" indicator. No precise numbers though. If I would ask you how you feel, you won't answer with "64%" now do you? It's just "zuperb, fine, normal, not so good, or like shit".

Friday, February 5, 2010

a-MAZE-ing

Always trying to create good looking maps to test with. But as I'm not a very good modeller/mapper/texture artist, it takes ages and the end result still often dissapoints. That leaves me no time for developing other aspects of a game... such as gameplay.

So for a change, I created a big maze. An ugly simple map made of many corridors. To hide its uglyness, I used Maybelene mascara; a thick layer of fog. The fog does more than that though, it also hides a big threat in this claustrofobic world; a big, slow wandering creature. You can hear it, but you can't see it...

To be honest, that monster model has yet to be finished. Biggest challenge is writing a proper skeleton animation system + doing the skinning somehow. For now, a not-so-impressive, non-animated, Goldeneye look-a-like dummy soldier "ice skates" through the world. Making funny sounds (Halflife2 Combine chatter). But at least he finds its way in this mess. He's even kind enough to dodge me when I walk on his path, instead of rudely bumping me away. Meet mr."dummy":

Now I got to change this polite fellow into a monster.
- Proper pathfinding, picking logical points
- Realistic behavior when being unaware of you
- Scanning for threats
- Usings its ears
- Fuzzy logic when searching you without having a visual
- Predict your path in the maze
- Hurt you
- Being hurt
- Roarr! Moawn! Gorgle! Grrrr!
AI sucks in many games. Yes they might be 'smart' or tough, but I still feel an unfair balance. Either I can heal myself thousands of times in notime with neat medkits, and bulldozer over entire armies. Or vice-versa. Russians that pop me with a Makarov pistol while I'm lying in the bushes 500 meters away, monsters with ultrasonic hearing and X-ray eyes, and most annoying, Soldiers that happily continue their path just after being shot in the knee, head and balls.

This maze is a good playground for tuning AI. Make it difficult, but not unfair. The player must sense a learning curve, and use its skills. Not sheer luck, sixty medkits, or the auto-save. But most of all, let's see if this scenario can actually scare someone. I was making a horror game remember?

void TECH()
{
For the tech geeks, AI is done for most parts into Python scripts.
That means behavior is not fixed engine code. The engine just
sends events like "threat in sight", "path blocked", "second elapsed",
or "ouch, bullet in my head". The script does the rest. Except for
heavy duty tasks such as A* pathfinding, finding tactical spots or
updating the sensors (sight, hearing).
}
To finish this week, here a sneak preview of the maze-enemy. Although this won't be his final shape (look's too much like the Doom3 Hellknight). More next week!