Jibble

Author Topic: Swarm Development: Postmortem  (Read 80402 times)

Baron

  • Mittens Serf
  • AGS Baker
  • Rottwheelers
  • Not-so-Evil Banana Dictator
    • I can help with AGS tutoring
    • Best Innovation Award Winner 2011, for the concept and management of SWARMAGS
    • I can help with voice acting
    • Baron worked on one or more games that was nominated for an AGS Award!
Swarm Development: Postmortem
« on: 21 Apr 2011, 04:58 »
April 30 Edit:

For those of you just joining the discussion a quick summary is appropriate.  The thread started out theoretically discussing how many AGSers could each make very small contributions to quickly create a finished adventure game, kind of like how a hive of bees will each pitch in their small part to create a hive (page 1).  Then we decided to run a small experiment to test the feasibility of breaking the game development process into one-hour increments of relatively self-directed development time (page 2).  We then spent a while brainstorming lead-sprites (roughly page 3-5) before settling on a composite sprite that fit well with our background styles (page 6).  From there we began divvying up work (originally page 6, now later in this post for organizational purposes), and the rest of the thread is people claiming that work, executing it and discussing it.  
    Project Crowd-venture (our working title, appropriately created in less than an hour by a self-directed volunteer), will be a short game that will hopefully take about 60 hours to develop.  We are therefore currently looking for approximately 60 volunteers to offer one hour each.  Volunteers will be provided with loose guidelines from previous contributors and then encouraged to finish their task using their best judgement or creative whimsy.  The result will be an organic game that will be nothing like what any individual could have come up with on their own.  Read on if you are intrigued, look below in this post for our current requirements or see our Recruit a Team advertisement if you are interested in participating in the project.  

------------------------------------------------------
May 15 Edit:  The following is an updated version of post #104 that details finalized guidelines and work in progress.  For organizational purposes it has been moved to the first post.

So moving on -let's SWARM! Please refer back to the Plot Document Post for background requirements and the Stylistic Guidelines Post for style guidance when drawing background art/objects.  Recall that our Merrick sprite is roughly 50px in height (see below for finalized version) -please use it for scaling purposes (doorways, furniture, other characters, etc.).  I'm going to list all available jobs and people can choose what to spend their hour (ish) working on.  Please claim the job by posting so that we minimize people working on the same thing, and then edit that post to show off your work (and remember to look through to see if anyone is already working on something you're interested in!).

Available jobs:

BACKGROUNDS -background art is priority, do "extras" (colouring, textures, objects...) only if time:
1) LAB BACKGROUND (completed by Grim)
2) HALLWAY BACKGROUND (completed by Scarab)
3) ROBOT LAB BACKGROUND (completed by Corby)
4) EXERCISE YARD (completed by Yarooze)
5) GUARDROOM (completed by Crimson Wizard)
6) Intro Cutscene (completed by Selmiak)
7)Exit Cutscene (completed by Secret Fawful)
8 ) Exit Cutscene 2 (robot monster interior behind talking vampire twins)
9) TITLE SCREEN
10) Crash screen (completed by Secret Fawful)
11) Blast screen (completed by Buckethead)


OBJECTS
1) Objects for Lab (restraining chair, mirror, fridge, magnets, crucifix)(completed by anian)
2) Laser control console (please play rough build to get a feeling for what we need)
3) Fridge Magnets (completed by Ghost)

CHARACTER DESIGN -use Merrick style/size for style
1) Military Doctor (completed by abstauber)
2) Scientists (2) in robot lab (one completed by Yarooze, other completed by Tabata)
3) Preoccupied guard on exercise yard catwalk (completed by Ali)
4) Guards dying in firefight in guardroom (3-4) more or less copies of each other (one completed by Jared)
5) Giant (100-150px) Robo Monster  (completed by Pinback)
6) Vampire twins (completed by JackPumpkinHead)
7) We need a convincing "back" view of Merrick.(completed by Baron)
8 ) Robot Probe (completed by Studio 3)
9) Vampire twin close-ups for final cutscene(completed by Secret Fawful)
10) Scientist closeups for final cutscene (to be based on Yarooze & Tabata's in-game sprites)
11) Cockroaches (completed by Tabata)

