[hacker_9]

I think you might be missing the point of the article. The metric for measuring a game's success is how fun it is to play. You can't plan fun, that only comes from having a playground and tweaking things until the game play feels satisfying. Note I use words like fun and satisfying - words that are all highly subjective, and can only really be ticked off when you have the game in front of you and can agree it was fun to play.

The metric for measuring the success of software on the other hand is directly proportional to the amount of functionality it implements, as defined in the requirement spec. These totally different goals for development are the reason the industries are so different, and why one is harder to plan for than the other.

[ZenoArrow]

You don't have to build the whole game to get started on testing how fun it is to play, you start with an ideas sandbox and go from there. A large part of modern game development is involved in building up art assets, you only need a minimal set of art assets before you start playtesting and refining ideas.

[hacker_9]

Not always true. For example the combat animation in the Arkham games - without it how do you test the combat is satisfying? Or the super cars in GTA, how to you test they break in interesting ways without having the finished mesh? Or the gun projectiles in Fallout - how do you tweak them to feel right without a good bullet mesh, physics, collision, particle effects and so on? Satisfying game play is just as visual as it is functional.

[ZenoArrow]

I said minimal, not zero. To use your Arkham combat example, you do need to build the character animations, but you don't need to build the Arkham city environment in which those combat animations will eventually take place.

To give a visual example, in Street Fighter 5 there's the training stage, which is very simple but ideal for testing character animations and game mechanics. If you were developing Street Fighter 5, wouldn't you build such an environment first?

http://media.eventhubs.com/images/2015/07/07_betapics02.jpg

[hacker_9]

You are saying then that the animations are 'minimal' in the Arkham games, which they are not. To make the animation as fluent as it is would require a lot of work and tweaking. Street Fighter on the other hand has a defined set of animations that are played independently of the attack animation, resulting in far less work but overall less satisfying visuals.

Finally, of course you can build the environment separately if there is no dependency on it.

[ZenoArrow]

> "You are saying then that the animations are 'minimal' in the Arkham games, which they are not."

I'm saying for playtesting they are the minimum you need to do the playtesting. If playtesting is a priority then you work on the elements important for playtesting first. "Minimal" is not a reflection on the amount of work that goes into getting up to the playtesting baseline.

[nradov]

The metric for success on any commercial software is long-term ROI, not "fun" or "functionality". This applies to both games and business software. Fun and functionality can't really be quantified in a way that's consistent or comparable across products.

Some of the most successful games aren't really much fun for the most active players, such as MMORGs and free-to-play mobile games. They seem to succeed more through triggering addiction and a sense of competition amongst players rather than providing an enjoyable experience.

[andrewvc]

A major point of the agile manifesto was that building any software to a waterfall spec results in unhappy users. Even enterprise software is iteratively designed these days (well at good places at least). Games are not special.

[hacker_9]

Agile is no magic bullet. Additionally 'change' means a very different thing when you are talking about in-flexible data (3d models, textures, animation etc), and usually means throwing the data away completely and starting over. This is a lot more work that adding a form field to a web page, or changing the business logic behind a query by moving some code around.

[bartread]

This^^^. Scheduling for some types of software is harder than others. I mean it's always a pain in the neck, but not necessarily intractable.

I used to work on shrinkwrapped tools for SQL Server and .NET developers, and over time got pretty good at scheduling releases with an ever narrowing window (that was never that wide to begin with), even accounting for the inevitable changes you'd need to make as you got customers to try out the software throughout the project. And you needed some degree of certainty over scheduling in order to coordinate with marketing, make sure sales and product support were trained, dovetail with other projects so that people could be reassigned, etc. Key point, as well: teams are cross-functional, but relatively small.

Line of business apps are trickier because you're often dealing with stakeholders who either aren't sure, or can't well express, what they need. You also have the kind of integration problems that occur much less often than with shrinkwrapped software. Cynically, I feel like a lot of unwillingness to schedule for these kinds of projects - especially for moderate team size/complexity - is really because people just don't like doing it, for a variety of reasons. And by schedule, I mean sit down and do the homework as it were in detail, not just throw a convenient date up on the board (I've never seen anyone do a good job of estimating a software project in the large this way, and it doesn't help the business make informed decisions when you end up shifting the date or cutting functionality under duress later on).

You get similar problems with public facing web apps: because you can roll out a new version of the software whenever you want this allows you to chop and change functionality as needed (or wanted), so things can grow tentacles. Team size and complexity can vary a lot here but, obviously, bigger, more complex teams make it harder to schedule. If you're rolling out functionality incrementally though, this may not present a big issue commercially.

Games are a whole other thing, because the feel of playing, and the fun factor are absolutely key. This is also why I don't think film development is a great analogue for game development. Film is not interactive, but games are, which adds a layer of complexity film doesn't need to worry about. And this comes whilst having a production team of a comparable size and complexity to that of a film for big budget games.

To be honest though, I'm not sure how much team size and complexity factors in with games - just watch the Indiegame film where you have very small teams in all cases, yet (particularly memorable with Fez) development takes massively longer than expected, and involves a rewrite to get the game right. If that hadn't happened it wouldn't have been as good a game.

Like I say, I think games really are a different kind of problem - perhaps the closest thing software project management has to an NP-hard problem. It's really no surprise they ship late, and that crunch is a reality. Perma-crunch though: well, that just makes me feel sick to think about.

[nradov]

The point of agile is for a team to achieve the maximum possible sustainable velocity. If you're building a custom line-of-business application, a web SaaS, or shrink-wrapped productivity software then you typically want to manage it as an ongoing program with multiple releases spread over many years. So a rational manager won't burn the team out on the current release because she needs to keep the team intact to work on the next release. Whereas with most games there's very little maintenance and enhancement work after the initial release, so it might be economically rational to overwork the team in the short term even if that pace is unsustainable.