Sunday, July 21, 2013

Picker a number

More than once, I receive questions like "what is the max polycount for this new monster model?", or "what should the texture resolution be?". Not that I'm an art director, but since we lack one, I'll usually take the role to give such advise. And of course, I (should) know the technical specs to answers questions like these.


Artists need reference materials, style guidelines, and also technical boundaries. The ultra-detailed meshes that roll out programs such as ZBrush are usually not useable in a game, because they carry way too many polygons. For the non-technicians; an average (high polygon) ZBrush character can easily contain a few hundred thousand to a few million polygons. An in-game version of the same dude is usually somewhere between thousand to ten thousand polygons. In other words, the detail has to be reduced with a factor 10 to 100.

It's not that a (modern) computer can't render a 100k model, but the games I know usually show a bit more than just one character. Maybe the game has to render a whole army of the same characters, besides drawing the environment, doing some special FX, calculating physics, playing audio and figuring out what is going on in the heads of those characters (AI).

Same thing for textures. When drawing, its common to start on a big canvas. Not only does this allow more detail, it also just works easier. But, a single 4096 x 4096 texture can eat up to 64 MB. Even though hardware increases its memory every generation, you would only be able to pump a few of those into your videocard. Can't make a game that only uses 15 different textures of course.



Luckily we have a "stretch" function in pretty much any painting program, and there are also plenty of tools to reduce a million-poly model to a low(game) poly mesh that still looks close to its original (in combination with a normalMap to compensate the lack of smaller details). Nothing new so far. But, how to answer these "how much polygon?" questions? What are the magical quantities for this concoction?

Well, very hard to say really. First of all, I can't easily look into a GPU chip and see the desired throughput. There is no exact upper limit of polygons that are allowed. In theory, each extra polygon reduces the speed a tiny bit, but in practice the performance is a result of many, many factors. What else is going on? Do you have 1 giga model, or thousands of tiny models? How smart does the engine batch & render things? What are the bottlenecks? What can the hardware do? If you either have super-hardware, or the game doesn't do a whole lot, you can go berserk on the models or textures. If you need a lot of everything on the other hand, you need to balance things carefully.

To make things worse (or actually this is a good thing), the hardware changes all the time. A 2.000 triangle puppet would be heavy shit in the Quake1 days, now the GPU eats it for breakfast. It's like answering how much calories should you eat over the next few years. If we spend our days in the couch watching baseball, we probably don't need that extra pizza slice. If we get a heart attack after too many pizza slices and start playing baseball instead of watching it, the extra calories may eventually be needed to fuel our sports-bodies. A stupid comparison maybe, but the saying “enough is as good as a feast” is true in both cases. Take what you need, but don't overdo it. Or you'll get fat and slow.


Ok... that's some vague useless advice so far, let's see if we can transform it into some more useful guidelines for both artists and programmers. Here ten hints.

Quite some triangles were spend on this badboy. No, we won't show you the whole character, but let's say he might play a little role in a next demo movie...

1>> You can always downscale
First, and maybe most important, don't care about specs to begin with. At least not during the production of your initial model or texture. Downsizing a model or texture afterwards is easy. Upsizing on the other hand leads to quality loss, or is simply impossible.

As an art director, you should worry more about providing structure and space to process all this data. Preferably, the original "master file" should be on a shared location. Use a cloud, Dropbox or something similar to store the files. Everyone (privileged) can make a copy or review it, and if the artist computer crashes (which happens suspiciously often...), you always have a back-up.

Warning though, usually the Master files are insane big, so a free (2-gig) Dropbox account will be full before you know it. As a screwy Dutchman, I didn't pay for an unlimited account either so far, but you'll be needing it sooner or later.


2>> Don't overdo
“Drink with moderation”. As with drinking beer, eating hamburgers, smoking pot, or whatever you do, enjoy but don't take more than needed...(writing this, still recovering from my hang-over…). This is a golden rule for pretty much everything in life, including for making textures and 3D models.

If you are an artist, you want to show awesome stuff, your skills, and surpass yourself each time. That is a good attitude, but know when to stop. First of all, you can either perfect a few pixels/polygons, or make two assets in the same time. Being a perfectionist costs a lot of time, and often you don't have that time when making a game that will consists then-thousands of assets.

Second, you, or your reviewer, will always find small flaws. But will the end-user really notice it? Did you complain about the pixels in the Wolfenstein Nazi's back in 1991? Are the fake reflections in Crysis2 killing the vibe? Did you know that plenty of lights in games don't actually cast shadows? Are the non-perfectly-round shapes in 3D games a pain in the ass? The average gamer doesn't care or notice. Just as long the whole composition of things looks good.

The problem is, when the artist sends a near-finished object, say a chair object, the reviewer will be 100% focused on that single chair. The lack of fart-marks in the seat will make it unrealistic, the pegs aren't nicely rounded, the texture is a bit blurry at the bottom side, its 4 cm taller than a normal chair, and so on. I know this, because I'm a nitpicker as well. But maybe, and this is a lesson to learn for me as well, it's better to first finish a whole room and see how everything works out when being combined together.

If you look at a Rembrandt painting from a distance, you see one whole. A theme, a scene, a mood, a certain color palette. If the theme grabs you and the composition is good, the painting is a success. If you look closer you might notice Rembrandt was too lazy to paint the fucking vase in the background properly, but that doesn't matter. So artist, zoom out, lay back, put your object in an existing scene, and see if it does its job. Eventually downsize the texture, or use less polygons and check again. If you didn't saw a real difference, your asset is still good to go.


>> 3 The illusionist
In addition to 5, sometimes simple tricks can do the job as well. Even though it might feel cheap, dirty, wrong, and old fashioned, simple 2D sprites or decals are still used a lot. An old industrial corridor needs details such as wires, switches, cables, cracks, dirt, broken tiles, oil smear, and so on. Modeling all those things takes more time, costs more performance, and sometimes doesn’t even look better. A flat decal can look more detailed than a low poly object.

When to exactly use decals or sprites then? I usually use them for small stuff, or things you would only watch from a distance, so you can’t really walk around it, breaking the illusion. Faking stuff also goes for a lot of special effects. Realtime G.I., real 3D particle clouds, or volumetric dust sure are cool, but also terribly expensive. Often they can be replaced with a much cheaper variant, and in some cases those even look better as well, as it can be very tricky to implement the realtime counterparts correctly. Pre baked lightMaps versus realtime G.I. is a perfect example.

No matter how advanced your particle engine is, the 2D flame is still unbeatable. Though I have to implement XZ rotation to keep facing the camera, the left flame starts showing its fakeness.


4>> Stress! test!
If you can, just fill a room with heavy models and see what happens. I used to remove triangles with a microscope & tweezers. But in practice, high polycounts aren't the bottleneck usually. At least not in my case. The number of assets, whether those are small or big objects, matters though. Videocards love to batch things, so rather than nitpicking about a few polygons, you'd better ensure the (engine)code to sort, group and batch things as good as possible. Especially when you have to deal with dense stuff, like a jungle. Or garbage mountains.

On lower-end hardware, the polycounts may become a bottleneck much sooner. So yet again, stress-test if possible. Just to see where your limits are (and to test code improvements / changes). It avoids getting stuck with impossible scene concepts, or having false fears for high polycounts on the other hand.


5>> Guess the texture memory usage
If you worry about texture sizes, calculating the memory usage for a single texture is quite easy:
KB = ( pixelsWidth x pixelsHeight x channelCount ) / 1024
MB = KB / 1024
Textures are usually in the RGB8 or RGBA8 format, which means you multiply the width and height with 3 or 4. Thus a 1024 x 1024 x RGBA texture takes 4 megabyte. That doesn't sound like much, assuming a modern card has at least 1 gig video memory. BUT! There are some catches:
* Textures are often mipmapped, increases the size with 33%
* Textures often come as a set (diffuse + normalMap + height + specular + whatever)
This easily doubles or triples the requirements

* Your program loads more than just textures into the video card memory.
Buffers to draw on (FBO's), 3D models (VBO's), shaders, et cetera.

* Windows and other programs want a bit of the honeypot as well.
Let's just say ~15% of the available memory isn't for you
In other words, if you have 1 gig of memory, it doesn't mean you supply your scene with 1 gig of texture data (simultaneously). Last but not least, there is also a thing called "bandwidth". If you render a room that is made of 128 MB data in total - for example some geometry + ~21 1024x1024 RGBA texturesets (diffuse & normalMap) - it means that your videocard has to squish 128 MB of data through its hydraulic hoses each time you render. Difficult to tell what the exact maximum is, as it varies for each card and probably the GPU also caches stuff, but there is a limit somewhere. Just as long you don't hit this ceiling (meaning some other factors are limiting your performance), there is nothing to worry about really. Just don't overdo things to stay away from the critical limits, see 5.


6>> Texture Compression / LODs
Use DDS textures & compression(DXT, ...) to reduce the texture sizes to ~1/4. This allows to load a lot more textures into your memory, and/or to reduce memory requirements/bandwidth. Careful though, compression doesn't always turn out good for every texture. Especially normalMaps can look "crunchy". Check your results.

When rendering very complex models, or just a lot of models in big (outdoor) scenes, you can save bandwidth and triangles as well by switching to lower polygon versions of your models and (background) environments. You can sure render a monster with 20.000 triangles from nearby, but when stepping some meters away you can half the polycount without really noticing it. And forest trees might even do a good job with flat billboard sprites when being rendered from a distance (that’s how Farcry did it for example).


>> 7 Batch & combine
Rendering the same palmtree hundred times might go faster than rendering fifty different palmtrees, even though the polycount could be the same. This is because you’ll have to interrupt the videocard each time, telling to switch tasks. Use grouping, sorting and tricks like instancing to avoid this as much as possible.

As an artist, you can help as well. Make asset sets that can be re-used. Sounds obvious, but sometimes objects are so “showy” that you shouldn’t place too much of them. Another trick is to combine as much as possible in one model, and/or let the subparts share the same texture. Rendering a house as one big object with one texture(set) will go faster than constructing the house of many sub assets. Of course, this might give problems with things like texture quality, different required shaders, or destructibility though. Stay in contact with the technicians or map designers to find out what works best.


8>> Make performance options
T22 has some graphical options that aren't too hard to implement. When using DDS texture files with mipmaps for example, you can easily create a "Texture Quality" setting. When choosing a lower setting, the highest resolution mip-map level(s) aren't loaded, which can save a big amount of memory / bandwidth.

Special effects such as SSAO, shadows, screen-space reflections or realtime GI can be switched on/off, though this is tricky. When tuning the graphics, the lighting matters a lot. When I disable SSAO and use another type of cheaper GI, the scene just looks different. So instead of switching things on/off, I usually give them a quality setting as well. Lower quality usually means that the effect is rendered on smaller buffers, reducing framerate issues.

You could also decrease particle cloud densities, or make IFDEFs in your shader code to skip some parts, or to use less samples for effects such as blurring or raymarching. But as said, don't get lost in too many settings. While developing you should try to render the scene "representative". If it looks completely different on another computer, it gets very difficult for the artists to make a good looking scene.


9>> Bottlenecks & Profilers
If the framerate stinks, then one or more factors have become a bottleneck. If you render very simple scenery but use gigantic textures, bandwidth could be the problem. If you are rendering dozens of layers of transparent particles on top of each other, the fillrate might be killing. Just to name a few examples. Unfortunately, it’s not always so easy to tell why things are slow. In that case you can try using a profiler, that tests shader execution, what is being loaded onto your card, what API (OpenGL / DirectX) calls are done, et cetera. If you are using OpenGL like me, gDEBugger for example might be useful. AMD and nVidia also have tools, though I didn't successfully implement those in combination with OpenGL & good old Delphi.


10>> When will the game release?
Tomorrow? Next year? .... "When it’s done"? Unless your game is small or you have a clear deadline, chances are big that you still have year(s). Ifso, don't panic if the framerate is a bit low on your current computer. In fact, T22 runs like sirup with lard on my 4 year old laptop. But when running it an another modern computer, it goes surprisingly smooth again.

That doesn't mean you can ignore the performance. If the speed suddenly drops seriously after implementing some new effect, make sure you're not doing something wrong. But then again, be careful not to waste many precious hours on increasing the performance with tiny bits. Chances are that the efforts are negligible one year later, and optimization often leads to bug-sensitive, ugly code. Make a solid basis, but spare the tuning for the final stages, when knowing the actual target hardware.

Coming to think of it, I just remember playing leaked Doom3 and Halflife2 versions. And well, they performed terrible even though their maps, shaders & effects weren’t even finished. Just saying.



Well ladies and gentleman, what fun we had again. But it's time to go on a little vacation, so no posts this month anymore. After the vacation the pressure at work will hopefully drop a bit, which also gives more time to work on our next Demo movie. It has been way too long since we showed a new clip or an interesting screenshot, but we're working on it. Ciao!

Thursday, June 27, 2013

Working class zero

What's happening here? Lost your typing-thumb, Rick?

Yes, I know there aren't much updates lately, and that I'm recycling the same room screenshots over and over again (so, no screenshot this time). And if you have followed other "hobby" projects or Mods before, than your doctor instincts may tell that these are the typical symptoms of a slowly dying patient.

Does that mean...? Nah. Nelson Mandela might pass away (peace is with him), but this project isn't dead yet. It's running almost three years now, and I've been programming the engine for at least six years. You don't think I would suddenly stop now, do you? My girl has to ask for two years before I finally fix a plank or paint the shed. And if I say "I'll do that right away honey!", it can be translated into "What were you saying honey?!". I’m lazy. But, when it comes to programming my babies, I’m very determined.


No the reason that you read and see little here lately, is simply due the amount of work. Real work I mean, a job. It's always busy during the summers when the harvesting season starts (one of my jobs is making agricultural machines, for Ploeger), but usually I can find some free hours during the nights or weekends otherwise. Or fantasize a little at the office when it’s not too busy.

This time however, it’s insane. And if I say “insane”, it really is insane. I never complain about doing overwork, but let’s just say the working days don’t stop at six ó clock. Waking up and going to bed with work (and yes, I wake up early and go late to bed). Also in the weekends. Since I’ve been doing that for two months now, my mind is 200% focused on the job. So switching to another complex project such as Tower22 in the few free hours, is simply not doable right now. DJ Bootsy can’t mix Shania Twain with Sepultura either. The few free hours are to drink beer, or demolish a “new” old house a friend just bought. Or to see my daughter. Last time she fabricated full diapers, now she is almost five again, has tattoos, smokes cigarettes and comes home with other (5-year old) boy scum.


Tag-team
On top of the regular summer-work (= programming new features & helping our service guys & visiting (angry) farmers), new prototype machines have to be made. New design, new diesel engine, new cabin, new controls, new electrical lay-outs, new touchscreen, new controller modules, new graphics, new everything. And of course we didn't just plan a single prototype machine. Nope, two other machines are made by our partner companies (Oxbo & PMC) as well, and there is still another one planned a bit later. But besides just programming whatever needs to be programmed, these particular tasks brings a whole new challenge as well: working with other people!

Normally I program everything on solo (same for T22). Which is a lot of work, then again it gives you full control over the project, and you decide the tempo. When working with other people, you have to trust and rely on them. The obvious advantage of having multiple puppets working on the same thing, is that you can spread tasks and work in parallel... If you have a well oiled team at least. Luckily Tower22 gave me some experience when it comes to teamwork, though my partners here are artists instead of technicians... Artists might be more “lazy”, but technicians on the other hand are (far) more stubborn. So quite a lot time is spend on sharing documents, explaining new technologies and trying to convince them. And swallowing your own ego sometimes. Having them living on the other side of the planet, and never met some of them doesn’t help much either. Be patient and keep smiling!


All right, one screenshot then. Otherwise this post looks so boring. Diego has been drawing all kinds of decals lately. Switches, wires, cracks, stains, dirt, rotten leafs, more dirt... Oh and this environment still looks pretty clean for a horror game. Not everything needs to look like puke of course.

Always look at the bright side of work
Oh well, I’m sure things get better when we know each other a bit longer, and when we manage to finish the first machines as a team. It’s always satisfying to see the giant monsters in action as an end result. It’s just that there is a bit (too) much information, work, and new faces are coming on my plate from all directions. So that leaves no time for T22 now. I also have a second job as well, so the head simply is full. The problem with programming is that you can't just start for 30 minutes and leave it behind again. Well, you can, but putting unfinished code back on the shelf is bad mojo. Do it good / finish it, or don't start on it, that is my experience.

Anyway, fortunately, this whole situation is only temporarily. We’ll be back in action when the farm manure settled down. The other good news is that, even though they’re busy as well, some of the T22 team guys are working on an awesome monster as we speak. The mesh (by Julio) is pretty much done, and this time we have a rigger (Stephen Wong) and an animator (Antonio Yanez) to jolt it alive. No more shitty Milkshape animations from my hand! Also the environment for the next demo is almost done. And Robert made another monster we can play further with after the upcoming demo. The planned summer-release of this demo might not be realistic with all the summer-work, but hopefully we can surprise you this autumn.

And when we do that, I’ll push the demo towards a popular Dutch gaming magazine as well. The teamwork on both Tower22 and my job, learned me a valuable lesson: face-to-face. You can email, Twitter and Skype all you want, but in the end people are best instructed and motivated if you just work in the same physical place. Despite all the technology, some things will never change. So hopefully this demo + note in a games magazine can bring me in contact with Dutch artists that can come over here for a beer. No matter how late I go to bed, a better structured team is really necessary to get Tower22 done.


Another little plus of all this working, is that I earned some extras. So, let’s stimulate our lousy economy a bit by buying a Wacom Cintiq ! No, not the huge ones. Just a 12” (used) one to start with. I can’t draw for shit on my Intuos due the lack of practicing, so it would be a bit stupid to buy a professional (expensive!!) tablet and expect everything would suddenly change. If you hardly hit the road, you don’t buy a Ferrari either. Unless you have too much money… ah never mind. You get the point.

Monday, June 3, 2013

#!/Bash Linux

Time for a little brawl. Did the title say "Linux"? Oh, then you know you will get it.

Often when we read about Linux, either the author LOVES it, or HATES it. Nothing new, the majority that just "digs a product", doesn't bother writing an article in the first place. Although Linux is the kind of product that you can only either hate or love. If you fall somewhere in between, then you're not using Linux but Windows or Apple. Simple as that.

So do I. Not that I adore Windows (never tried Apple), but I have no reason to use Linux. And for my goals -programming T22 / work, playing a game, and watching internet porn- Windows just suits fine. Hence, a lot of the programs I would need don't even exists on Linux so I don't really have a choice, do I? And no, it's not the fault of big-bad-MS either that the majority of software developers only target Windows. On their turn, software developers just look at the target audience. And most of their audience uses Windows. Especially when talking about games or office related software. It's a vicious circle. And the reason why 99% of the office is using Windows is not entirely the result of Microsoft's evil Monopoly either. Linux just sucks for the office, and I'll explain why.

Offtopic. Framed one of the drawings Pablo made a while ago.


Unmasking the popular “Why Linux?!” reasons
-----------------------
First, before calling me an ignorant "Hat0r", I'm certainly not telling that X is better, or that Linux is an inferior product that should dissapear or change completely. Although I only half agree with some of the popular "Why Linux?!" spearpoints.

>> It's free!
True, and certainly a valid reason some years ago. But nowadays Windows isn't that expensive anymore. Besides, I work, and I don't mind paying someone if he/she delivers a good service. How about you, cheap bastard ? ;) No but seriously, we all love free stuff, but then again it's not evil to pay for a product. That's just how our world rolls. You don't work for free either, do you? Exactly.

>> Its Open Source!
So what. That doesn’t make a product automatically “good”. The idea of Open Source is that everyone can contribute free tools, and review & fix each other’s code. Of course, this is required to provide a free OS, and there is nothing wrong with this approach. But the majority of programmers isn’t extraordinary good. Not saying the Linux programmers are bad, in fact, I’m quite amazed that they manage to keep this product consistent, clean and stable so well being somewhat "unorganized". But just the label “Open Source” on itself doesn’t guarantee brilliant tools and the code to be bug-free.

On top, a programmer can write free / Open Source packages for MS, Mac, Google, Android or whatever platform as well. In conclusion, an Open Source OS isn’t worse or better than a non-Open Source OS. It all stands or falls with the qualities of the programmers and designers. And... commercial companies like MS, Apple or Google have the money to generate well documented standards and attract those few extraordinary good programmers.


>> Linux is 100 times safer than MS!
I bet it is. But here is a little statistics exercise. You live in a town with 10.000 people. 95% are Chinese, and have a vertical frontdoors. The other 5% are white and have a horizontal frontdoor. Crime statistics tell that 89% of the burglaries happen in Chinese homes. Now does that mean that Chinese homes with vertical doors are less safe?

Maybe. But since 95% of the homes belong to Chinese, the random chance is much bigger that a Chinese home is chosen for a burglary. As an extra, thieves know how to break these vertical doors, as they're very familiar with them, opposed to those weird horizontal doors. So, of course, in absolute numbers, Chinese homes become victim a lot more often. But when looking at the percentages, the whities homes are actually less safe, since 11% of the crimes happened in white homes while they only make 5% of the community.

Statistics is a bitch. Now I don't know about the actual hacker-virus-Windows/Linux statistics, but obviously a Windows computer is a much easier target. And last but not least, the average Linux user is likely more experienced with computers (thus defending his PC better) than the average Windows user. Because in general, only advanced users chose Linux. Many problems start with users opening their penis-enlargement mails, and that is something neither MS or Linux can prevent.


>>Linux can do X or Y just as well!
Yeah, but often the tools aren’t as user friendly or "complete" as their Mac or MS counterparts (though I often blame those for being bloated and too-much). Plus the number of people that use the Linux equivalents, is a lot lower. That’s not Linux's fault, but it still means that the amount of help, tutorials, teachers, books and other help comes in lower numbers as well. Not very handy if you are a newbie. Commercial companies have the power to promote and organize study materials for their products, where Open Source products have to rely on good will. The Linux community has proven to be very willing, but yet... As said in the first point, this world runs on cash.


It's an Unix system! she says. Thinking now, Linux actually could work in such a weird way.


And now some Real reasons why to use Linux
-----------------------
Enough sceptism. Now some things that make Linux good (as far as I know). First, let me tell a bit about my history with Linux. It’s short. Ten years ago I had to use it for some school assignments, and I hated it.

Ok, some nuance. I didn’t like most things we had to do at school anyway, so Linux wasn’t my favorite waste of time either. Plus the distro we used (forgot which one) was a lot more primitive than nowadays versions probably. But still, the other kids that liked Linux at school, either did a lot of (home)server related things, or just used it because they were nerds. Really. The type of kid that likes making jokes about Windows (starting the laugh-track), and staring at Tux (that penguin) the whole day, making them look intelligent.

Well, I know little about internet(security), routers and servers so I’m not going to argue about Linux strengths here. If it weren’t good, network operators wouldn’t be using it in such a large scale. Now my experience. Half year ago I had to start using Linux (via VM-ware that emulates it on Windows) again. For work. So whether I like it or not, shut up and work. Ubuntu is the name of the distro I’m using. No, don’t tell me Ubuntu sucks and distro X is better – I don’t care. My first impression of Ubuntu? Pretty nice! It was small, compact, looked pretty smooth, contained a file browser, and I could connect with internet without having to read spells from my Lord Voldemort magic book. Not a bad rendez vous.


Last years software design is focusing at easy big symbols again (see smartphones), rather than filling the screen with billions of functions, labels, and little buttons. Linux doesn’t look that way, but has been pretty clean and minimal by itself for all along. Which is a good thing. For newcomers, the less buttons and info, the less that can go wrong.

This minimalism doesn’t only resemble the looks. The Linux package itself can be made minimal too, making it very useful for devices that don’t have a 100 gig harddrive, six processors and an elephant of RAM memory. As you may have guessed, I have to program a machine (touch)screen for work, which runs on Ubuntu. Though Windows has Mobile variants as well, it seems that Linux is easy to strip. There are even tiny microcontrollers that can run it. This makes it ideal for embedded or lower-end devices.

This minimalism also reflects in the stability. Though Linux crashed horribly on me as well (unable to boot after a sudden computer shutdown), in general, it just seems to be less hanging, CPU hogging, memory eating and crashing than Windows. However, it’s not that Windows is crap. Windows simply has to support a wider variety of software, third party drivers and whatsoever. If I make a shit program for Linux, it will just crash as well. Nevertheless, Linux remains a more obvious choice if you need a 24/7 service. You don’t want your Server to crash, neither your machine hardware to hang. If a Boing 747 went down, the creators can’t come up with an excuse like “Sorry, but the Windows terminals also had to support the MineSweeper game and tons of other useless background stuff”. The less going on, the less chance on a crash.


Then why isn't average Joe using Linux?
-----------------------
Now to the point. As explained above, Linux has a set of good reasons to use. Stable, minimalistic, free, et cetera. But why is the majority still using Windows? Linux fans would like to state that MS has a monopoly position, brainwashed the market, and/or that Windows users are just stupid. Though there is some truth in that, Linux also has to look in the mirror and acknowledge its own flaws.

Though I’m a programmer, I have little patience and know-how with a lot of electronic devices. I only use 2% of my telephone functions, can’t program the VCR recorder, confuse the word "booting" with shoes, and generally don’t like spending more than 6 seconds to learn new software. Basically, I’m just as clumsy as most other common PC users. And since I often write software for that same audience, I know how to keep it as simple as possible. Office Betty doesn’t care how software truly works. She just wants a few simple buttons that do exactly what she expects. And Goddamn right she is.



Linux on the other hand forces the user to learn & type commands, and recognize wacky weird terminology. What the hell is a "Grub"? Some sort of evil forest gnome? Linux is stuffed with names like that. Short, ugly names. Grep, /etc, /opt, krt, brt, prt, Fuckt, whatever. The good thing is, if (IF) you are familiar with the environment, you can actually type paths and commands very quickly because of the short naming. But for newbies, Windows slang such as “c:\Program Files\AssholeSoft\“ makes much more sense.

Well, that's a matter of getting used to it maybe. But… I DON'T WANT TO TYPE in the first place!! If I need to install something in Linux, I got to open a terminal and do something like
.......# tar -xs shaggyballs.tar.gz -C /opt/mycrap
Oh, and though folder names are short, installation names are often much longer
.......# tar -xs shaggyballs-linux-core_1.0.4-mozillacheese 53~2.tar.gz -C /opt/mycrap
And to make it worse, Linux is case sensitive. In other words, you'll make a typo very easily. If you are afraid and new (like me) to Linux, you barely dare to hit "ENTER". Maybe I launch a North Korean rocket if accidentally writing the wrong command!

Classic example of someone who made a typo on a Linux station.


Now you can tell me "it’s your own fault, learn to type / follow tutorial-X". But no, no, NO! This is where Linux fails to become lovers with the bigger audience. I'm too dumb and lazy to train myself, and I have the right to be dumb and lazy. And so does any other user. Face it, at least 75% of the computer users doesn't know much about computers, neither wants to know. And this is exactly why a product like an iPhone becomes popular, and Linux not.

I probably belong to the other 25% that actually knows a bit about computers, but that still doesn't mean that I should train myself doing things that can be done 100 times easier. With a mouse, and a GUI you know. Ultra basic elements that transformed DOS computers into more user-friendly devices about twenty years ago. I bet it's cool to know a lot of Unix commands, and I've seen guys unpacking and installing things faster than I could do with a mouse and Install-Wizard. Yet I don't want to solve puzzles each time I need to copy a file or install something. Bottom line:
- I want to use my software - not my OS

That's right. Linux, Windows, Mac, I don't give a crap. Just as long "my stuff" can be done. Whether that is running Delphi, Qt, Paint Shop Pro, browsing internet, reading mail, writing a spreadsheet or doing a game. All the OS has to do, is making me able to start those things ASAP, and run them (stable!). That's why I’m not particularly interested in new Windows packages either. It doesn't really change my experience since 99% of the time, I'm staring at a Delphi screen instead of an awesome new app-based desktop.