ANIMATION -use my robot arm in military colour experiment (page 4, below) for mechanical arm ideas
  -use this basic sprite to work from: try to preserve frames (or frame size) for ease of importing

1) Merrick side walk cycle (complete by scarab)
2) Merrick front walk cycle ( ' ' )
3) Merrick side level take (reach out) (hopefully we can script it that only side views are necessary)
4) Merrick side high take (reach out)
5) Merrick side low take (bend & reach -NOT FOR FIRST TIMERS)
6) Talking animation (sides & front -just bobbing head with open mouth) (completed by Baron)
7) Biting animation (completed by Ghost)
8 ) Merrick back walkcycle (completed by Baron)
9) Scientists idle and being bitten (completed by Tabata)
10) guards being bitten (see page 20)
11) scientist climbing on cabinet and waving broom at vampire (extra characterization for now, to be done if time)

Writing
1) Doctor's intro cutscene rant (completed by Hudders)
2) Merrick exchange with Scientists as he bites them (so that Merrick understands fire resistant properties of pine cones and/or survival capacity of cockroaches)
3) Puzzle design -someone to examine the feasibility of creating an interesting probe repair puzzle for the robot lab.  This would also require writing dialog/messages that would flag the puzzle for the player appropriately cut for time being due to lack of time/interest
       ...more to come.

Interface Design
1) Quick mock up for GUI for the swarm to discuss. (one completed by Studio3).  (We're looking for a one-pane GUI that will pop up when a button or character is clicked (yet to be determined). GUI must have the following buttons: save, load, quit, about and OK (for inventory selection).  Must also have inventory window and character speed slider).
2) Cursor Design (completed by Cat/Tabata/Scarab)
3) Inventory Cursors (completed by Baron)


Music Director
1) Not really my strength, but I foresee the need for someone to direct other musicians to create short loops (MIDI?  OGG?) to suit the various scenes.  Remember the musicians should each only spend an hour, and will probably need some sort of theme/genre to guide them.

AGS Importing
1) Someone to import existing assets into AGS (two backgrounds, three partial characters) so that we can start a GIP thread. (in progress, by Baron)

That's all I can think of for now, but more will drip out over the coming days.  Good luck and have fun!

------------------------------------------------------
Original Post:

I figure it will take me another 1000 hours to finish my game.  Then I got to thinking, if I could only amass a swarm of 1000 fellow AGSers then we could knock the whole thing off in just 1 hour.  To summarize:

         Man-Hours for Project  |  Number of Men  |  Hours to Project Completion
-----------------------------------------------------------------------------------------------------
                1000                      |              1           |               1000
-----------------------------------------------------------------------------------------------------
                1000                      |          1000         |                  1
-----------------------------------------------------------------------------------------------------

We all know that collaboration makes it possible to do vastly more than an individual ever could.   But I'm not interested in "typical" collaboration here.  What I'm interested in is the theoretical underpinnings of a new way to create an adventure game: not a collaboration as much as a swarming.  I envisage AGSers scurrying through the artistic and programmatical equivalents of bee-hives and ant tunnels in some sort of wondrously self-organized mass event. One hundred of our finest writers scripting for 500 of our finest artists to the tune of 50 of our finest composers and the code of 200 of our finest programmers (etc. for the smaller jobs).  Think about it!  A full-sized game created in an hour!  Consider the possibilities!

 Obviously some thought would have to be put into co-ordination:  we just can't rely on our instincts and hormonal signals (..... or can we???  What might a "spontaneous" project look like with a little polish here and there?).  How might you co-ordinate tasks with mutual dependency on each other -tasks that could take days to play-out in the conventional game-development paradigm -so that they can take place all at once?  Does anyone know if this has ever been tried?  What obstacles do you foresee, and what thoughts do you have to overcome them?

Please bear in mind this is a theoretical discussion for the time being: I'm well aware of the logistical issues of focusing 1000 minds on a single task.  For now I just want to flesh out the idea some more.
« Last Edit: 06 Nov 2011, 04:36 by Baron »

2ma2

  • Mittens Baron
  • Now fatter and balder
    • 2ma2 worked on one or more games that won an AGS Award!
    •  
    • 2ma2 worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #1 on: 21 Apr 2011, 08:41 »
