On 1/2/06, Ben Everett <[EMAIL PROTECTED]> wrote: > [...] We don't > have to worry about team bloat (which I believe Insurgency is having to deal > with to a LARGE extent) and we don't have to worry about any communication > issues. By leaving our team small we can work even more closely together to > develop something that we truly have a shared vision for. > > I hope that helped someone :)
[Wanted to reply to this from the perspective of someone who's worked (far too long) on a much larger-scale project. Quite a bit of the text below doesn't really apply to smaller efforts; on the other hand, not everyone aims small -- there *are* groups that have the resources and initiative to aim quite high, and they have their own unique set of problems to deal with. It ended up being much longer than I expected; anyone replying with "TLDR" will of course be respectfully kicked in the groin.] Team bloat was something both Andrew (KungFuSquirrel, from NS and now at Raven) and I had to deal with on Nightwatch, and it's easy to underestimate the danger posed by it. For one thing, just about any good project management book written outside of China will tell you that simply throwing more people at a problem won't work as expected. Each additional staff member adds a _lot_ of logistical overhead to a team, especially one communicating exclusively (or almost exclusively) over the internet. You also increase the likelihood of running into "bad apple" team members, as well as two legitimate, contributing team members not getting along. From my experience, recruitment tends to reach the stage of diminishing returns quite quickly. At one stage we had over thirty people working on Nightwatch, and I suspect we could have achieved virtually the same results with far staff members working more efficiently. We ended up having to restructure and downscale the project to bring it within a manageable size, not because it was too large for the team to produce, but because the logistical situation the original plans required made it impossible to work on at anywhere near full capacity. This sort of thing is even more problematic when you're working on a single-player episode, due to the amount of interdependence between various pieces of content, particularly in traditionally "lone wolf" fields like level design. Most candidates take quite a while to adjust (some never do), and as a result I've found that teamwork, flexibility, and an ability to follow instructions and not get over-'creative' with instructions often results in better team members that simple raw talent. It's also important to screen out candidates who are obviously in it exclusively for themselves, because more often than not they end up with a bunch of shiny highlights for their portfolio and you end up with an effectively worthless piece of content that doesn't fit into the bigger scheme of your project. The best team members I've worked with excel not because of their skill at e.g. making maps (although that's obviously also important) but because of their dedication to the team and the project as a whole. A more serious problem with overstaffing, though, as well as inadequate screening of applicants, is that the larger the team, the more people tend to rely upon others to do their work for them, and upon an equally nebulous "management" to magically make all the interfacing and integrating happen without any effort by individual team members to communicate among themselves. It can also create a lot of very difficult self-perpetuating slowdowns, with the slow progress of a few team members discouraging others from keeping their own pace up. Doing nothing is probably the worst possible solution, but on the other hand most mods are also volunteer projects, so the range of disciplinary measures isn't exactly that great -- it's not like you can dock someone's pay or give them a reprimand when they're working for free. One related thing that has annoyed me to no end is the unfortunate tendency of unproductive team members to gradually disappear instead of actually quitting. A huge caveat I've discovered when dealing with the HR side of mod development is that a sizeable majority of people just don't have the balls to say they don't have the time or motivation to continue contributing. Instead, they continue to maintain a nominal association with the mod, slowly drop out of contact without any explanation, and end up deceiving the leadership of the mod for months while they generate no content but don't get replaced because everyone assumes they're hard at work. Yet another reason why good communications and frequent status updates from 'core' team members are essential. We've certainly made a lot of mistakes dealing with these sorts of issues during the course of development -- it's not like we had heaps of experience in the field to draw from, and in a lot of cases stuff took us entirely by surprise. I don't know whether or not Nightwatch will end up as an example of a successful modding effort or not -- that largely depends on the outcome of current efforts. Either way, it's certainly been educational insofar as large-scale mod project management strategies go. It's lasted an enormous amount of time for a mod project, so it's tended to be exposed to a lot more development situations than the typical project will see. * * * * * On a different note, I don't necessarily agree with the later suggestion by Eugenio that level development should be broken down into various "passes" by different people. Although theoretically a good idea, given the background most mappers have as well as practical development realities, it tends to confuse things, demotivate people and often doesn't work as intended. It's not a primary point in his discussion, with which I agree for the most part, but I thought I should point it out. -------------------------------- Ryan Desgroseilliers Project Director, Half-Life: Nightwatch http://www.hl-nightwatch.net/ _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
