Documentary vs Hiring More Devs

priorities, i questions them.

on any project, there is a point of diminishing returns for adding more developers.

there's also only a certain amount of parallelism a project can support. for example, maybe adding another c++ dev would get the engine done a month earlier, but the art assets won't be ready in any case.

This.

Also, they already promised the documentary as a stretch goal. It would definitely upset a lot of people if they went back on their word, regardless of what they use the money on.

Also, more developers does not equal quicker development, in fact, projects with too many developers tend to get bogged down in bureaucracy and other delays. Read up on Microsoft Windows development, and you will see what I mean. It's a nightmare!

They also made over 200k beyond the documentary stretch goal. Even if they make the documentary, development will still have that extra money.

There is also the question of whether or not the Doc will actually cost 200K. I doubt it as I think Uber would take more of a hands-on approach to it rather than hiring film and editing crews and what not for a year, the Money is still cycling into the project, and as others have said, more Staff =/= Faster Development in all cases and there are times when the money could be better spent on something like new equipment/tools/chairs/whatever to make existing Staff more efficient.

Mike

They actually dont have extra money. The money required to develop a game of this caliber and all these features will take more than the 2.3M they made on the kickstarter and Paypal. In the end they really need more money but they are going to do the project anyway.

It might cost more(or rather could have) but Uber budgeted for all this and the stretch goals, they wouldn't have(and/or shouldn't have) promised us something more than they could afford. Obviously you can't plan for the unexpected like the apocalypse and such, but to say they didn't budget out the stretchgoals and such is pretty out there...

Mike

I never said they couldnt do it. But a project like this will usually cost much more than 2 million. But it all depends on how they set up the work load. There are ways you can get any project done on a limited amount of funds but it takes a lot of organization micromanaging. But I do still have faith that Uber can really pull it off at the full of what they said. But to say that they have extras is far beyond what is possible considering they still have to provide all the physical goods as well to everyone that purchased them in the kickstarter and on Paypal.

I still don't think you're giving Uber enough credit, it's not like they didn't budget for the KS rewards and such, and while I'm not saying they will have money left over after the game is released the fact is the amount raised past the Doc is Extra in the fact that it doesn't have a particular purpose and will likely be used to fill in the gaps for other features as the appear or something similar.

Mike

Another example was the failed Hellgate London. The Schaefer brothers admitted that much of the reason why it failed was due to overspending the budget and hiring so many devs that they spent more time managing then they were developing.

Which is why when they rebooted their studio as Runic Games and made Torchlight and Torchlight 2 that they kept themselves to a studio population of 30 and are not hiring anymore. It lets the developers develop, the coders code, and they spent less time trying to manage chaos and more time actually getting things done, since it is far easier for them to work with a small focused and dedicated team.


For smaller game companies that lack a money vacuum, a smaller dedicated team is a blessing.

I believe that team size is will be optimal at base $900K goal. Uber will not enter the project if they're not ready. Also, big teams is not always good, since creational flexibility is still limited to a single vision of a game. More staff => less creative freedom per developer => less motivation => less productivity. And don't forget about team interaction/management overhead, which is increasing rapidly with team size.

But aside of $100K for documentary we still have spare $200K, which I'd like to see that additional resources to be spent on something contributing to the game itself. And on occasion I've heard in one of the treads that shields and other advanced defences are not in solely because of production cost limits, so using spare resources to raise that limit would be nice.

A bit of random industry musings:

"Hiring More Devs" does not always mean "finish game faster". In most cases it means the game takes the same amount of time or longer. That being said we're a small enough team that hiring new people to take on specific features makes sense.

A game I worked on long ago had more than 300 people listed in the credits on the dev team alone. The reality was there were about 40 of us and the last month the publisher freaked out and started dumping people on the project. Most of those with their name on in the credits may have only spent an afternoon working on the game; they'd get tasked to fix a bug, fix it as quickly as possible, and move on. Most of the "work" done by those extra developers ended up becoming the full time job of two of the original 40 to undo each day as usually they broke far more than they fixed on top of still having to fix the original issue. One specific bug with a sound effect I remember getting "fixed" dozens of times by dozen different people, always getting "fixed" the same obvious way, which unfortunately happened to cause the much worse issue of breaking sound for the rest of the game. The hapless programmer who had to undo all of that "work" for weeks eventually only needed two days to fix the issue for real.

In the end the game was released with over 30000 bugs in the database, but there were so many duplicates and false issues (again from just dumping huge numbers of people with little actual experience on the project) that we honestly don't know how many were real issues.


On the other hand some big groups are able to leverage the additional man power in a more meaningful way. Ubisoft for example tends to work in relatively small teams even if a project has hundreds of people on it. They break in to groups of 10-50 and work on specific chunks of the game. If you've ever played the Assassin's Creed games you'll know there are one off or infrequently used mechanics like flame throwers on ships or flying sequences that aren't part of the rest of the game. These are the kinds of bite sized pieces these teams work on. In a way things get done faster than if there were only 30 people on the project total, but the reality is more that these additional features just wouldn't make it in to the game to begin with and the game would still take about the same amount of time.

I don't think more Dev's is better and faster at this point!!! It is too late for this!!! Game is already designed, engine is running and minor things need to be done. The hardest part is done:

1) Design is done
2) Engine is done
3) AI is somewhat done but it is based on previous experience so intelect is there already

Only cosmetic stuff, more units, some lua etc. scripting left. This's minor stuff. You need team to achieve hardest stuff that is already pretty much finished. You want to hire 20 people for a week to have gas giants, metal and lava planets ready? Designing the engine to display planets, and handle gameplay -that's the challenge -not scripting the unit.

Debugging?
How can you have smooth debugging when 20 people debugthe game at once. Remember, bug fix can create new bug. When you test it all over you don't know what version to test.

New staff would have a lot to learn about engine. That would be waste of time and money.

Uber ent. entered the project long time, before it was anounced on kickstarter.

You are so off base, None of that is actually done.

Mike

Thanks for sharing that , the middle part is indeed how you do NOT develop games.

Nope, design of a game will continue to the very end. And I think the initial design still needs a lot of work

Nope

Don't think so

Nope

Nope, Chuck Testa

Partially true.

What no nope Chuck Testa. Im offended.

that would at least explain why big software projects are so slow on bug fixing... only one guy is allowed to debug .. while we are at it, the development has to be frozen to ensure that no new bugs are introduced while fixing a previous bug ... holding your breath might not hurt either, at least short term.

Fixed