Instead of fighting the obvious dilemma with coordination, you could use the fact that 1000 people work with the exact same thing - such as massive limitations, forcing each individual to work within a confined space, and encourage them to bend that space as much as possible. It could be conceptual, visual or technical boundaries.

Radiant

  • Mittens Knight
  • AGS Baker
  • Return once more to the Two Kingdoms!
    • I can help with publishing
    • I can help with story design
    • Radiant worked on one or more games that won an AGS Award!
    •  
    • Radiant worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #2 on: 21 Apr 2011, 13:54 »
         Man-Hours for Project  |  Number of Men  |  Hours to Project Completion
-----------------------------------------------------------------------------------------------------
                1000                      |              1           |               1000
-----------------------------------------------------------------------------------------------------
                1000                      |          1000         |               5000
-----------------------------------------------------------------------------------------------------

This is probably a more reasonable estimate. What you're looking at is the Mythical Man Month anti-pattern, i.e. that putting twice as much people on a project by no means makes it twice as fast.

Re: Swarm Development
« Reply #3 on: 21 Apr 2011, 17:58 »
What you're looking at is the Mythical Man Month anti-pattern, i.e. that putting twice as much people on a project by no means makes it twice as fast.
It depends on the project. One man building a house could take him 10 days. Two men building a house will take them 5 days. Three men might take 3-4 days.
Of course if these men aren't self thinkers and motivated, you're spending most of your time baby sitting and teaching them to build the house rather than just building it individually and not waiting for the other worker to catch up to you. (I know this because my brother builds houses)

Surely an AGS game would be much different mostly because everyone can't work on the same thing at once. You can't have 1000 people working with the same game files at the same time. And the programmer is waiting for the animators to finish their work frame by frame. All the production bottle necks to the AGS side of things.

Ali

  • What will become of the baron?
    • Ali worked on one or more games that won an AGS Award!
    •  
    • Ali worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #4 on: 21 Apr 2011, 19:20 »
If it worked, I think this would end up producing an epic, chaotic version of the storytelling game where each person writes one word/sentence.

That said, it might be fun to play a chain-game where different people designed each room.

Re: Swarm Development
« Reply #5 on: 21 Apr 2011, 19:56 »
This could work well if the "engine" part of the game is created in the traditional way and the swarm designs levels or quests.
Imagine an open RPG where the swarm members only choose how far up the XP ladder their quest is going to be, then design it using some kind of quest designer provided by the programmers.

The main game will then provide access to all the quests as soon as the character is leveled up appropriately.
If this is implemented well, people could keep adding quests to the game.
Fail at Floaty Rog' now!  still having to deal with what games are going through

Re: Swarm Development
« Reply #6 on: 21 Apr 2011, 20:07 »
Well, not that I'm an expert on game making, but having a lot of people working on a game should speed up things...if there's a good system that makes it into a complete whole.

IMO, riping off and modifying a system that is used by big game companies could be a good start.
But on the other hand, we're not talking about normal game making, but this new "revolutionary" way of swarm game developing. Ha!

I'll concentrate on the graphic side a bit here, as that's what I think I do better than other stuff related to game making.

While I'm dreaming of this perfect way of doing things, I will also imagine I have a complete list of all the characters, rooms, GUIs and stuff, along with any requirements for size, colour depth, preferred style (a bunch of reference pictures for that) , and any other requirements the story makers wish for (like crude sketches of what rooms should look like and so).

I would then proceed to start all the graphics simultaneously, and release the horde of artist on them. Or to keep it manageable, organize the artists into "chains" so each gfx part goes through each artists hands once. Each artist would then draw some of the required graphics, and pass it on to the next guy down the chain. The last guy gives it to the quality control guy, who then decides if it is good enough to be put into the game, or rejects it, appends his critique, and sends it to the beginning of the chain again.
In practice, I imagine one guy outlining a room (for example), one guy picking colours and flood filling it, the next guy shading it, and the last guy applying touch ups. Yes, it could be broken down even further, but it's just an example so you can understand what I'm trying to say.
As an artist, you just do your part on one piece, then go to the next one, while the old piece is being worked on by someone else.

