Sunday, March 21, 2010

DirectQ Non-Bugs

I've said this before loads of times but it seems like it's one of those things I'm destined to repeat...

There are certain behaviours of DirectQ that I won't change; even if other engines change them, even if someone asks politely (or impolitely!) for the change. Nope, won't do it.

The main reason why is that for every one person who wants the change there is guaranteed to be another who doesn't want it. This is a fairly clear-cut case of not being able to please everybody, and in such cases I generally do what seems good to me.

Sometimes that involves giving a choice between the two behaviours, but sometimes it doesn't. The problem with giving a choice is "what do you make the default?" You can guarantee that whatever you pick, there will be people who prefer it to be the other way. You can also guarantee that there will be people who are completely unaware that such a choice exists, even if I put it in a menu with text saying "HELLO! Choice for XYZ here!"

Yes, all of these things have happened in the past.

An example. I had a request to make the gun model smaller with values of FOV above 90. Now, the way DirectQ handles the gun model with these is to draw it as if FOV was 90, and this has met with approval from people. So straight away we're in a situation where we have two contradictory behaviours and it's impossible to satisfy both.

Further investigation of the matter reveals that the way DirectQ handles FOV is actually correct. Fire up start.bsp, set fov 110, go to the torches above the pool in the e4 hall, jump on a ledge and have a look. The gun model is correctly scaled.



So now we're in a Dilbert-esque "put the bugs back in" scenario.

What all this means is that sometimes the answer to a request is going to be "no", even if you think it's a reasonable request, and even if you think it's a good thing to have. Not everybody might think the same way, and sometimes the requested behaviour is just going to be the wrong behaviour.

0 comments: