Thursday, July 14, 2011

Features Schmeatures

I originally posted this on I3D, but I believe that it also has value for going here.  I've expanded it a little from the original post, which can be read here.

Some thoughts on feature requests

Engine development is not a democratic process, and not all engine feature requests are born equal. If you're developing or maintaining an engine, it's inevitable that you're going to get feature requests, and everybody has their own set of favourites. It would be fair to guess that among any random selection of two people, their feature requests will have an average crossover of maybe 50%.

Even if time was an infinite resource (it isn't but let's pretend) there are other factors that influence whether or not an engine developer will implement a feature. For me, and in no particular order of priority.

Stability and compatibility with ID1

These two override everything else. Breaking the original game is not an option. And it not only must work, but it must work with the rest of your code (which may be radically different to the original code).

Compatibility with your vision of what your engine is

Every engine developer has a clear idea of what they want their engine to do or be. If a feature request goes outside of this vision the chances of it being taken up get reduced.

Doesn't fight against other features

If you have two new features and they conflict with each other then one of them will have to go. This means letting someone down, and that sucks, but it's also very real.

Reasonably popular/populist

If a given new feature is only ever going to be used by one person then it's of quite limited value. This is a bit of a grey area - the developer might think it's a cool idea despite that, or whatever.

Easy for others to implement

Every new feature has a chance of becoming a future standard. If it's not easy enough for other engines to also take up, that chance becomes lower.

Works the way mod authors/mappers/etc expect

If not, then it won't be used by the wider community. Take the example of interpolating alpha - nice idea, but no engine supports interpolating alpha. If a mod author switches alpha from 1 to 0, the mod author therefore expects the change to happen immediately. Break that and you'll piss off the mod author.

Works the way players expect

Quake is a known factor, if you play it then you expect it to behave in a certain manner, and if a new feature causes it to not do so, then the feature becomes of dubious value.

Can't be reasonably implemented elsewhere

Some engine features are better off being done in QC (SS or CS), some are better off being part of model/map formats, and so on. Quake already has too much in the engine that really should be elsewhere, let's not add to it.

It is something that hasn't already been rejected?

Sometimes the answer to a feature request can be "tried it already, didn't work".  Another grey area as sometimes code changes elsewhere can make it work, and sometimes the developer might be willing to have another try or negotiate a change to the feature that could make it work.

Conclusion

Not an exhaustive list, but comprehensive enough to think about when requesting new features. Let's get back to time. The last feature request I got that was claimed to be "so simple and will only take you 5 seconds" took two days. It was something I wanted to do, otherwise I would have junked it after half an hour, but it could so easily have been the other way around.

None of this should be taken to mean "no feature requests" - that would be stupid.  Instead, it's purpose is to provide some background info on why the answer is sometimes "no" to a feature request, and why you shouldn't feel too let down if so.  But the answer can also sometimes be "yes" (which should be obvious from the "5 second feature" example above).

End.

Wednesday, July 6, 2011

Updates for 6th July 2011

Work is still outstanding owing to Real Life commitments. Yeah, it's a pain, but right now the last thing I want to do when I come home in the evening is crank up the editor and look at some code.

As soon as I can start picking things up again you'll be the first to know.