Who has the authority to kill a feature?

 

Who has the authority to kill a feature? In much of software development, the ability of any programmer to declare “this is a bad idea and won’t work,” if they can prove themselves right, is highly valued as an ideal if not a daily reality. Does that apply in game development?

While programmers are the ones who have to actually build the stuff and are first to raise the red flag if there are problems with implementing an idea, they are not actually the final arbiters to kill a feature. In the grand scheme of things, production gets ultimate authority to decide what lives and what dies.

image

Much of the time, the programmers are the first veto – they look at the technology and say “No, the tech doesn’t currently support that”. Sometimes they say “Well, we can make it do that but it will take a lot of effort.” Sometimes they say “We tried to do it and it turned out it’s far more difficult to do than we thought. The time estimate is now much bigger.” However, it’s rare for a feature to be truly impossible with code. It can be done, it’s just a question of how much it will cost (time, people, etc.). Since we have a finite amount of resources to consume for the development of the game, it’s extremely important that we allocate these resources efficiently. In these cases, the programmer veto is almost never absolute – it’s actually a combination of “this is how much it will cost to do this” and “I personally don’t think this is worth the effort”.

image

This means that it’s actually possible to overrule the programmer veto suggestion if the feature is important enough. If the feature is something vital to the product, production may decide to cut other lower-priority features instead of the one in question in order to allocate it the additional resources needed for completion. This is what producers do – they maintain the delivery schedule and try to fit as much high priority work into it as possible. I’ve had this happen before – I was tasked with a feature that ended up being an iceberg. But rather than cut it, it was deemed too important – so they cut other stuff from my schedule for the upcoming weeks and had me focus on the iceberg instead.

image

This applies to more than just programming too – code that supports a feature often isn’t enough by itself to get the feature past the finish line. There are still assets

and content

that need to be created for it to work. If the designers or artists cannot complete the amount of work into their schedules necessary to adequately support the feature, it may end up getting cut as well. This happened to a feature I once worked on – a multiplayer melee combat grab system I worked on was cut not because of engineering or design concerns, but because we just didn’t have enough animator time to build enough animations for it. The system worked just fine, but we had only one animation at the end of the day, so production cut it.


The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Source: askagamedev
Who has the authority to kill a feature? In much of software development, the ability of any programmer to declare “this is a bad idea and won’t work,” if they can prove themselves right, is highly valued as an ideal if not a daily reality. Does that apply in game development?

appcodemarkt

Be the first to comment

Leave a Reply

Your email address will not be published.


*