ferearchitect.blogg.se

1. #HOW TO PLAY HORROR GAMES IN DEVELOPMENT HOW TO#
2. #HOW TO PLAY HORROR GAMES IN DEVELOPMENT FULL#
3. #HOW TO PLAY HORROR GAMES IN DEVELOPMENT SOFTWARE#

#HOW TO PLAY HORROR GAMES IN DEVELOPMENT SOFTWARE#

Software development is a collaborative game that you play, willingly or not, with your team and your users. Other people need to see it to measure against it. As soon as you give people a ladder to climb, they'll climb it. Social media is about cooperation, but the core of games is competitive. What you want is for the game to acknowledge the fact that it's tougher to get on Reed Hoffman's linkedin rather than someone who sells ads. You'll want to read the transcript of the talk along with the sides to dig a little deeper into the concepts:Īs you accomplish more, there need to be variant challenges. He deconstructs, , and for what they really are: massively distributed games. In a recent ETech07 presentation (also available as a PDF), Raph connects the dots more explicitly. It's important for all software developers.ĭo users want to use your application, or are they forced to use it? What you'll eventually realize is that designing for fun isn't just important for game developers. Take a minute to read Raph's classic theory of fun (pdf) presentation. Raph Koster is a notable game designer and programmer who writes entire books on the theory of fun. You might even say it's fun- either the explicit kind, or the implicit kind.įun may be more relevant than you think to your project. It speaks to a deeper level of engagement in the process than "I get paid to do this." We play games because we derive some kind of essential satisfaction from playing them.

The concept of software development as a collaborative game appeals to me. Casinos are the original MMORPG spaces, as outlined in Damion's presentation (ppt).

#HOW TO PLAY HORROR GAMES IN DEVELOPMENT FULL#

The idea that games can inform real world design problems is not a new one Damion Schubert's presentation What Vegas Can Teach MMO Designers is full of similar insight. And so the moves that make sense in open-source development naturally don't make the same sense for a standard resource-limited, goal-seeking software development project. It is a cooperative game that is not directed toward "reaching the goal", and is not built around managing scant resources. In that sense, it is much more like musicians playing together, or carpet-wrestling, or lego building.

The game will abandoned as soon as it stops being interesting for the players. Any number of players may show up, and they are not on a time-line. The game is interesting as long as it is interesting. Linus Torvald did not say, "We'll make a shippable copy of Linux, and then we can all go home." No, Linus is around, and it will evolve. Open-source development is different because it is not a resource-limited game, nor is it finite and end-point directed. Then it suddenly all makes sense - even if you don't like it. The logic of the funny contractor behavior doesn't make sense until you realize they are playing a different game, in which different moves are called for. It is quite clear that delivery of the software is a secondary concern, and growing the company, growing personal influence, or growing the career is what is many people's minds. In some of the military software projects, what we see is predominance of the career and corporate-enhancing infinite games. This game model of software development has stood me in good stead recently, as I evaluate military software projects and open-source software development. I can now see why Bill de hra calls Cockburn "the agile world's best kept secret." I've only quoted the conclusion I urge you read the complete article to get a full explanation of Cockburn's rationale behind the game analogy. It's a fascinating, thought-provoking article on the essential nature of software development.

#HOW TO PLAY HORROR GAMES IN DEVELOPMENT HOW TO#

Viewing software development as a game gives you better ideas on where to spend your money, how to structure your teams, and how they should allocate their efforts. You should spend your money to win that game. It is a game against time, and a game for mind-share. Software development is a "game", a game of speed and cooperation within your team, in competition against other teams. If software development was a matter of producing models, then you could spend your money developing models. If it was really engineering, then you could apply known engineering techniques. If software development was really a science, you could apply the scientific method to it. Software Development as a Collaborative GameĪlistair Cockburn maintains that software development is a cooperative game: