OrbWeaver

There is a way you can add it, by editing on of the CFG files although I can't remember which one off the top of my head. To invoke it manually type dmap lightCarve path/to/mymap.map at the console. That is true. You have to plan light placement carefully including ambient lights (but not fog lights, they have no impact at all according to my tests). The best thing to do is let FPS be your guide (assuming you don't have an absolutely wizz-bang graphics card that hides performance issues from you) - if a scene is lagging, lightcount is a good area to investigate.

With regards to lighting there is a simple test you can do - compile the map with the lightCarve compile-time option, and playtest. If you see a large improvement in framerate with lightCarve activated, then there is potential value in splitting brushes along light boundaries. If you see NO improvement in framerate, then don't waste any time manually splitting anything.

It merges coplanar adjacent surfaces with the same texture at compile time. This means that if you were to split up a floor brush into several brushes, it would not honour your splits when compiling to triangles, but would aim to produce the fewest tris in any case.

The problem is that it's a binary heuristic that doesn't correspond to reality, with the result that some mappers go to extraordinary lengths to split brushes etc. to avoid seeing blue in the lightcount view, with negligible results (including myself until I realised what a waste of time it was). All other things being equal, a whole screen full of 3-light overdraw would be 50% worse than 2-light overdraw which would be twice as bad as a single light. However unless you are removing a whole screen's worth of overdraw the difference will be much less than this - for example, 25% of the screen going from blue to green with no other changes would give you a maximum of 13% performance improvement (which you won't actually get because there is a lot more going on than just rendering lights). Similarly, 25% of the screen going from cyan to blue (4 lights to 3 lights) would give you a maximum of 8.25% performance benefit - even less signficant alongside all the other parallel rendering tasks. So yeah - keeping track of light counts is important and "maximum of 3" is OK as a rough guide, as long as people don't think that there is some boundary at >3 where the performance suddenly drops.

As a very very rough rule, yes. There is no magic cutoff at 3, it's just a case that more lights = more overdraw, which has a performance impact. The performance drop due to overdraw is a function of the amount of overdraw (i.e. the r_showLightCount colour) AND the screen area of the overdraw, so a small area of 4-light overlap will have relatively little impact.

I have never encountered a game editor that wasn't a bug-ridden pile of crap that crashed without warning on a regular basis. These things are written quickly in order to allow a development team to get their commercial game out before a deadline, and don't go through the rigourous testing procedures that would be expected for a mainstream app.

Assume an arrow can do 0, 20, 40, 60, 80, 100 with equal probability. Let E(x) be the expected outcome of event x. E(single hit) = (0 + 20 + 40 + 60 + 80 + 100) / 6 == 300 / 6 == 50 damage points So for a health of 100, the expected outcome is to die after 2 hits with this system. (For those unfamiliar with probability theory, the expected outcome is the outcome that an infinite number of trials will tend towards, or what will happen "on average" to use the colloquial expression).

That sort of random health is almost uncontested I imagine. In fact it should be higher than that - being struck by an arrow in the chest or head should have a greater than 50% change of killing you in one hit.

I think there should be a new rule that hooded faces for avatars are banned. There's what, 4 people using them now?

The Source engine is basically lower-tech than the D3 engine (with a couple of exceptions, such as the ability to use dynamic cube maps to produce real reflections), but by using pre-rendered static shadows (like T1/T2 did) it takes load off the GPU and allows very large scenes to be displayed. The D3 engine by contrast does everything dynamically, which requires MUCH greater performance from the hardware. You can have expansive outdoor areas in D3, you just have to build carefully and accept that it may require tomorrow's hardware to run smoothly.

The system oDDity seems to be proposing is similar to the luck systems used in certain pen-and-paper RPG games, whereby your luck would decrease with each successive use. It's very effective at discouraging risk-taking behaviour, but it's certainly not realistic.

I wonder how that's going. Last I recall their most recent great leap forward was deciding on a tagline.

There is little or no difference at the implementation level between "massive views" and "massive detail". It is merely a matter of scale. All the engine cares about is how much rendering work it has to do. Whether that is because a single room contains lots of detailed objects, or because you are looking out over a large vista of low-poly objects is not all that important.

No, but whether they would be able/willing to enforce and whether they have anything that they CAN enforce are two different questions, and I believe it is important to understand where the line is drawn. I would never intentially violate copyright or advocate doing so, but in many cases you can do things that people assume you can't without violating some IP right or other. IP companies have been very successful at stirring up a cloud of FUD around anything IP-related so that people genuinely believe that even using the word "Garrett" in conversation would be actionable (even if your name is Garrett, it is a fairly common surname after all).

That's a problem with employer culture as well. My employer does not push me to work more than my contractual hours, but they do seem to have this expectation that my life's dream is to work for them, and I will play all their games, move up through the grades etc. Actually all I want is a stable, stress-free job where I don't have to structure my entire personal life around "business needs". I'm not interested in competition or strutting around like a ponce, I just need to pay my bills and purchase food (and the occasional graphics card update hopefully). Being a contractor is actually quite appealing because of the independence (and of course charging by the hour), but I doubt it would have much stability.

Because we don't have access to the renderer until Doom 3 is open-sourced, which will be a couple of years at least. What you are describing is basically streaming LOD (Level of Detail) which would require a major rewrite of the scene processing code.

It wouldn't be illegal to create an FM that just used the names, as long as you didn't try to cross-import any Thief series assets into the mission. Mere names are not substantial enough to be protected by copyright, they have to be trademarked which requires registration and a fee - something Eidos almost certainly haven't done with "Keeper" or "Garrett".

It is true in some places - one of the things I often hear from people who have visited "poor" countries is how friendly and relaxed the people are, compared to western countries where they are stressed out trying to hold down their jobs and "get ahead". Fortunately in the EU there is an absolute maximum of 48 hours per week set out by law, unless you "opt out". If anybody asked me to work 60 hours a week (or even an extra hour for free) I would just laugh in their face.

Of course it has. Even a professional musician has good days and bad days, and with a number of skilled musicians involved, having a bad day while your opponent has a good day could make the difference between winning or losing.

The only difference between Constantine's sword and the regular sword was that Constantine's did not have a visibility penalty when it was drawn. Much as I would have loved a zombie-killer, it had no extra killing powers whatsoever.

Not only that, but 1) You can't just walk out and change jobs because you don't really like what you are doing, if you have bills to pay and you don't know how easy it will be to find another job (which might end up being just as bad if not worse). 2) Most people can't do the things they enjoy doing professionally, due to lack of demand or just lack of skill. I would enjoy doing level design all day but there aren't enough jobs that require this, too many people who want to do it and most of them are better than me. 3) Many of the enjoyable things that CAN be done professionally either don't pay very much or are unstable and have no job security or guaranteed income (such as being a musician).

If I were a multimillionaire I would do just that. Unfortunately most of us are not multimillionaires, and have to indulge in the aformentioned drudgework in order to feed and clothe ourselves.

I never found looking at other people's maps to be particularly instructive, as it usually involves being faced with a totally incomprehensible mishmash of brushes and objects with no easy way of discovering how each part was built. I find it easier to work up from the basics by following a tutorial and experimenting. What I have found useful is using the r_showSurfaceInfo cvar while playtesting, which allows you to point at something an immediately see what model it is and what texture is applied. You can then look up the model in a 3D app if desired, examine the individual textures or whatever.

Society should concentrate on improving the quality of the years we have, not trying to endlessly extend them. When you spend 5 days out of 7 in an office just to make enough money to stay alive, what the hell do you have to gain from a longer life?

No thanks. Isn't 80 years of pointless daily routine and endless busywork enough for these people?