Though I understand the point of your post, and agree, I have to ask for elaboration on the statement I highlighted. Lets take the subject of new content, for example. How would having more people developing content NOT increase the speed at which it is made? Or how would having more people hunting and fixing bugs NOT increase the speed at which they are fixed? I suppose if those people didnt work well together, but lets assume they did.
Governments throw money at a problem all the time, and things seem to still get worse. :cool:
In the film industry we like to say, "We have fast, cheap and good. Pick 2."
The heads almost always chose fast and cheap.
Heh, yes but it depends on the head. Hopefully they go slow and look for people that are talented AND a cultural fit for the team and company. And unfortunately that is always a slow process.
Hands Wishy a steaming mug of hot chocolate with fresh whipped cream and chocolate shavings on top.
Why thank you! *sprinkles on some cinnamon and sips*
Nagus: A number of folks have replied before I got back in the thread. They very much summed up (and even expanded on) anything I could tell you. I'd only be parroting them. I'd link to each one or quote them, but that's a bit much for one post.
Governments throw money at a problem all the time, and things seem to still get worse. :cool:
My post was regarding manpower, not money. Of course, it takes money to pay those people, but there is a difference between "boots on the ground" and "budget".
only if they are using the same pen and peice of paper the crossword is written on, adapt or die, resistance is futile.
TO an extend, they will always do so. There is only number of source code files that pertain to a specific task or function. Source Control / Revision Control Systems exist to allow multiple developers checking out such files and edit them seperately, and can even perform merges of multiple developers versions of the files. But there are limitations - at some point, the system cannot recognize how to combine these versions. And sometimes, even if it does, it can still lead to problems, since one guy might have changed a small assumption that someone else relied on to make his code work - without the version control system taking note, and possibly not even the compiler that will turn the code into an executable program (e.g. the game.).
Every analogy goes only so far and will reach its limtation - but assuming you split up your cross-word puzzle and everyone gets his own area of responsibility and pen to solve - since it is a crossword puzzle, these seperate areas to solve still have areas where they overlap - and the decision on what to write in 5 letters in the middle left might depend on one 6 letter in the middle top-left. And at that point, you need to manually figure out what makes sense.
Why thank you! *sprinkles on some cinnamon and sips*
Nagus: A number of folks have replied before I got back in the thread. They very much summed up (and even expanded on) anything I could tell you. I'd only be parroting them. I'd link to each one or quote them, but that's a bit much for one post.
Are you saying every person who has replied to my post was right, or just certain ones. If the latter, which ones?
But arent you more likely to get that good iea faster if you have more brains thinking about it and bouncing ideas off one another?
Honestly, no. The best ideas usually come from peopl2 who are very familiar with, or had a hand in developing the system in question (yes, once in a while you do get someone on the outside that does give a helpful perspective that leads to a solution, but in my experience, that more the exception then the rule. And I've been involed in IT and some software development since 1975.)
It's good to expand a team if the success level warrants it, but you should only expand at the rate you can train a new person to be useful on the team with minimal effect on the team's overall progress as development continues.
Though I understand the point of your post, and agree, I have to ask for elaboration on the statement I highlighted. Lets take the subject of new content, for example. How would having more people developing content NOT increase the speed at which it is made? Or how would having more people hunting and fixing bugs NOT increase the speed at which they are fixed? I suppose if those people didnt work well together, but lets assume they did.
I could be dead wrong about this, but being a web developer I think they're may be some similarities between what the Devs do and what I do - even though web development probably isn't nearly as complex. That being said I can relate to what Wishbone is talking about as far as some bugs might create bigger ones and when writing a program from scratch the solution probably isn't as simple as a Google search or looking to some programming book for an answer.
So instead of spending all that time to fix a minor bug (and in the grand scope of STO, these bugs are smaller) which could takes anywhere from hours to months they move on to work on something bigger and better, such as the feature episodes. I'm sure these bugs are always on the back of their minds and maybe sometimes they even think of a solution, go back to it, see if it works, and if it doesn't they let it go temporarily again to move onto something else.
As far as we know some of these bugs may take months, in which case I'm sure they ask themselves "Are these man hours worth using on this compared to everything else we have planned?"
Then again i could be wrong about all of this, but that's how our mentality is in web design. If you have a problem that can't be solved ina certain amount of time, move on to something else and come back to it later.
Honestly, no. The best ideas usually come from peopl2 who are very familiar with, or had a hand in developing the system in question (yes, once in a while you do get someone on the outside that does give a helpful perspective that leads to a solution, but in my experience, that more the exception then the rule. And I've been involed in IT and some software development since 1975.)
It's good to expand a team if the success level warrants it, but you should only expand at the rate you can train a new person to be useful on the team with minimal effect on the team's overall progress as development continues.
in the same terms getting people in who have worked on top titles from the last 5 years like world of warcraft, dont punch me but warhammer online and aion might bring a different perspective to the game but whos to say a different way of doing something is bad. warhammer was an amazing pvp game, well balanced and amazing warzones someone from that bacground who is taught how to use this game engine would be a great added person to cryptic.
someone from world of warcraft who was in the game creating instances and raids bringing there background and experience and the dif way of looking at things to sto could add a great aspect to sto and cryptic
someone from aion who was in the team that worked on zoneing and map usage could bring that experience to sto and even though a dif way of looking at it would improve sto and increase cryptics game/games.
Comments
The heads almost always chose fast and cheap.
Governments throw money at a problem all the time, and things seem to still get worse. :cool:
Heh, yes but it depends on the head. Hopefully they go slow and look for people that are talented AND a cultural fit for the team and company. And unfortunately that is always a slow process.
Nagus: A number of folks have replied before I got back in the thread. They very much summed up (and even expanded on) anything I could tell you. I'd only be parroting them.
But did he get it?
Cheers for the advice, anyway!
My post was regarding manpower, not money. Of course, it takes money to pay those people, but there is a difference between "boots on the ground" and "budget".
TO an extend, they will always do so. There is only number of source code files that pertain to a specific task or function. Source Control / Revision Control Systems exist to allow multiple developers checking out such files and edit them seperately, and can even perform merges of multiple developers versions of the files. But there are limitations - at some point, the system cannot recognize how to combine these versions. And sometimes, even if it does, it can still lead to problems, since one guy might have changed a small assumption that someone else relied on to make his code work - without the version control system taking note, and possibly not even the compiler that will turn the code into an executable program (e.g. the game.).
Every analogy goes only so far and will reach its limtation - but assuming you split up your cross-word puzzle and everyone gets his own area of responsibility and pen to solve - since it is a crossword puzzle, these seperate areas to solve still have areas where they overlap - and the decision on what to write in 5 letters in the middle left might depend on one 6 letter in the middle top-left. And at that point, you need to manually figure out what makes sense.
Are you saying every person who has replied to my post was right, or just certain ones. If the latter, which ones?
I wasn't talking about the OP. I was generalizing.
My original reply was meant for everyone who think they have the talent and skills to help out.
Honestly, no. The best ideas usually come from peopl2 who are very familiar with, or had a hand in developing the system in question (yes, once in a while you do get someone on the outside that does give a helpful perspective that leads to a solution, but in my experience, that more the exception then the rule. And I've been involed in IT and some software development since 1975.)
It's good to expand a team if the success level warrants it, but you should only expand at the rate you can train a new person to be useful on the team with minimal effect on the team's overall progress as development continues.
I could be dead wrong about this, but being a web developer I think they're may be some similarities between what the Devs do and what I do - even though web development probably isn't nearly as complex. That being said I can relate to what Wishbone is talking about as far as some bugs might create bigger ones and when writing a program from scratch the solution probably isn't as simple as a Google search or looking to some programming book for an answer.
So instead of spending all that time to fix a minor bug (and in the grand scope of STO, these bugs are smaller) which could takes anywhere from hours to months they move on to work on something bigger and better, such as the feature episodes. I'm sure these bugs are always on the back of their minds and maybe sometimes they even think of a solution, go back to it, see if it works, and if it doesn't they let it go temporarily again to move onto something else.
As far as we know some of these bugs may take months, in which case I'm sure they ask themselves "Are these man hours worth using on this compared to everything else we have planned?"
Then again i could be wrong about all of this, but that's how our mentality is in web design. If you have a problem that can't be solved ina certain amount of time, move on to something else and come back to it later.
in the same terms getting people in who have worked on top titles from the last 5 years like world of warcraft, dont punch me but warhammer online and aion might bring a different perspective to the game but whos to say a different way of doing something is bad. warhammer was an amazing pvp game, well balanced and amazing warzones someone from that bacground who is taught how to use this game engine would be a great added person to cryptic.
someone from world of warcraft who was in the game creating instances and raids bringing there background and experience and the dif way of looking at things to sto could add a great aspect to sto and cryptic
someone from aion who was in the team that worked on zoneing and map usage could bring that experience to sto and even though a dif way of looking at it would improve sto and increase cryptics game/games.