Of course, if there's a way you could find so many artist that would draw on a similar level, and produce at least average quality stuff, you'd still need to find a way to move all those sprites between people, track who has what and where, keep them all motivated so they don't bog down the process,and store all the versions of all the gfx in case of accidents and stuff that might need re editing. Yes, pretty simple isn't it? =P

Not to mention that you could try to find out which artist is best for particular fields of drawing so you can arrange the chains to produce better quality art.

And what happens if one artist goes away for some reason? I think it would bee good to have backup artist to jump in if that happens, so the drawing continues regardless of it, maybe.
The more I think about it, the more complicated it gets.

Anyway, it's all theoretical , I doubt anyone will ever implement it anyway.

Re: Swarm Development
« Reply #7 on: 21 Apr 2011, 20:35 »
This could work well if the "engine" part of the game is created in the traditional way and the swarm designs levels or quests.
Imagine an open RPG where the swarm members only choose how far up the XP ladder their quest is going to be, then design it using some kind of quest designer provided by the programmers.

The main game will then provide access to all the quests as soon as the character is leveled up appropriately.
If this is implemented well, people could keep adding quests to the game.

In fact, using the RunAGSGame() feature, it wouldn't be difficult at all to organise an Eternally Us-esque linear game.

If 10-20 (which is perhaps a more reasonable number,) people each were given a fully animated character and were tasked with creating a 1-room game with a specific setting/theme, and one weekend to do it. If you then strung all of them together, you could have a reasonable length game completed in 48 hours.

If the game used RON-style graphics then most people would be able to handle maintaining the style. Or even better, if the theme revolved around alternate dimensions, that could explain any graphical inconsistencies (and make it easier to manufacture creative scenarios for puzzles).

Furthermore, each contributor could submit any music additional animations necessary for their room for use by the others, and thus creating a swifter work flow for all and better cohesion from room to room.

Anyway, it's all theoretical , I doubt anyone will ever implement it anyway.
It's still fun to talk about  ;D

Re: Swarm Development
« Reply #8 on: 21 Apr 2011, 20:51 »
This was done in the German Maniac Mansion Mania forum; it was called Maniac Dungeon. There are about 20 one room games so far and it's still going afaik.

I almost killed it when I signed up for room 6 and failed to finish it though :=
Fail at Floaty Rog' now!  still having to deal with what games are going through

Mr Jake

  • Mittens Vassal
    • I can help with web design
Re: Swarm Development
« Reply #9 on: 22 Apr 2011, 03:54 »
Adding 1000 to a 1000 man hour project doesn't make it require only 1 hour :P

There is a limit at which adding more people becomes detrimental. It's called Brooks' Law (http://en.wikipedia.org/wiki/Brooks's_law)

Igor Hardy

  • Mittens Serf
    • Igor Hardy worked on one or more games that won an AGS Award!
    •  
    • Igor Hardy worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #10 on: 22 Apr 2011, 10:18 »
I think the correct equation for estimating the number of hours you need to do a 1-man 1000 hour project with a much larger team is raising the number of hours (for 1 person) to the power of the number of people on the team.
« Last Edit: 22 Apr 2011, 12:46 by Ascovel »

straydogstrut

  • Barking up the wrong tree
    • I can help with play testing
    • I can help with proof reading
Re: Swarm Development
« Reply #11 on: 22 Apr 2011, 11:07 »
In fact, using the RunAGSGame() feature, it wouldn't be difficult at all to organise an Eternally Us-esque linear game.

If 10-20 (which is perhaps a more reasonable number,) people each were given a fully animated character and were tasked with creating a 1-room game with a specific setting/theme, and one weekend to do it. If you then strung all of them together, you could have a reasonable length game completed in 48 hours.

...

Furthermore, each contributor could submit any music additional animations necessary for their room for use by the others, and thus creating a swifter work flow for all and better cohesion from room to room.

That sounds like a lot of fun and a MAGS could easily be adapted to give it a trial run. You could go the linear route and stipulate that each room must have 1-2 exits to fit with the rest (or more if you want a branching world), or everyone could make escape the room games and join them together box within a box within a box a la Futurama=)

Re: Swarm Development
« Reply #12 on: 22 Apr 2011, 11:46 »
...