BUT! Once we do need the OS to copy files, empty the trashcan, connect a new type of exotic hardware device, unzip stuff, or search a file, it needs to be as fast and easy as possible. Now, Linux can do all of that, and maybe even better and faster than Windows. But those darn terminal commands... it's like using DOS again. I'm not saying Linux should remove its terminal, commands and wacky names. Hey, if you like to work that way, you can grub-grep-sudo-ssh-ls-cd-tar-mount as much as you like. But if Linux wants to reach a wider audience, it should have visual tools as well. If I install something and find out it's a line-command tool, I generally delete it right away.

Their File Browser works nice, so why not using it for a lot more handlings? I’m sure there actually are a lot of (free) tools that can help me with this. But again, I have to find & install those first. You got to understand that most of the average users would have already given up by then. Hence the majority of users doesn’t even understand what a directory is, or how to find a file in Windows Explorer. Linux expects too much knowledge of its users.


If you wonder what the heck we've been doing last period. Well, making the walls uglier.

Conclusion
-----------------------
Well, my conclusion at least. Taste differs, let that be clear. In my opinion Linux has its strengths when it comes to being minimalistic, free, safe and stable compared to some others. It’s great weakness is it’s lacking user-friendliness. Some parts work smooth, other parts brings us back DOS trauma’s. And no, it’s not a matter of learning a bit. Most computer users don’t want to learn and if the Linux community fails to see that, Linux will never even come close to taking over the market. Call us dumb, but not being intuitive is just as dumb (at least if you want to gain popularity).

Then again, I wonder if Linux really should become an easy, widely used platform. Would the Wiz-Kids really like to see the entire office, school and mom working on Linux stations? Linux is like a small group of Gothic kids in class that don’t want to be identified with the rest. If everyone starts wearing black dresses, they’ll start wearing pink knickers. You won’t be a Linux Wiz-Kid anymore if everyone else knows how to use it as well. So maybe Linux should stay a bit difficult. I don’t find it “fun” to search 2 hours on how to create a startup-script, but I bet a lot of hobbyists actually enjoy this, making Linux a satisfying challenge. Linux offers you more control over your computer, but this contradicts what the average user want from an OS.

Moreover, if Linux would become a number one platform, then sure as hell the amount of viruses, leaks, cracks and open backdoors will increase as well, degrading Linux as a safe and stable system. Simply because hackers and other scum will target these devices much more, and a lot more of half-protected software or poorly written drivers will appear by third parties. Being Open Source doesn’t really help hiding leaks and weaknesses either, though the plus is that anyone can contribute to report or fix them of course. A bigger number of users, drivers and software will increase the number of problems and complaints as well. Certainly if the overall "computer skills" level of the users will degrade as well.


As for the popular sports of Windows / Mac / Linux / WhateverOS bashing each other on the internet fora; go ahead, have fun. But just remember you look silly if you are in blind love with one OS and fail to see the pro’s and con’s in a bigger picture. Like a ninja, one should master his tools. Don’t just use X because someone else sais so. If you can make awesome stuff using the Commodore 64, then the Commodore64 it is for you.

Now boys, this is how Linux (Ubuntu, minimal) really looks like. It doesn't work with snes-FX-chip 3D Jurassic Park cubes, it won't recognize speech or commands like "Computer, re-engage starwarp boosters now! >> Yes sir, boosters working at 98%". It looks like... a normal computer, though I still get a bad taste of the eerie "DOS" Terminal.

Friday, May 10, 2013

don't don't Don't believe the hype !

When I was a little fat boy, Doom(2) pointed out my destiny; I would make games. And become a programmer, otherwise you can’t make games. Doing animations or drawing graphics wasn’t all that important those days, and “3D modeling” was a word yet to be invented. At least in my little world.

It still took some years before I could actually start programming though. No PC, no idea, and not the brains to solve formula’s other than 8 + ? = 12. And without internet or able to read English either, becoming a game programmer was “far future” stuff. Besides, playing games and drawing “levels” together with friends was much more fun than even thinking about reading a book. That’s what they call a boys dream. And usually boys dreams don’t come true.

Well, my boys dream didn’t come true either so far. I became a programmer, but not in a game studio. I finished zero games myself. And honestly, I wouldn’t probably even like to work in some studio, doing game “X”. Because I want to realize my own ideas, not just pooping some code to realize someone else’s dream. How different than 18 years ago.

One of the few, if not the only, Doom4 "leaked" (concept)shots.... Well, after seeing complete cities getting destroyed dozens of times last 10 years, a shot like this doesn't produce much more than a "mehhh". Where are the cool mechanized demons?!


Forgotten glory
I’m not going to describe my whole boring programmer “career”, but I just came across this article (looking if there were some damn Doom4 screenshots already), about difficulties in the Doom 4 development process. 18 years ago I would have eaten blue mold cheese (and boy I hate cheese) to join id Software. But funny enough, I wouldn’t like to stand in their shoes right now! Even though name "Doom" equals gold, it seems to be impossible to make a fun game out of it once again. I'll explain.

Everyone older than 20 has likely played Doom (1 or 2). And younger generations have at least heard about it. Grandpa telling his grandchildren how Doom was the shit back in the nineties. The Nineties, where your mother wore gigantic earrings, where rappers had high-top fades, where the effects of Terminator 2 were mind boggling, and the flying car would come soon. Doom is still notorious, even though the last installment, Doom3 (2004), didn’t quite please everyone.

Maybe id Software just got old. But wait. How about those other old Bastards? Quake4 (2005), a follow up on Quake2 (1997), was cool but considered old and stiff. Games by then had open worlds, dramatic stories, Havoc physics, et cetera. Halflife 3 then? Eh…. Their development takes even longer than Tower22. Halflife2 was released in 2004. Some add-on episodes were released as well, but not a single f*cking screenshot from Halflife3. Hence, even their “Episode 3” didn’t appear (yet). And honestly I’m not even curious about it anymore. Enough City 17, Alix, Robot dog and Combine. They had their chance and didn’t show up anymore. Just give me a brand new bad-ass Halflife 3.

Duke Nukem then? Well, we know how that ended. “Shit happens.”, as the Duke would say. So, except from Halflife2, NONE of our old heroes managed to release a truly successful shooter-title in the last 15 years. It was either “fun but not revolutionary”, mediocre, plain shit, or it just didn’t finish at all.

We older guys have patience, and our warm memories will help forgiving faults, and makes us still looking forward to their next titles. The younger generations however may have seen the hypes, bought Duke Nukem Forever, and had to conclude those legendary super-games just sucked. It’s just as “cool” as your dad telling about how awesome The Beatles were back then… it’s a feeling and vibe you can’t bring over. You had to be there, back then. And time changes.

Back then we had Big Fucking Guns son


Now what?
So, looking at the trend, my guess is that Doom4 won’t be much fun either, and those development problems aren’t a surprise. Maybe Halflife3 will do better, and that’s because its founded on a more modern (accepted) game design. As Halflife 1 was ahead as well back in the nineties, compared to other “dumb” shooters. The newer Quakes, Dooms or Dukes, are grand children of the “dumb shooter” genre though, and that’s exactly where the problem starts; Identity Crisis.


If I were in the shoes of id or 3D Realms, then what would I do? 18 years ago I wanted to make games like Doom, so, here is your chance. Tell us, genius, now what?

