Just read the valve handbook. Really crazy stuff. All about hiring the strongest people you can, putting them in a flat hierarchy environment so they have to bosses or minions just peers, and letting them individually decide how they can be the most valuable to the company.
article on making half life
2 months to releasing half life they felt like it was just a jumble of a couple of cool things but didn't hold together as a game. So... "We set up a small group of people to take every silly idea, every cool trick, everything interesting that existed in any kind of working state somewhere in the game and put them into a single prototype level. When the level started to get fun, they added more variations of the fun things. If an idea wasn’t fun, they cut it. When they needed a software feature, they simplified it until it was something that could be written in a few days. They all worked together on this one small level for a month while the rest of us basically did nothing. When they were done, we all played it. It was great. It was Die Hard meets Evil Dead. It was the vision. It was going to be our game. It was huge and scary and going to take a lot of work, but after seeing it we weren’t going to be satisfied with anything less."
The second step in the pre-cabal process was to analyze what was fun about our prototype level.
first theory was 'experiential density'; the more interesting things happen to the player the funner. If it's based on distance then the player just needs to move to get more stimulation.
2nd theory 'player acknowledgement'; player feels like they have an affect on the world, shooting hitting things leaves a mark (decal) npc's react to players arrival.
3rd theory 'player's fault'; game warn players about danger and offers solution, then players do better next time, if game just kills em without warning players will dislike the game.
meetings dedicated to a section of the game.
high level concepts and specific events that will be fun.
then arranged into a storyline/chronology
then ruff map w/ notes of what where and when
sometimes try to design around a random prop or idea and that constraint led to funner designs, which got even better when the constraint was taken away once a web was built up, so started doing requirements just for idea generators.
then build it. then play test it.
then fix everything play tester found that wasn't fun.