That sounds like a lot of fun and a MAGS could easily be adapted to give it a trial run. You could go the linear route and stipulate that each room must have 1-2 exits to fit with the rest (or more if you want a branching world), or everyone could make escape the room games and join them together box within a box within a box a la Futurama=)

Although I feel that the key to making this theoretically possible is to bring the scale down as low as possible, so rather than having something to the effect of 'Everyone make a short game and combine to make a medium-full length game' I would suggest having 'everyone make a tiny game and combine them to make a short-medium length game'

Otherwise you're more likely to have people drop out because they don't have time/ lose motivation in their idea/ were too ambitious, etc.

I don't think it's too much to assume that people can maintain productivity/drive for 8-10 hours to produce a room and a couple of puzzles, especially when they have access to each others music/animation.

Radiant

  • Mittens Knight
  • AGS Baker
  • Return once more to the Two Kingdoms!
    • I can help with publishing
    • I can help with story design
    • Radiant worked on one or more games that won an AGS Award!
    •  
    • Radiant worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #13 on: 22 Apr 2011, 12:22 »
I think it would be funny to have a combined effort where everybody makes one room for a game. Sure, the style and story would be all over the place, but it would be interesting to see how it would turn out.

Snarky

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #14 on: 22 Apr 2011, 12:27 »
This is probably a more reasonable estimate. What you're looking at is the Mythical Man Month anti-pattern, i.e. that putting twice as much people on a project by no means makes it twice as fast.

Hmmm... I was going to read The Mythical Man-Month, but it seemed like it was taking too long, so instead I hired 100 people to read a page each. That way we finished the book in less than five minutes!

Baron

  • Mittens Serf
  • AGS Baker
  • Rottwheelers
  • Not-so-Evil Banana Dictator
    • I can help with AGS tutoring
    • Best Innovation Award Winner 2011, for the concept and management of SWARMAGS
    • I can help with voice acting
    • Baron worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #15 on: 22 Apr 2011, 15:01 »
Interesting thoughts so far.

This is probably a more reasonable estimate. What you're looking at is the Mythical Man Month anti-pattern, i.e. that putting twice as much people on a project by no means makes it twice as fast.

This is a definite problem.  The more people added to the typical collaboration team, the more management/communication/training/in-fighting required.  The problem mostly stems from the "control" aspect, however.  If all the autonomous agents were left to regulate themselves (quality, content, etc.) within loose parameters, and everyone was aware of this fact from the beginning so that expectations of the final product could be adjusted accordingly, I think a lot of the "overhead" in the process could be reduced.  Obviously there will be quality issues, but they may well be substantially offset by the magic of serendipitous creativity in a less-structured environment.  Perhaps afterwards a smaller team can spend more time making the "happy accidents" more prominent and editing out the flops.

This could work well if the "engine" part of the game is created in the traditional way and the swarm designs levels or quests.
Imagine an open RPG where the swarm members only choose how far up the XP ladder their quest is going to be, then design it using some kind of quest designer provided by the programmers.

Using modular design is a really good idea for consistency.  It would take a lot of prep work, true, but it would definitely solve a lot of compatability issues.

I would then proceed to start all the graphics simultaneously, and release the horde of artist on them. Or to keep it manageable, organize the artists into "chains" so each gfx part goes through each artists hands once. Each artist would then draw some of the required graphics, and pass it on to the next guy down the chain. The last guy gives it to the quality control guy, who then decides if it is good enough to be put into the game, or rejects it, appends his critique, and sends it to the beginning of the chain again.

 These "chains" of artists each specializing in one very limited aspect of development reminds me of a factory system of mass production.  With scale this would definitely be more efficient, but it's a bit of a departure from the swarm idea.

I don't think it's too much to assume that people can maintain productivity/drive for 8-10 hours to produce a room and a couple of puzzles, especially when they have access to each others music/animation.

 I guess 1 hour might be a bit ambitious, but the idea is to minimize drop-outs (i.e. lost man hours).  The shorter the commitment period, the less likely people will lose focus, have real-life issues, or begin to despair that their efforts will never bear fruit.  The swarm model allows for near instant gratification, which should be good for motivation.