In forum user-reactions, I often read that games like Duke Nukem or a new Doom will fail (or failed) because they are based on simple, dumb, linear, mindless, corridor shooting. While modern games involve emotions, more thinking, deeper story characters, RPG elements, and whatsoever. Plus they also come in a different difficulty setting. While old games were a hard challenge testing your button-pressing skills, modern games focus more on pulling the player through an immersive story. It’s like comparing Heavy metal music with complicated stupid out-of-rhythm Dub Step tunes. It’s Arnold Schwarzenegger muscles versus Morgan Freeman storytelling. It’s wrecking cars versus solving Sudoku puzzles. Drinking beer versus drinking expensive wine. Modern games sure aren’t all good, but as you can see in their budgets, they take themselves very serious, and care a lot about immersion. At the same time, these huge budgets prevent designers from trying out new stuff. They copy from each other and play safe.

But I don't think those games fail because they are "old". I think they mixed up with modern (copied) elements in an inconsistent way, rather than trusting on their roots. Doom, Duke, or whatever old shooter, got stuck somewhere between the past and present. You simply can’t tell a dramatic story in a joking Duke Nukem setting, so let’s just limit it to saving chicks, like in the old days. But! Instead of carrying 12 weapons, we can only carry two now. Because hey… carrying 12 weapons isn’t very realistic, is it? The Doom3 guy still kept his mouth shut and mainly mowed down imps with a shotgun, but at the same time we could learn a dramatic story about what happened on Mars 5 billion years ago, and the overall horror setting was rather dark & serious, compared to the “crazy awkward weird hellish” atmosphere in the old Doom games.

A game that is only about shooting and destroying things, sounds old. So these games added some story, friendly NPC's, vehicle sequences and other "surprises". But even though I liked the Quake4 Mech parts (cause of the sound effects), such additions usually feel cheap and forced. You're not fooling us! So please, just focus on your core again!


Let's chew Bubblegum again
And that’s where it really went wrong, though very little forum-people seem to notice that. The “Core” elements weren’t done properly either! Don’t get me wrong, I liked Doom3 and Quake4, but they weren’t as addictive and fun as their ancestors. Multiply that argument with 10 for Duke Nukem Forever. I don’t necessarily believe that old-school-dumb-shooters wouldn’t be fun anymore. Hell, kids are playing ANGRY BIRDS these days! That isn’t exactly a revolutionary, dramatic, diverse, photorealistic, deep experience either. No, they just made a simple game. BUT THEY MADE IT SOLID.

And maybe it’s just me, but I still enjoy playing through old Doom (or Halflife, or Quake2, or Red Alert, or Super Mario, or …) now and then. Maybe it’s nostalgia fooling me, but recently I also played Advance Wars for the Nintendo DS. No complex stories, not very beautiful, annoying Japanese Anime kids as war CEO’s, but very, very enjoyable. And no I never played such a game in the past, so Nostalgia doesn’t count here.

The ingredients to create a so called “next-gen” game, don’t automatically equal a good game. In fact, I only like very few game, next-gen or not. In the end, a well chosen setting + addiction and fun are still the dominant factors. But those are quite often neglected, and masked with a lot of eye candy and other kinds of distraction. Making a game that is fun in the bare bone, just isn’t easy. It wasn’t in the Nineties, and now it still isn’t.



Eureka!
If that is all true, then in theory an old dumb game like Doom2 could still work out anno 2013. But they just have to do it properly! Ok. Then what exactly made Doom or Duke Nukem such good games back then, and what did they forget in their latest releases? Well, I can name a few things. But in one sentence: Realism took over, too much. If you played older games, then think back again for a second… weren’t those old level designs kinda weird? Levels these days are based on real-life structures. Even damaged sci-fi factories are still based on architecture that would make sense more or less. Compare this:


Even though Doom3 is more modern, its “scare factor” is based on more classical ideas. Darkness, cold lighting, damaged crap, blood stains, you name it. Doom2 on the other hand was a cacophony of purple skyboxes, green flames, walls of pink flesh and poison lakes. Combine that with metal rock music (instead of silent scary ambient mood sound), and the craziness is complete. Not just Doom, a lot of old games were a bizarre mixture of sounds, flying platforms and absolute illogical worlds. Actually Duke Nukem 3D was one of the first games with worlds that would come closer to real life situations. Cinema’s, sexshops, bars, flooded streets, space ships with lava… oh wait, there we go again.

Upcoming photorealistic graphics, has killed creativity and daring level design. Although the worlds look a hundred times better now, they all fall back on real life scenario’s. No matter it’s a sci-fi, medieval, cowboy or jungle shooter game. Looking good, but not very surprising really. Hehe, by the way, one of the user reactions I saw about graphics:
"
IDGAF that your new frostbite engine can render amazing
dust particles in sunlight. As a geek and someone who can't
wait for games to look great, yeah, it's amazing. As a player,
I ain't spending $60 to see digital dust.
I can go up to the attic and see it for free
"

Oops.

And yeah, even though I spend most T22 time on graphics, the quote is painfully true. So coming back to the question “what should I do for a new Doom or Duke Nukem?”… Well, make some bizarre, illogical, colorful, twisted worlds again for start. Think out of the box, and DON’T think about what you see outside in normal-life(tm). Think in 486 computer style, where we needed other tricks to surprise. Make something that you WON’T see when turning on the TV or walking on the streets. For a change, just make levels with random themes, again and don’t care about one big story line that logically connects all the worlds. “Level1: bloody compound”, “level2: Skull library”, “level3: Lava Gaybar”, et cetera. Surprise me.


Second, they should perfect the art of killing hordes again. 18 years ago I enjoyed quickly running and launching a rocket, blasting 6 zombie-dudes at once, and now I still do. Too bad that 99.9% of the games don’t allow that anymore. Except Valve’s “Left 4 Dead” where dozens of zombies run at you. And guess what, it’s one of the few games I regularly play. And I’m not the only one playing it, so they must be doing something good!

In Doom3, you didn’t fight hordes, but hidden dangerous monsters one by one mostly. Quake 4 pumped it up a bit, but was still quiet and slow paced compared to its ancestor. The makers of Duke Nukem Forever didn’t understand its own roots all. Shooting a three-barreled machine gun AND kicking the mighty boot at the same time at a monster shitting on the toilets was awesome. But now shooting at the few enemies, with a stiff old Duke, just felt like paving your backyard with heavy tiles.

Just give me lot’s of monsters in lot’s of surprising variations, high speed avoiding of projectiles, plenty of blood, and excellent sound effects that keep us satisfied each time the trigger is pulled. I know in the Doom3 days, making such hordes wasn’t possible due computing limitations, but that should have been solved by now. And otherwise just remove some triangles and bones from your models. In the end, fun sells, not graphics.


Well, I’ll dream on again.

Saturday, May 4, 2013

Demo progress

How about a nice cup of... progress updates. Last months some people left, some I kicked out myself as they stopped emailing suddenly (is there a medical explanation for that?), and others joined. 99% of them is busy with other stuff, and me myself is kinda occupied with work lately as well. A prototype harvesting machine with complete new touchscreen and controllers has to be finished within the next few months. And at the same time this new system will be deployed on other machines as well, plus there is the usual extra load of work that comes with the spring & summer as the harvesting season, and thus the service, special options & angry farmers, begins. To compensate the extra desk-chair hours, I'm also sporting a bit more last year to prevent dying from a heart-attack. So all in all, less hours available for Tower22, simple as that. No worries though, it won't be summer forever, certainly not in Holland, and when the new software works well, things will get back to normal.


Yet, we slowly march forward to a next Demo release. Not near as fast as it should, but at least something is happening. I won’t tell you all the details as it would spoil things, but at least I can show you a picture of my girlfriend here:


Not too shabby ey mate? At least not if you compare it with the first looks of that same corridor. Until recently, the Demo corridor looked well, like shit. And as I wrote earlier in the whole “Radar Station making off” , I had my doubts if this corridor would ever look good. By now I should know that only with a fair amount of tweaking, using the right textures & colors, placing the light sources smartly, and delivering a *complete* scene, will look satisfying. No matter that kind of super-shaders you have, the environment won’t look good if it fails at any of those points. Yet as a programmer, I might be fooled a bit with the illusion that I’m doing something terribly wrong when each time I load a new environment or object into the game for the first time. After hours of blood, sweat and tears, you’ll get something like this:

That’s not very motivating for the artist. But, cheer up, the other picture above shows that things will start looking good sooner or later. What we did for this particular corridor lately? Well, let’s sum up:


• Textures
Of course stupid. The first time I loaded the corridor mesh, we didn’t have any texture that would fit with the original conceptual drawing. Most textures made so far, were from an industrial type, related to the Radar Station demo. So for starters, we had to make parquet wood, a red runner carpet, wall panels, and the upper walls / ceiling.

That on itself isn’t enough. If you look at the red runner for example, you’ll see it has a painfully sharp edge that makes the carpet look out of place somehow. The lack of proper Anti-Aliasing in T22 makes it even worse, though that’s another story. Anyway, we needed more variation on the textures so we are making Decals (cracks, peeled of walls, rotten leafs under the plant, switches, cables, …). And, we make use of Entropy in most textures nowadays. This basically comes down on mixing texture variants by Vertex Painting. The worn carpet at the edges in the upper shot is the result of mixing in a variant. Same thing for the darker ceiling texture.


• Improved bloom & lensflares
The atmosphere in this corridor has to be “sleepy”, “warm”, and “gloomy”. Earlier shots were too dark at my taste. The original drawing showed a much brighter room though, and I liked that. But as brightness increases, graphical shortcomings, emptiness, and errors will become more visible too (so I actually use darkness to mask things). One of those errors was the crappy bloom. Either it was non-existing, or too much. Now a more subtle blur has been used. And to improve the effect without needing extraordinary blooms, lens-flares have been added lately. They can work on any bright spot on the screen, not necessarily lightsources only.


The original sketch by Pablo. Different corridor actually, but same style.

• Lightsources
Sounds stupid, but yes, you will need to show somehow where the light is coming from. If you place a light in your scene, but without having an actual model of a bulb, sun, projector, chandelier, or whatever that can emit light, it will look fake. So we made the chandelier (no flame sprites yet) and a smaller wall-lamp.

Then an underestimated step comes, placing the lights properly. Where do you want your lights? Usually people put them in logical way so that the entire environments catches light. But for games, this isn’t always optimal. Logical lighting equals boring lighting, as the entire scene receives the same amount of light more or less, leading to low contrasts and a bland taste. Breaking lights to create a darker spot is therefore an often used trick (plus it helps the performance as well, less lights = faster rendering). But looking at the drawing again, I realized that I needed this “blandness” for this particular “sleepy” look. Just putting lights at random points, without symmetry, would look strange.


• Volumetric effects
Another keyword was “gloomy” though. Yes, it is a horror game. So how the heck can you make things look scary with the lights on? Well, with some magical tweaking of the colors. And who says the lights will always stay on? Game engines worked so damn hard to make realtime, dynamic lighting last 10 years, so make use of it!

To add filthy warmth, I made volumetric dust fields. Right now they are too thick at my taste, but otherwise it gets a bit hard to see them in a static screenshot. This is not just some little particles flying under a lamp source. We actually raytrace each pixel on the screen to measure the fog density + received light a ray traveled through. This allows cool volumetric shadows, and yes, it’s a slow GPU eating effect.



• Programming
Busy with AI as described in the earlier posts, and this demo will show you some realtime GI. Or actually not, if you implement GI properly it shouldn’t be really noticeable except when doing some extreme wild things with the lights. But as you can see in the screenshots, the corridor ceilings aren’t black even though no lamp is directly shining on them. That, my friend, is GI doing its magic.

I won’t go in detail about it, and this effect is neither 100% done nor perfect, but it seems to be cool to prove you can handle GI nowadays, so here it is.


• More objects
With a single object you can’t win the war. If you place a pretty girl between pigs, she will get dirty and ugly eventually as well. Same for objects. A single nice looking plant won’t cheer up the environment. In fact, it looks weird if the rest remains empty and undetailed. So we added little junk around the plant, made (fake) doors, a heater, and attached some paintings on the wall. As with real life interior design, the whole composition of objects and colors will make or break the room.

From my personal collection. The small weird panels on the left show the realtime GI + glossy reflection processing btw.



Are we finished now? Of course not. Games are never finished, even not the finished ones on the shop shelves. We need a few more objects, tune the volumetric fog, tweak colors, draw some more decals, try to increase the sharpness (T22 always gets blurry for some reason), remove artifacts, make flaming sprites, compose music, and oh, maybe some other surprises as well…

I’m hoping you can enjoy the new Demo somewhere this summer. And more important for the health of this project, I also hope this demo will attract a fresh bunch of artists with talent, dedication AND time (that seems to be an almost impossible combi). If I’m happy with the result, I’ll pass the demo forward to some popular Dutch games magazine. It turned out that just placing a video on Youtube / Vimeo isn’t enough to make a catch. Got to do some wild crazy fishing, like Rex Hunt.

Wednesday, April 24, 2013

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 :)

Saturday, April 13, 2013

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.

Saturday, March 30, 2013

T22 Book Club

What is this?! Blogger suddenly changed the whole lay-out?! Jesus would turn over in his cave. And walk out.

Maybe this new look isn't so bad, but some parts are broke, and I hate coding HTML. I've been programming pretty much everything the past century, but I just never got into HTML, Javascripts, or any other webpage-building technique. Don't know why. Either I like something, or it doesn't interest me a single binary bit.

Well, the Compute Shader tutorial is finished, and let's not complain again about how difficult it is to motivate a team, make rapid progress, and show you eye candy every few weeks. No. Let's talk about something different... right? .... Hmmmm .... everything ok at work …. Nice weather ... Or actually not, my balls are still freezing off here in Holland ... yeah ….. cold ….. saw any TV yesterday? …. Pfff, really cold outside …. I’m allergic for woolen trousers ….



Nope, not much special to report from T22 either, so I just recycle this gun again.

Wait, I know something. Books!
I’m not much of a reader. Except that I read fairy tails and kids stories (“Jip en Janneke”) every day for our little girl. Which is completely awesome, so if you need a good excuse to read kids books, just make a kid somewhere. But other than that, we don’t have filled bookcases around here. Not that I don’t like reading, and sometimes I do get a nice book from friends, but I usually just don’t have time. Or don’t make time for it, whatever.

