Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
1000 people working on a game to make it most lengthy, deep with replayability and daily patches - i
sagil
Member CommonPosts: 291
I'd just like to know if it's possible this can be done now or in the future. With money cost, organizing, etc..
To be more clear maybe... is it like having builders working on a wonder building?
I'd imagine this might work for mmos... but single player games are just a once a day or week marathon. Mmos however can last 10 years or more, which WoW proves.
Comments
Do you mean 1000 devs worknig on the game?
I dont know the average wage of agame dev these days lets say they where all on $30k a year... thats a hell of a lot of cash... just on paying your workers.. plus of course some will be paid more an so on..
If the game is big enough then mabye..
i imagine its more like too many cooks in the kitchen
EQ2 fan sites
You would start to get diminishing returns at some point. I don't know which point that would be, but as you added more developers, you'd have to add more and more people to manage the process itself rather than creating actual content. You would need to add more and more people in the QA department and then more people to manage the people in the QA department. At some point, you'd need to add people to manage the people who are managing people. So it's possible, but you might get the same results with five hundred people rather than a thousand people. Plus you'd save a bunch of money. Even more money than going with Geico for your auto and home insurance.
I can not remember winning or losing a single debate on the internet.
IMO, the more Dev's on a Game the worse it will be.
With 20 people, your regular dosage of stupid is quite low, multiply that into the hundreds and even thousands, and the stupid start out-weighing the smart.
Just sayin'...
"The problem with quotes from the Internet is that it's almost impossible to validate their authenticity." - Abraham Lincoln
If content is allowed to be community driven, voted on, polished, implimented and made permanant by the devs, then yes, we could get thousands of players and involved in one game. Foundries, Toolsets, Construction Sets, whatever you want to call them -- need to be player friendly and not programmer-exclusive so that everybody can use the limits of their own imagination to contribute.
Imagine player-created content that becomes blended in with the game and is unique on each server. The game would literally be self perpetuating and would really drive players to want to stay, to want to have characters on various servers, and to want to participate in the community votings system for adding additional content.
Player driven content is all well and good, but I prefer it stays within the limitations of what the programmers & artists have provided to the players within the game.
Second Life is a good example of both what people are capable of creating, as well as the amount of crap they can fart out in rapid succession.
Quality over Quantity, if you will.
"The problem with quotes from the Internet is that it's almost impossible to validate their authenticity." - Abraham Lincoln
Hm. Am I the only one that thinks that Warcraft and Starcraft got 2/3rd of their players because of their modding tools? Okay, it wasn't relatively easy to use, but many people played games inside one game they are familiar with and that started ideas for experienced developers to make things like DotA and Slender.
Now, if I am right, the developers out there that are paid to make games would eventually make an improved game out of the MMO toolsets that is used by the casual and hardcore gamers inside that gaming habitation. But that still doesn't remove the world feeling of the game that have those toolsets.
There wouldn't be quite nice models from the players, but I am for skinning (a la minecraft) and coding (like starcraft but much more suited towards mmorpgs).
PvP is the first thing I have in mind. Those can easily be manipulated because usually they are instanced in mmos nowadays. It could be kill the vampire that no one knows who it is, or a racing minigame. You never know what people will come up with. I'd even think the dungeons would be more strategic when hardcore players make it.
ah yeah nice one i was thinknig in £s hehe
1000 employees earning an average of 30K + benefits, tax and pension contributions, office space, IT equipment, software etc.
Let's say a very conservative 45K per person instead...
That's 45 million per year for a 5 year development cylcle of the 'best game ever'...
...so, 225 million. Add other costs such as advertising, conventions, website, box and disk production etc. in and you can bolt on another 25 million easy...
Box sales at $60 each (lets say $30 net) means you need 8.33 million sales to break even at the get go. This of course won't happen.
Then reduce the support staff to 300 - which is still very high by today's standards - especially considering you have just made a game which minimises the active input necessary for day to day running because it is 'the best game ever'.
That's 13.5 million dollars per year costs on salary, plus extras - lets say 17.5 million total.
Now - let's say it does half as well as Warcraft - 5 million players and subs (yes it WOULD require subs) and these were $15/month.
Loss in the first 3 months would (in this entirely theocrafted scenario) be -$150 million on sales plus subs would mean -75 million by month three.
Lets say you half subscription numbers after that.
You break even month 9 and start to make a 30 million profit (including a deduction of 20% corporation tax factored) per month.
Take into account server and other costs unrelated to directly supporting your employees and lets say for the sake of arguement it turns out to be $25,000,000 per month profit.
I may have something fundamentally wrong, but with lets say a successful 5 year life cycle, thats a licence to print money on first glance.
Makes you wonder how much moolah Blizzard have...
Coordinating 1000 people on a MMO would be possible, but it wont have the effects the OP seems to assume.
For computer programming, remember that, in general, adding more people to a project wont speed the project up. Thats because a programming project is an extremely complex construct that new people have to learn first. Thus adding more people to a project might actually slow the project down.
So what would you do with 1000 people ? You would split them into groups working on different projects.
I dont get the appeal of daily patches, though. A patch means something has to be patched - i.e. fixed.
And again, there are limits to what kind of complexity a single person can handle. Thus more people will NOT patch errors faster.
And thats the point of having 2 instead of 1 people, because thats when communication has to start and returns per person degrade. The only solution is working in parallel - different people working at different projects with no link between each other and thus no need for communication.
Putting aside the economics of the thing (others have addressed this pretty well), I have to ask: daily patches? Really?
Constant rebalancing was one of the reasons I stopped playing WoW. I make it a habit to avoid flavor of the month classes, but going from overpowered to nerfed and back to overpowered inside of a few months got annoying pretty quickly. I like to master a character, which is impossible when a game changes the rules regularly.
If you're talking about content patches, I don't see the point. Pushing stuff out that fast is going to degrade the quality -- a huge staff might help with implementation speed, but it won't make the design any better. At that pace, how do you prevent repetition? How do you prevent rapid gear inflation? Your hypothetical game would be a mess inside of 6 months.
If you want a game with endless content, there are other ways to pull it off that don't involve a live team the size of a small town. You can have something like STO's foundry, you can hire event GMs, or you can implement sandbox features. All of those ideas have their pros and cons (better saved for a different thread), but each one is more feasible than churning out patch after patch, ad nauseum.
I would think it would depend on the MMO they are trying to create, but I don't think it would be as effective as you might think, nor do I think it would speed the process of development. If they were all broken down and managed in different areas of expertise and development areas it may be possible, but they would need to develop it in quarter the time most mmo's are developed to offset development costs, mmo's are already expensive to create. Personally I think it would be a logistcal nightmare.
^^^^^ this, basically.
If you only have one person working on a game, he can be however productive he can be. If you have one person working on combat, one person working on network code, one person working on audio, one person working on artwork, one person setting up a web page, and one person handling customer support, they can probably all be about as productive as they can be, without taking that much work to keep them all on the same page, and without tripping over each other that much. Having several people also means that they can specialize in things that they're actually good at.
But if you have a thousand people working on your game, then you're going to have an awful lot with nearly the same job description. It's going to take a lot of work to keep them all on the same page, rather than trying to do a bunch of contradictory things that won't mesh with what other people are doing.
It's also going to take a lot of work to keep them from tripping over each other. You can have multiple people programming a game at the same time so long as they're working on different sections. But the more programmers you have, the harder that is to do, and you can easily end up with a situation where one person changes source code in one way and a different person changes source code in a different way that conflicts with the first person. Neither change is necessarily "wrong"; they just conflict with each other and that crashes the program.
Regardless of how many people you have working on a game, though, daily patches are probably a bad idea. You don't want to push stuff live as soon as it is coded, as it will probably be buggy at first. It takes some time to test code and make sure that it works properly--and if you're constantly changing other code that interacts with it, you'll never actually know that it all works properly together.
There's also the nuisance of making everyone get off the game to download a patch. If you have a patching system like ATITD, where you can push a patch live without having to take the servers down, then it's less of a problem. Even a system like Guild Wars, where you can let players keep playing but log off to get a patch when they want it, makes frequent patching more palatable. The latter absolutely requires very heavy instancing, though. If you've got a patching system like World of Warcraft, where every single patch means two hours to go get it and then another hour to fix everything it broke about your UI, daily patches would mean you hardly ever get to actually play the game.
"It's a sandbox, if you are not willing to create a castle then all you have is sand" - jtcgs
Good God -if they actually meant 1000 Devs - forget the whole thing.
I was calculating based on 1000 people TOTAL.
On the other issues - with good integration engineers and absolutely TOP project management, multiple threads of work could be coordinated successfully.
But it is a project which would basically need all the best people in the business.
It would make a ton of cash though - if they pulled it off.
Not going to happen. Aside from the money issue, co-ordinating 1000 coders is a highly professional job. Most project teams are way less than that for a reason.
Too many Devs in the Kitchen....
When you have that many the message of the game gets lost and suddenly you end up with a mess of ideas that don't work well together. You couldn't just have one person in charge of a team like that so you'd end up with poor communication.
Which is why your integration people would have to be top notch and the project coordination extremely well defined - so groups of coders work on discrete subsystems as much as possible.
I disagree - it would be poor if the project management was poor.
It is not a foregone conclusion that becuase it would be extremely challenging, that it would fail.
Most of that would be artists, designers (lore content), and scripters (script coding for content mechanics). After a solid engine / server / db framework is in place, there really isn't much programming that needs to be done.
Organized into teams of 40, that's 25 regions at a time being worked on. That's enough to crank out a completely new Outland sized world every month.
Possible? yes, but it would be so huge and expensive that it would take millions of player to cover costs.
Back in the day,
way way back in the day...like in the morning of MMO's when they were still Mud's, text based and your UI...if you had a ui...was a paper doll that turned red when a limb was hurt (yea they had limb specific mechanics back then...something we still don't really do)
back in those days, GM's were people who would randomly spawn invasions, your city would be full of monsters of every type from kobolds to demon elementals...it was glorious and it never seems to work in the new MMO's
Part of the reason would probably be all the crying people would do if the race to level 100 was slowed down because they couldn't turn in a quest because some "Stupid developer" decided to do a "stupid event" but man..those events rocked you would have the entire city engaged and healers and rezzers would set up shop in the town center while low levels would scatter out of the hell that was happening or just die. You could drag bodies in most of those text based games, another thing we don't see now...probably because someone would use it to grief...but people would be dragging the dead to the rezzers even if they couldn't fight they could do something.
I would like to see those types of events happen...not content updates just events that happen and a code capable of letting people put those events into place and then employees willing to use that code to enhance the fun of the game.
They would also set up random shops where you could buy unique items, now I know it is much easier to do unique items back then because it was basically just changing text where as now you would have to recode graphics or put in new ones...still you would think it wouldn't be that hard to change color paterns and the like to make some nice stuff...
ahh well I am done talking about the hazy old days.
It would be cool if you had enough developers in a game to run stuff like this though, instead of having programmers only involved in making expansions and content updates and bug fixes and class rebalancing.