You've all given me a lot to think about.  For practical reasons it really does seem necessary to do a considerable amount of prep work in advance, have the mass event, and then have a polishing period at the end.  This makes it more like raising a straw-bale house than a true self-coordinated swarming, but without those hive/colony instincts of certain social insects I do concede it would be very difficult to get a mass of AGSers to behave that way.  Definitely a smaller scale event involving 10-20 as Khris suggests would be a better place to start from for experimental purposes.  Based on the results you could try to scale-up the project and streamline the inefficiencies.

Thanks for all the ideas -keep them coming! 
   

Wyz

  • anno 1986
    • I can help with making music
    • I can help with story design
    • I can help with translating
    • I can help with voice acting
    • I can help with web design
    • Wyz worked on one or more games that won an AGS Award!
    •  
    • Wyz worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #16 on: 22 Apr 2011, 15:39 »
Interesting subject! Bees in a hive all have a predefined function which they can execute independently. The only thing that needs to be mutual exclusive is the entering and departing of the hive. For tasks that are almost completely independent the first table would work, but making games has a lot of things that need to happen subsequently.

When I compare it to swarm computing there is still a way to arrange something like this, but it will need a system. Operation systems that support multi-threading actually have such system.
One of the things that will definitely work is as JimReed explained what in parallel computing is usually called a pipeline. You divide a certain task, like drawing a character sprite in to several smaller but trivial tasks that need to happen subsequently. Then you let a number of people execute those concurrently and let them pass on to the next person. As long as nobody falls behind it can be very efficient.

Not everything can be pipelined however so there is another system: queueing.
This is eligible for simple tasks that don't need to happen in a particular order mostly but might have dependencies. Let's say implementing puzzles. There would be 5 programmers at ready, and 10 puzzles not to be implemented. The ten puzzles are put on the queue, each programmer picks a puzzle from the queue and starts working on it. If it is finished the programmer picks the next puzzle on the queue. At any point there might be a dependency and the programmer must wait for something to be finished. There are two options: either he waits, or he put's the puzzle back on the queue and picks another item from the queue to work on. It actually would matter which of the two options he'd pick. Switching tasks will take some extra time because he needs to read into the new task, it might have been something another programmer left and he'll need to get up to speed. On the other hand waiting might take a very long time, in which the programmer is not doing anything useful. The trick is to estimate on for hand which dependencies are bound to take not a lot of time, and you choose to just wait for those.

When using queues and pipelines, and splitting up the tasks wisely (using code by contract is one very elegant way) there still is a problem not everything can be done concurrently. If you take all the things that need to happen subsequently and divide the time you would like to spend by it you can calculate how long each task should take; or make a estimate roughly. I know one person can make a game in one hour, but it depends all on the communication and transfer overhead if 1000 people can make a game in one hour. The question remains: does that game equals in quality as a game made by a single person with the same man hours. I doubt that, but it would be a fun experiment!!! :D
Life is like an adventure without the pixel hunts.

theo

  • SKYGOBLIN
    • theo worked on one or more games that won an AGS Award!
    •  
    • theo worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #17 on: 23 Apr 2011, 21:34 »
Man I'd love to see this in action. Or rather, I'd love to see the results.

blueskirt

  • I'm a doctor!
Re: Swarm Development
« Reply #18 on: 24 Apr 2011, 19:46 »
Using the same logic, 1000 men could hammer a nail in 1 nano second if they nailed it together. ;)

I don't believe this will change the way games are created but it could result with a funny game, if somewhat inconsistent in every aspects.

Radiant

  • Mittens Knight
  • AGS Baker
  • Return once more to the Two Kingdoms!
    • I can help with publishing
    • I can help with story design
    • Radiant worked on one or more games that won an AGS Award!
    •  
    • Radiant worked on one or more games that was nominated for an AGS Award!
Re: Swarm Development
« Reply #19 on: 24 Apr 2011, 21:16 »
If all the autonomous agents were left to regulate themselves (quality, content, etc.) within loose parameters, and everyone was aware of this fact from the beginning so that expectations of the final product could be adjusted accordingly, I think a lot of the "overhead" in the process could be reduced.

I would suggest you volunteer on Wikipedia for a month to see how well that works out in practice. Large groups of people do not self-regulate well.