However, last Christmas Santa gave me two books (using my own wallet to pay them). First there was “Eugene Sledge: With the old Breed”, which is truly brilliant. You may remember the name from the HBO series “The Pacific”. Well, character “Sledge” really existed, he fought in the Pacific (WO2 really happened too!), and wrote a book about it. Not just a summation of 4 April 1942, Hitler shaved his moustache, 5 April 1942 Frozen beef for diner again, 6 April 1942 some Japanese made stinking Sushi in the foxhole next to us. No, the man actually had the talent for writing things down in a grim, graphical, but also neutral way. No waving American flags and hero’s, just the war as dirty as it is. A biography that shows humanity in its worst possible way. I can really recommend it, and I’ll sure get back on it here some day.



"The Why's and How's of Level Design"
But after five paragraphs I still didn’t reach the actual topic (bad habit), that other book, “The why's and how's of Level design”, by Heurences, or Sjoerd de Jong. That name sounds Dutch btw, or Belgium maybe. You don’t have to be a mastermind to figure what’s the book about. As said before, I never really red about “making games” either. Pretty much all the programming knowledge comes from internet webpages, example programs, and just by looking at the neighbors. Also, the design of a level is not exactly the terrain of a programmer. Design contains
• Picking themes
• Making realistic plans. What can be done, and what can’t be done with the time & tools
• Drawing floorplans
• Make the map suitable for the given type of gameplay (shoot, puzzle, race, platformer, …)
• Making wise use of eye catchers
• Texture & color palette
• Lighting
• Modeling it
• … And so on …

This book covers all these topics, but on a more general level. It doesn’t explain which buttons to click in Maya to create a donut. It focuses on techniques that generally work for level design, and of course, he also shows the counterparts: things that should be avoided. That may not sound very helpful, but it’s just true that many, many amateur and hobbyists make the same errors when designing a new level pack or game MOD. Really, level Design is a job on its own, and you can’t just teach it yourself by reading a book or two. Neither with this book (but neither does the author claim that).


Like developing any creative talent, becoming a good Level designer requires practice. Lots of it. But Rick, why would you want to become a Level Designer? Get back in your programmer hole! Maybe I should, but unfortunately, this project doesn’t have a level designer yet. Of course artists have nice ideas and knowledge about how to setup an interesting scene. But it’s too fragmented to create a consistent world that exactly fits the Tower22 needs. As the book explains, all different elements need to become one. A sports car may look great, but it doesn’t belong in the world of T22. Of course the artists know what the word harmony means, but then the level design still needs to meet the story and gameplay requirements. And my twisted mind about how a horror game should look like, which isn’t the same as Resident Evil or Silent Hill, to name a few.

That’s why projects have one or a few lead designers. They understand all these requirements, and coordinate the artists. Obviously, I play a part in that, as I created the ideas. And most others don’t have time to learn the game plot thoroughly, neither time to coordinate and monitor other artists. So, that makes me pretty much the Level Designer.

No Emmy award for this drawing, but at least I know how to use MS Paint a little bit to make my point clear.

Yet I lack skills when it comes to architecture, making outstanding artwork, advanced 3D geometry, or drawing textures. Not that I have to model everything myself, but it would be nice to get some better understanding, to improve the communication. One can only transfer his ideas to another if he knows how to explain, sketch, and divide the work in concrete tasks. Usually programmers (Beta’s) and artists (Alfa’s) approach things completely different, so as a programmer, I needed to dive in their world a bit to get on one line. That’s why I bought this book basically.

Back to the book. The author covers most of the design aspects you would expect. How to make geometry look interesting? How to break up boring repeating geometry (a very real problem for the T22 corridors), which lights can be used where, and the importance of respecting core gameplay features rather than just mixing random “cool” ideas. But it also tells about planning, and making realistic, feasible ideas. A mistake often made by beginners is trying to do “everything”, but soon finding out the plans are overambitious. Leading to nothing, or half-finished inconsistent results. The book uses a lot of colored pictures, comparing good & wrong situations to show you why certain techniques work, or don’t work. Hence the book title “whys and How’s”. The book finishes with some Unreal Tournament levels he did, and also nice, interviews with artists from the games industry.


My 50 cents
Cool and The Gang. But, the key question, did we learn from it? Hmmm. First, as said before and by the author as well, you don’t just learn level design. You have to try it yourself. Then this book can be used as a guideline to reach good results earlier, and to avoid pitfalls. And although I disagree on a few statements, the book makes logical sense. The advises are true, and he manages to explain it without floating away in vagueness, though a beginning artist may miss some deeper explanations here and there. Many examples are a little bit too Captain Obvious.

Then again, maybe I’m not a beginner when it comes to Level Design. Ever since Super Nintendo and Doom2, I’ve been drawing floorplans, fantasizing about game worlds, and carefully looking at other games. When I play Crysis, I don’t just get “wowed”. I try to find graphical weaknesses that reveal how the world was made. Which techniques, shaders and elements were used? When playing Halflife2, I look beyond the battle and notice the backgrounds and styles that are used to make a believable, immersive world. When thinking about puzzles, I remember how smart and complex the Zelda worlds were made. I know the contrast between nineties games that focused on simple but addictive gameplay, and the more realistic 21th century “next gen” engines (that don’t always succeed in delivering a fun game). So, that doesn’t make the advice from this book less valuable, it’s just that I wasn’t surprised by most advises.

Ok, a little bit news then; bullet holes.


Second, the showcases are obviously aimed at the Action & Shooter genre, using UDK and Unreal Tournament (Deathmatch) levels in particular. That’s fine of course, since shooters are still a popular genre and tend to search graphical limits more than any other genre. But gameplay wise, I couldn’t map it on Tower22, which has a very different, almost unique, style. For example, although I agree with the author that clichés and exaggeration works in games to compensate the lacking (hardware)capabilities to pull you in the game, I try to break with some of them. T22 should not look as if it has been done before.

Another difference. Unreal-like games are split in levels. It’s all about rapid, addictive gameplay. World one doesn’t have to do anything with world 2, just as long they are well designed when it comes to shooting another. World A can be a science fiction space station while world B has a “Capture the ketchup in McDonalds” theme. But most single player, story driven games, can’t permit this variation. Especially not a game like Tower22, where the horror atmosphere is the dominant factor (maybe even more than gameplay). A single mistake can ruin the immersion. Rooms that should be scary but feel safe, cheesy music, a laughable monster, overused predictable clichés, a wrong pacing and timing of scary events… all will reduce the horror experience to a joke. A shooter game can fall back on its core action elements if the environment makes a mistake, but T22 can’t. Of course the book explains how to make floorplans and climaxes, but not in detail. Making a complicated but satisfying puzzle, or a truly scary environment needs some more explanation.


The verdict
Well, those were my two complaints. It’s not really a mistake of the author, as he just choose to use the action genre as a demonstration. You can’t write a book about everything, for both a beginning & experienced audience. So if you want to make action game levels / MODs but don’t have a whole lot of experience yet, I’m sure the book will give you valuable advice. As for me, I need to find an Level Designer that has experience with both horror and complex interconnected puzzle worlds (such as Zelda or Metroid). But where to find those? Abduct George Trevor maybe? (fictive architect of the Resident Evil mansion)