yeah i like the “play it often” point. i’m encountering the lack of that on the dev’s part in puzzle pirates, areas of content practically unplayable due to design mechanics that fester and never get addressed. areas that are supposed to be “core gameplay”.
“…meaningful PvP that shapes the world AND challenging PvE raids AND an incredible beautiful 3D engine AND a unicorn AND crafting AND player housing AND a pony.”
I am stunned that you forgot to include “fetapults” in that list.
Definatly, enjoyed the egomaniacal writings! You should do them more often.
Has anyone ever tried doing the planning for an MMO i public? Maybe we can make an ‘MMO Tycoon’ game of making a game… set the time / budget constraints and see what we can reasonably fit in there.
Who knows, maybe it would be educational to the players and the dev teams at the same time.
Yeah, right! More like “design by committee” and that almost never works.
@Gaidin6 The trouble is that the victory conditions for an MMO Tycoon are very different depending on whether you’re playing as lead designer, venture capitalist, or community guy, for example…
Though I was planning on critiquing, these suggestions are just abstract enough to be beyond critique. Congrats, I cannot refute you’ve fixed everything – other than the devil being in the details and the details being avoided through a wise choice of scope of the document.
“Scope” definitely would be the over all theme for the failure of WAR, in my opinion.
They had the opportunity to make a kick ass world PvP driven game, and instead they wasted a huge portion of their resources on dungeons and raids that aren’t part of that scope.
Failure to understand that you can’t launch a better version of WoW when you have a fraction of the budget for WoW is failure.
@ibn I assume you realize I was being sarcastic with the “MMO Tycoon” idea BUT figured you’d be the lead designer and the others you mentioned would be obstacles to overcome (venture capitalist wanting the game out the door, community guy wanting the next great game mechanic or more zones, etc.).
In reality I was just wondering if there would be any value to anyone to design “a game” in public (like on MMORPG.COM). People could see that mundane tasks like “Build Server Infrastructure” took 3 – 6 months (or whatever it takes), let alone nailing down ethereal ideas like setting or game mechanics.
Harlan Ellison did an experiment in the mid-70′s at UCLA where he explored the concept of a shared world with some of the best sci-fi writers of the time (the book, titled Medea: Harlan’s World was the result).
I thought something like this might be an interesting experiment, too, since everyone seems to think they can design games better than the folks actually doing it.
Again, not sure how much fun it would be, especially for guys like Lum who does this stuff for a living, but figured it might be a way to show the masses (trolls? can the be taught?) that this stuff is hard. Maybe he could use it as fodder for “LFoL” Parts 3 to 10!
I don’t think the average MMO player really knows or cares about the reasons why so many games fail – they just want to have fun. So, while the effort to educate them as to why these failures happen is laudable, it’s ultimately not going to be too successful.
And, reading the as someone who’s been working on MMOs for more than a decade, it’s kind of like it was authored by Captain Obvious. That’s no surprise, and not meant as an insult either – I’ve just been there, done that, and have the t-shirts to prove it.
Maybe it will help some aspiring developer and they won’t fall into some of those particular traps. Although, you’d have to be certifiably crazy to want to make an MMO, if you really knew what it was like. Nothing like spending 5+ years of your life on a product that gets shut down after about a year of live service. Feels great!
I wonder which elements of PP you are referring to, exactly. I know they added some features after I left, but it didn’t solve any of my particular concerns with that game. I wonder if we’re thinking about the same things.
@Vaxhacker and Geldon
I’m not a designer, but even as just an ordinary player I found some of Scott’s points this week definitely ventured in Captain Obvious territory. I don’t think there is a single developer who would disagree with his points, but whether what that developer is doing is running afoul of what Scott wrote. And the bean-counters on top of them just don’t bother with such considerations to begin with; they would sooner have a bad game that makes gazillions of dollars than a revolutionary one that fails.
What also didn’t help is that despite the contents of the first article, I see little that could connect part two to part one. Part one gave specific examples of MMO failure, brief, concise, almost bullet-point, all condensed to fit into a single article, but you saw what he was getting to. Part two, on the other hand, never so much as mentions a single game to serve as an example of the various points. In some places, like that section on technology, you can easily fill in the blanks: Inadequate server capacity gets you Darkfall at launch, “hubris” should get a portrait of Gaute Godager or Paul Barnett. Why not mention Gaute’s “steak” remark, then?
In the case of “scope”, though, I get the exact opposite problem: I can’t think of a single example that would fit here. The entire lesson seems to be: “if you’re a garage-league studio, don’t try to make World of Warcraft”. Except that the most egregious example of WoW copycatting I can think of was Warhammer Online, and that its problem was not exactly scope. And the other example I can think of, Age of Conan, actually pulled it off as far as the scope was concerned, though it didn’t seem to be that way at launch. So that entire section on scope would have been improved with some examples.
What’s interesting is that there is now another MMORPG.com article that details some of those annoying things in MMO’s that developers just can’t get rid of, even though we’re sick of them. That whole “Kill ten rats” and FedEx approach to questing. The Holy Trinity of tank, ranged, healer. Nothing that hasn’t been said before, but that, if left unchecked, may end up killing MMO’s. But here the real problem is that the list amounts more or less to wishful thinking, like eradicating world poverty.
[...]As Scott points out, most scoping problems are either related to having unrealistic project goals or deviations from your scope (called scope creep). Realistic goal setting is really a function of experience, so ideally whoever is creating a project plan has the subject matter expertise to lay out achievable milestones.
In my experience as a project manager, scope creep has always been the bigger danger. Over the course of any long project, the scope of that project is likely to change or evolve.[...]
-Serial Ganker
Vetarnias :@ethereal.wolf
And the bean-counters on top of them just don’t bother with such considerations to begin with; they would sooner have a bad game that makes gazillions of dollars than a revolutionary one that fails
If it’s making gazillions of dollars, it’s hard to characterise a game as “bad” – by definition, there would be a lot of people who think it’s “good” enough to part with their money for. It might be a “dumbed down, mass market” game, it might not be the game YOU want to play, but a game that is providing a lot of people with entertainment that they manifestly enjoy is doing just what a game should be – so how is it a “bad” game?
Contrariwise – if a game is a dull, unplayable POS that makes me wish I’d spent the last few hours helping my girlfriend with her clothes shopping instead – that’s a bad game. I don’t care how noble the developer’s intentions were to create the next step in the evolution of MMOs, the result should be something that I enjoy playing.
“Part two, on the other hand, never so much as mentions a single game to serve as an example of the various points.”
No need to be specific with examples. Any large software project deals with these issues on a daily bases some successfully and some not.
“so ideally whoever is creating a project plan has the subject matter expertise to lay out achievable milestones.”
This is the path to failure. One person, even everyone in the end, does not have expertise to layout milestones for a team. Everyone is going to hit unknowns usually on discovered when they are doing the actual work. Your process has to handle these common issues if you are going to be able to release a known product to your customers.
I’m not a designer, but even as just an ordinary player I found some of Scott’s points this week definitely ventured in Captain Obvious territory.
The tricky thing about game development is that, in attempting to push the envelope, what was previously Captain Obvious territory rapidly becomes a forgotten prologue. Even a pipe dream atop all the other demands you attempt to meet.
As I said, Lum’s article was relatively irrefutably correct via abstraction/choice of scope. He didn’t get into the gritty details, just laid down the easily forgotten guidelines. He had some good reasons for this:
First, because the gritty details will vary heavily from project to project, and nobody has the necessary omniscience to imagine every little individuality.
Second, because this is an article on MMORPG.com, not a comprehensive designer website. He’s explaining things that might be useful for a newbie designer, but are primarily aimed at MMORPG players who want to know where things went wrong.
So, yes, I could point out there are obvious shortcomings to the message, but this would be very shortsighted of me: looking deeper, it was a good choice of document depth.
You missed the point — which is to have clearly defined and ACHIEVABLE milestones.
Your scope is going to change, no doubt about it. But WHEN it changes, you need to consider how that impacts your milestones and that you adapt your scope through change control to ensure that your project will still be successful.
Project that fail do so because they allow the scope creep without considering the impact on the milestones. And THAT is the real path to failure. Particularly when we are defining success as REACHING those milestones.
I sure hope I don’t completely ruin the tags on this post. Preview? Edit?
UnsGub :
“Part two, on the other hand, never so much as mentions a single game to serve as an example of the various points.”
No need to be specific with examples. Any large software project deals with these issues on a daily bases some successfully and some not.
That’s an [i]un[/i]reason. If any large development project runs into these problems regularly, and there’s no need for examples because everyone is familiar with them, why even bother writing the article?
geldonyetich :
First, because the gritty details will vary heavily from project to project, and nobody has the necessary omniscience to imagine every little individuality.
Then why bother mentioning the examples of failure in the first article? As you’ll remember, this was a two-part series, which implies some sort of connection, and the conclusion of the first article was “Conclusions, And How To Fix All Of This Mess.”
Second, because this is an article on MMORPG.com, not a comprehensive designer website. He’s explaining things that might be useful for a newbie designer, but are primarily aimed at MMORPG players who want to know where things went wrong.
But that’s precisely what wasn’t addressed. “Here are some very specific spectacular failures, and on an only somewhat related note, here are reasons some games sometimes fail.” Connect the two, or don’t bother linking the articles in the first place.
As I was taught back in high school, or hell, maybe even grade school, providing examples to illustrate your theories always bolsters your point, and this is no exception. I also learned in high school Geometry and Trigonometry that “it’s obvious” is in fact not an acceptable proof.
I completely disagree with you two and agree with Vetarnias on this one. I enjoyed both articles, and both were well written. The conclusion does not address the introduction, though. I would have liked to have a seen a re-visitation of each failure from the first article along with a brief blurb of why it failed. As it is, I’m going to try and do it myself, and I’m going to fail, which further leads me to question how the two articles are related:
Ultima Online Problem: Rampant mean-spirited non-consensual PVP Failed due to:
Scope: Not being big enough to include a PVP flag at first, contrary to the article highlighting creeping scope as an issue?
Tech: I don’t think so, unless you want to consider that flag tech, when it was really a design choice.
Customer Service: No?
Fun: Maybe the devs didn’t try enduring being PKed?
Hellgate: London Problem: Wanted to charge like an MMO without being one Failed due to:
Scope: No?
Tech: No?
Customer Service: No?
Fun: No?
EQ2 Problem: Wasn’t enough like its predecessor? Failed due to:
Scope: No?
Tech: No?
Customer Service: No?
Fun: No?
Auto Assault Problem: Weird game with no clear market Failed due to:
Scope: No?
Tech: No?
Customer Service: No?
Fun: No?
SWG Problem: Expansion pack completely changed game, pissing off loyal customers without gaining any new ones Failed due to:
Scope: No?
Tech: No?
Customer Service: Maybe? Not really customer service so much as neglecting to consider your current customer base’s interests.
Fun: Maybe? Whether or not the new expansion was fun is really beside the point, though.
I mean, hey, the failures were fun to reminisce about and make fun of, and the tips and pitfalls are all relevant and well worded. The two are not connected, though, despite the fact that the articles are. I’d have much preferred a little connection and resolution.
The distinction is perhaps more difficult to make for video games – if you have fun, you have fun. Compare that to movies: James Cameron still can’t write a screenplay, and Avatar, $600 million later, will inevitably win for Best Picture. The problem is that I’m constantly having run-ins with WoW fanboys who insist that WoW is teh bestest game of all time, in everything, because it has 11 million players to prove it. Any criticism is futile, because if it were bad, it wouldn’t be played.
@Geldon
I see what you mean, though I don’t think it will change much for MMORPG players. You know they will complain nonetheless at the next game, and may even look upon Scott’s article as an excuse for developers.
Beyond that, I’m puzzled by Scott’s use of pronouns in the article. “You”, for instance, is aimed not at players, but at developers. Sample: “You will have to convince your stakeholders, your team members, and your prospective players…”. Players themselves are referred to in the third person, even though they are assumed to be the intended readers. I suspect it’s a style decision to make player-readers feel they are eavesdropping on a confidential discussion between two developers; but you need something confidential being said to maintain the illusion. If Donald Trump were giving financial advice to a (nonexistent, purely for narrative purposes) business rookie in front of a middle-class audience, wouldn’t you expect something a little less obvious than “buy low, sell high”?
Furthermore, Cymbaline’s post also demonstrated (I’ll have to rely on her judgement, as I haven’t played some – most, actually – of the games on that list) that some of the failures mentioned in the first part can’t be explained by the contents of the second part, even though they are so vague as to be stretched almost to infinity. And really, is “had no market for it” (as with Auto Assault) a design flaw?
Scott is an intelligent and lively writer, but I think he dropped the ball on this one. I’m not sure why, but I would have liked to see him discuss some recent or ongoing failures (according to him), except Aion, which is, as we all know, perfect.
I’m sorry if everyone is disappointed but I’m not going to point fingers any more so than I did in the first part. I don’t think a chart describing “OK, the following games fell down in viewing themselves as a service: X, Y, Z” would benefit anyone save people who like pointing at car wrecks (admittedly, that group is a large list).
I’ve said it a couple of times on this blog and I say it again: I disagree that “your team will have to come up with everything from scratch” , the technology is there, people just don’t know, they prefer to burn their money on Gamebryo.
@Vetarnias: mainly that you are completely dependent on human players to run any type of voyage. this means if you’re wanting to do a less popular activity like pillaging on viridian server (where atlantis voyages are king) it can be very difficult to load anything larger than a sloop successfully. or to run any type of voyage in the non-peak hours. its not uncommon for players to spend more than 4 hours trying to load a flotilla or an atlantis voyage. additionally alot of the players are unreliable and will leave the ship in the middle of a battle, increasing the potential of the battle navigator getting shafted. there was a fairly long thread in the pp game design forum of people asking for skilled bots to at least reduce reliance on human jobbers, but it seems to have fallen on deaf ears.
Perhaps you consider adding specific examples as “pointing at car wrecks” (and, given where that article was published, you are probably right in fearing that it will be viewed as such and consequently enjoyed for the number of dead bodies it leaves in its wake), but I would rather see the use of specific examples as a more clinical process, in this case an autopsy or something close to it. The purpose isn’t so much to poke fun at their failures, but to learn from them. Perhaps the average MMORPG.com reader isn’t interested in that, so I understand your restraint, but I think it would have made for a superior article if you had attached specific games for each of your parts.
@ethereal.wolf
I was on Hunter, and it was fast becoming the same thing when I left. As a so-so battle navigator, I had given up on trying to hold pillages, even on a sloop (not to mention that I rarely if ever broke even), because it was impossible to find someone who would stay after even one defeat; I was much better off selling my services as a sailor to others, but it gets tiresome after a while. By the time I quit the game, we had decided to call our small flag “Instant Gratification” out of desperation at this very problem.
I’m not sure that adding bots would be the solution to that, though. Sounds more like skirting the problem and removing one of the “MMO” aspects of Puzzle Pirates in the process.
In the case of “scope”, though, I get the exact opposite problem: I can’t think of a single example that would fit here. The entire lesson seems to be: “if you’re a garage-league studio, don’t try to make World of Warcraft”. Except that the most egregious example of WoW copycatting I can think of was Warhammer Online, and that its problem was not exactly scope.
[/quote]
Oh it was definitely scope. WAR tried to be all things to all people. They wanted to be the bestest PvE raiding game ever, and the bestest PvP game ever, at the same time. Essentially they tried to be WoW, and then take that a step further by including a meaningful world PvP and robust guild system to the mix. What they wound up with is a game that advanced the genre in some ways and failed deliver what people expected in other areas. PvE content was sparse and untested. Crafting was a skeleton that would have been better of not even included in the launch of the game. World PvP– well, the technology just couldn’t handle it, and they didn’t have a graceful fall back position.
If their scope had been more focused, if that hadn’t forced themselves to pull together all of these unrelated elements at the last minute, if they’d been able to focus on the one thing they had that they could knock out of the park (organized world PvP), the game might have launched with fewer initial sales, but with a lot more retained subs.
@vetarnias: there was some excellent discussion in the extra swabbies thread about how enabling more autonomy does not necessarily reduce socialization. i also think clinging to rigid ideas of what an “mmo” should be is the reason the problem continues to fester and hasn’t been properly fixed. even a reduction to partial dependance on humans is better than the complete dependance they have now. as you pointed out yourself, the current arrangement makes for a shitty game experience.
I preferred this article to the first part. The first part was a short look at why a number of MMOs failed and ultimately I don’t think that short look really provided enough insight into what went wrong. However, it’s a popular article because the MMORPG.com forums got to go, “Yeah, devs suck! Epic fail lolcats!”.
Part two is a “here’s why things don’t work out” article and is much smarter for not just pointing and yelling, “Yeah, devs suck!”. It’s about the process behind the development of a MMO in a market where players want you to promise them the earth but the scream and carry on when things aren’t delivered exactly as they appear in their head. Or about how easy it is for a game designer to come up with a cool-sounding idea that becomes a development nightmare (or, worse, just doesn’t quite work out).
[If mentioning the gritty details requires the omniescence mortal existence lacks] Then why bother mentioning the examples of failure in the first article? As you’ll remember, this was a two-part series, which implies some sort of connection, and the conclusion of the first article was “Conclusions, And How To Fix All Of This Mess.”
What you are objecting to is the means Lum went about it. You wanted him to take each given example and point out how he would have done this or that differently. Instead, he chose give the general reasons that would have brought about each flaw.
I can imagine several good reasons why he chose the later approach over the former besides that (as he said) pointing at carwrecks isn’t particularly productive. For example, because hindsight is 20/20 and it’s somewhat unscrupulous to claim you would have been able to learn from these mistakes before they were made.
As it is, I’m going to try and do it myself, and I’m going to fail, which further leads me to question how the two articles are related:
You can only blame yourself there. Because the approach chosen by Lum here was to go for the abstract reasons why mistakes are typically made, I can actually look at many of your examples where you wrote “No?” and come up with many, many examples of how those reasons could apply to each.
For example:
Hellgate: London
Problem: Wanted to charge like an MMO without being one
Failed due to:
Scope: By definition, yes. Considering their chosen scope was incompatible with the MMORPg that the wanted to be. If they had decided upon this scope originally and planned appropriately, they likely would have reached that goal.
Tech: Of course, one of the main reasons why Hellgate: London failed was because their tech was not quite up to the task of providing the experience that players would have interpretted as an MMORPG. Flagship learned the hard way that the demand behind a MMORPG is hard – at least hard-enough that you can’t easily shoehorn your 3D Diablo into being one. The heavily instanced compromise did not satsify.
Customer Service: It’s interesting to consider that, from the start, the players were telling Flagship that they were not particularly interested in seeing a subscription fee applied to the game in any form. Who, might you wonder, is responsible for disseminating the information from their userbase in time?
Fun: Of course, as almost anyone who has actually purchased Hellgate would tell you, the main reason why they’re not still playing it was because the game was a badly balanced travesty. They were tweaking and tweaking all the way up until the end, but they did not realize one important thing. The fun, stupid. It seems that, like an article you my have recently read would have warned you, the fun was lost by the sidelines until it was too late to do anything about it. (Those last 9 words being related to scope.)
@Vetarnias
Beyond that, I’m puzzled by Scott’s use of pronouns in the article. “You”, for instance, is aimed not at players, but at developers. Sample: “You will have to convince your stakeholders, your team members, and your prospective players…”.
“You” is a tricky habit that I often fall into as well. It’s common in American dialogue to refer to a hypothetical you in a hypothetical situation (often being described in a “you would have had to have been there” reference to the writer). However, when read, it’s often taken very personally.
I wouldn’t get too hung up on it. I don’t need to prove that the article was intended for the average slub on MMORPG.com to enjoy. This is because this is self-evident by the fact it was posted to MMORPG.com.
You wrote an awful lot of “No?”s for things that had valid Yes’s, even YESS!!!’s. Auto Assault was considered fun? Doesn’t your given problem for Hellgate point directly to a scope problem? (“Wanted to charge like an MMO without being one” sounds very much like a scope problem.) Ultima Online “failed”? It sure lasted a while! Isn’t SWG fundamentally changing the universe’s mechanics a simultaneous scope change and fun-source change, which would jar anyone used to the old fun-source and scope? And weren’t there many complaints about bugs in SWG?
Or did you frame those as each having only one problem, and asking whether that one problem you chose fit the categories given? Because I’m sure there’s was more than one problem for each.
geldonyetich :
What you are objecting to is the means Lum went about it. You wanted him to take each given example and point out how he would have done this or that differently. Instead, he chose give the general reasons that would have brought about each flaw.
No, I didn’t, and no, he didn’t. I don’t want him to say what he would have done differently, I want him to point out where it went wrong. “EQ’s 72 hour wait queues for bosses is a failure of fun. Had the developers actually tried playing through such encounters on a real server populated by lots of people where they’re just another face in the crowd and not someone with debugging powers, they would have found it a bit less fun.” He did choose to give general reasons, but I’m having a hard time connecting them to the examples he gave in the first part, and, as the author, I think he should have done that for us, and not left it to us to guess.
Further, I disagree with Scott in that I don’t think that saying “this failed because it wasn’t fun” is pointing fingers. I think it’s illustrating your point with a concrete example, and I think that’s always helpful in making your case. To be fair, I don’t know who designed EQ, and they don’t know me, so I’m not really even capable of pointing fingers or offending people (anymore than some random guy on the internet screaming “you suck!” can offend a designer). Maybe I would feel differently if I were in the industry and could actually piss people off and burn some bridges.
Also, I love charts. And video game car-wrecks.
You can only blame yourself there. Because the approach chosen by Lum here was to go for the abstract reasons why mistakes are typically made, I can actually look at many of your examples where you wrote “No?” and come up with many, many examples of how those reasons could apply to each.
No, I can blame Scott – and I did. When you’re writing a paper on what is broken and why, it is standard procedure to connect the two.
Regarding your example of Hellgate, I completely disagree with your scope reasoning. They didn’t want to be an MMORPG, and they weren’t trying to be. They just wanted to charge like one. They weren’t a victim of scope creep or scope failure in general. As far as tech, the “failure” that Scott sited in the article (not one that you think the game had, because that’s not what we’re arguing) was charging like an MMORPG without being one. That’s not a tech issue. Your customer service issue I might buy. And again, your fun issue addresses what you think is wrong with the game, not what Scott pointed out as the failure in article 1.
My whole point is: don’t leave me to guess at what you meant – say it!
Guy :
Or did you frame those as each having only one problem, and asking whether that one problem you chose fit the categories given? Because I’m sure there’s was more than one problem for each.
This is really the same thing that I just mentioned to Geldon, but yes, I’m framing them as each having one particular “failure” (note, that they had a failure, not that they failed, which is a crucial distinction that many commenters on MMORPG.com failed to make in article 1, as EQ and UO certainly didn’t fail) because that’s what Scott did in the original article. As per one of your points, he didn’t state that Auto Assault wasn’t fun, he stated that it had a very small, strange niche and a poorly defined target market. He didn’t mention the bugs in SWG, he mentioned that they yanked the table cloth out from underneath their existing player base.
“But WHEN it changes, you need to consider how that impacts your milestones and that you adapt your scope through change control to ensure that your project will still be successful.
Project that fail do so because they allow the scope creep without considering the impact on the milestones. And THAT is the real path to failure. Particularly when we are defining success as REACHING those milestones.”
Projects that fail are just making the wrong choices sometime about scope but there are many issues at play. Obvious the path of choices here is not easy. If milestones are measure of success it is doomed. Choose to disregard what makes up a specific milestone maybe the correct course.
Project change on a daily basis and everything has to be able to response. Team roles, features, tech, process, milestone, resources, dates, etc. There are more than enough constrains in large software projects adding in SCOPE, CHANGE CONTROL, and MILESTONES could be constrains that lead to failure or success. They are just tools that may or may not help.
We live in the world of dev writing code in the morning and customers having it in the afternoon with huge global systems. How ones builds, deploys, distributes software is a feature of that software. MMOs still have yet to design that feature well into their games. At least some have down to months or weeks.
I’m planning a car trip from Seattle to New York. I need to be there in 7 days.
My planned route takes me through the Dakotas and the Midwest. A few hours into my drive, I decide that I want to stop at Mt. Rushmore.
It’s not on my planned route, but I have enough flexibility in my schedule that I can make the adjustment and still get to New York in 7 days.
I couldn’t, say, suddenly decide I wanted to go stop at Dallas, Texas. Not if I wanted to reach New York in 7 days for that job.
MMO devs do the equivalent of deciding to stop in Dallas and then end the trip in Kentucky because they couldn’t make it all the way to New York.
Flexibility is all well and good but at some point you need to a) have a plan and b) stick to that plan.
Our milestones are the baby goals along that path. Areas where we can check in and assess how we are performing against that plan.
If the plan is not going well, then obviously you are going to need to adapt. But that doesn’t detract from the virtue of having that plan in the first place.
No, I didn’t, and no, he didn’t. I don’t want him to say what he would have done differently, I want him to point out where it went wrong.
Not an undertaking I’d be in a hurry to undergo. MMORPGs were epic endeavors involving hundreds of thousands of players. With this, there are hundreds of thousands of perspectives of perceived faults. I wouldn’t pretend I could cataloger every imagined sleight.
On the other hand, if you just wanted the quick and dirty breakdown of the larger flaws in the game, I’m pretty sure that’s what his first article did already. It would seem you simply wanted him to repeat himself.
Maybe you should try writing your own “here’s how I’d fix what was wrong with the games I wrote about” document from the perspective of Lum’s first document and see if you end up with something all that different.
Regarding your example of Hellgate, I completely disagree with your scope reasoning. They didn’t want to be an MMORPG, and they weren’t trying to be. They just wanted to charge like one.
Work with me a little here. Is it really that hard for you to connect that reason why they couldn’t get away with charging to be an MMORPG is because the necessary features to be considered an MMORPG were not in their choice of scope? That’s what I wrote, I just assumed you could make that leap.
No, from your very first comment, your mind has been in “find something to disagree with” mode. I’ve been there. It’s not hard to find something to do disagree with until the end of time, but it requires a suspension of your attempt to truly understand what was written.
geldonyetich :
Not an undertaking I’d be in a hurry to undergo. MMORPGs were epic endeavors involving hundreds of thousands of players. With this, there are hundreds of thousands of perspectives of perceived faults. I wouldn’t pretend I could cataloger every imagined sleight.
You’re either not reading what I write, or not understanding it. I don’t want a laundry list of everything that every player thought was wrong with EQ. I want the two articles connected. I want the problem (singular) pointed out in article 1 (in the case of EQ, 72 hour timers on bosses, to be concise) linked with the causes of failure in article 2.
Maybe you should try writing your own “here’s how I’d fix what was wrong with the games I wrote about” document from the perspective of Lum’s first document and see if you end up with something all that different.
Again, this is not about “here’s how I would fix it.” This is about connecting the two articles. Column A lists a game and a specific failure. Column B lists four causes of failure in MMORPGs. Draw lines between the two where relevant, with the necessary explanation to make those lines make sense.
Work with me a little here. Is it really that hard for you to connect that reason why they couldn’t get away with charging to be an MMORPG is because the necessary features to be considered an MMORPG were not in their choice of scope? That’s what I wrote, I just assumed you could make that leap.
No, I can’t make that leap, because I don’t agree with it. Again, you’re not listening to me. One of our four items in Column B was “Failure due to not keeping scope in check.” What you’re saying is more like “Failure due to not keeping pricing in check relative to scope.” They both touch on scope, but they are, in fact, different things.
No, from your very first comment, your mind has been in “find something to disagree with” mode. I’ve been there. It’s not hard to find something to do disagree with until the end of time, but it requires a suspension of your attempt to truly understand what was written.
The irony, it smells like melted glue and slightly overcooked pancakes. I understand the two articles. I don’t think they were adequately linked. I understand that you think that Hellgate’s failure was attributable to scope. I disagree, to the extent that I don’t think it was attributable to the kind of scope problems that Scott mentioned in his second article, which leads us back to the sentence two periods prior to this one. Addressing the irony, I think it’s you who is having difficulty understanding what is written. I’m not. Scott understood what I was bitching about, and disagreed (and I disagree with his disagreement). Fine. That’s gravy. You and I are not disagreeing – you’re failing to understand me, and trying to tell me I’m wrong because of things I never said.
You and I are not disagreeing – you’re failing to understand me, and trying to tell me I’m wrong because of things I never said.
Well, it seems I have at least provoked you into the identical mindset I usually have when I approach forums these days. I suppose that’s an agreement of sorts.
However, for somebody who is not disagreeing with me, you certainly seem to be stating to the contrary a lot.
You’re either not reading what I write, or not understanding it. I don’t want a laundry list of everything that every player thought was wrong with EQ. I want the two articles connected. I want the problem (singular) pointed out in article 1 (in the case of EQ, 72 hour timers on bosses, to be concise) linked with the causes of failure in article 2.
In any case, I suspect we’ve come to the point where we can refer to our previous messages for our answers.
I don’t want a laundry list of everything that every player thought was wrong with EQ. I want the two articles connected. I want the problem (singular) pointed out in article 1 (in the case of EQ, 72 hour timers on bosses, to be concise) linked with the causes of failure in article 2.
What you are objecting to is the means Lum went about it. You wanted him to take each given example and point out how he would have done this or that differently. Instead, he chose give the general reasons that would have brought about each flaw.
This is really the same thing that I just mentioned to Geldon, but yes, I’m framing them as each having one particular “failure” (note, that they had a failure, not that they failed, which is a crucial distinction that many commenters on MMORPG.com failed to make in article 1, as EQ and UO certainly didn’t fail) because that’s what Scott did in the original article.
Part of the problem might be that Scott’s choice of examples in the first part included examples of both failures that were later overcome by the game’s developers and fatal mistakes that quickly sank the game. Sure, it’s all in hindsight, but so are all postmortems, their implicit purpose being to prevent the same situation from happening again.
Everquest’s 72-hour quest obviously didn’t kill the game, while the cause of Auto Assault’s failure was in its market-less premise, not any specific design. Some posters didn’t make the distinction between the two (a specific failure in a game, and a failed game), because the collection, while it cites classic examples, is too eclectic, and sometimes it’s not too clear what the lesson was (which might explain the general approach to part 2). When a seemingly ordinary failure in design is cited for a game anyone with a cursory interest in MMO’s knows has failed, why shouldn’t we think that it was this specific failure which killed it?
Yet at first glance, I can’t see, from part 1, why AC2 died and EQ2 endured, as both mistakes cited were corrected before the game died. This would imply an intangible aspect beyond the initial mistake that explains why a game with a disastrous launch like Anarchy Online (which isn’t in the part 1 examples, even though it would be an ideal example for the tech section of part 2) managed to recover, while other games that launched without many glitches sank.
Perhaps it is impossible to draw a lesson from the failures of part 1, partly because the context is essential (and varies wildly), and also because we cannot isolate this particular failure from other failures game X may have had, especially if other failures included such subjective-yet-essential considerations as fun.
I’m drawn back to that old debate on this blog over Zitron’s review of Darkfall, and how part of the debate was overtaken by a discussion of design versus fun. If it’s fun, is the bad design excused? Why should a reviewer’s sense of “fun” take precedence over a gamer’s sense of “fun”? If you want an example of such a subjective consideration, just look at Scott’s assessment of Tabula Rasa — in one word, the cause of its failure was “meh”. I can’t disagree with him, as I didn’t play TR, but now try to draw a lesson from it: “Don’t make boring games”? Perhaps that’s why part 2 ended up like it is — because the drawing of lessons is a treacherous game to play, even in hindsight. Might as well give the MMORPG.com crowd its panem et circenses, then.
[quote]No, I can’t make that leap, because I don’t agree with it. Again, you’re not listening to me. One of our four items in Column B was “Failure due to not keeping scope in check.” What you’re saying is more like “Failure due to not keeping pricing in check relative to scope.” They both touch on scope, but they are, in fact, different things.[/quote]
Technically, scope is inclusive of everything but in the context of these articles, you are right.
I would argue that any ‘pricing’ dispute is really more of a reflection on “Service” in that it’s a customer relations issue.
The four areas that Scott lists (Scope, Technical, Design, Service) are VERY broad areas in which just about any failure could be defined.
I think part of your problem is that you are more narrowly defining these categories than Scott.
Isn’t saying that a game has too small a niche or market the same as saying it’s not enough fun for enough people? These are issues that blend into one another.
Isn’t saying that a game has too small a niche or market the same as saying it’s not enough fun for enough people? These are issues that blend into one another.
There’s a slight difference. A game might be fun (meaning: enjoyable to play) for a lot of people, but if it has a very niche market, very few will actually try it.
Alright. That doesn’t really sound like what happened with Auto Assault, though. For instance: I heard a “Car Wars”-ish or “Deathtrack”-ish game was being made called Auto Assault, and got excited. Sounds like I was the niche. But then I heard it wasn’t fun. So I didn’t try it.
While there’s a difference, niche and fun aren’t exclusive categories.
In Auto Assault’s case, they had a shot at a whole new niche. It’s not like there’s a whole lot of car war MMORPG alternatives.
However, the bottom line of any game is that games are entertainment. If a game isn’t fun, don’t expect people to hang around.
You could get away with just selling a brand slapped on a crappy game if you’re just selling to ride the box sales. For example, the average movie tie in game. However, a MMORPG with a monthly subscription model require longevity to survive.
Not that selling crap to a starved niche was their goal. I was in Auto Assault beta towards the last few months. There was a reason why scope was at the head of Lum’s list. They simply ran out of time finish the game. It happens to most MMORPGs, really – that lack of polish can kill the fun. WoW finished their game a year before it was released, and spent the rest of the time just polishing.
Guy :Isn’t saying that a game has too small a niche or market the same as saying it’s not enough fun for enough people? These are issues that blend into one another.
Sort of – niche games are fun for a relatively small set of players. Generally speaking, the designers know that going in and build both the game (to appeal as much as possible to that niche) and the business plan accordingly.
Bad games want to be fun, but fail at it. They don’t appeal to the people the designers wanted them to. You can have a bad mass market game (Age of Conan and Warhammer are prime candidates here) and you can have bad niche games (back to Auto Assault). Sure, you get some outliers who like the game but there just aren’t enough of them to keep the servers open – most of the target market have said “meh” and walked away.
This is IT project management 101 material. Do people in your industry really not understand how critical scope control is to a successful project? Have you thought about outsourcing project management to people who do this for a living?
A good PMO will make your job easier, not harder – that’s how you tell the good ones from the bad ones. If all your developers hate the project manager, or all he does is ask for status and adds no value, then he’s a bad one.
The second half of the article reads like an Agile primer. Tackle big projects in small bites, get user feedback early and often, and use that feedback to modify your design concepts.
Do people in your industry really not understand how critical scope control is to a successful project? Have you thought about outsourcing project management to people who do this for a living?
It’d say it’s less that game developers don’t understand scope control so much as because game developers are producing a game.
When developing most software, you have a task that the software must perform and set about breaking that task down into a workable design to realize in a functional program.
Games are a very unusual software to develop in that the sale task that the software must perform is “be entertaining,” and there are an infinite number of ways to realize this.
Scope becomes lost quickly because you’ll never know if your game has succeeded in its goal until you’re relatively close to fruition of a complete product. Further, there’s no real limit to just how much enjoyable you can attempt to capture, given adequate time in resources.
What you invariably end up with is an endless development cycle, continue to refine and improve. At first, hoping to eventually realize an enjoyable result. Then, hoping to improve that result to the point where it’s highly competitive.
MMORPGs have it extra hard because they need to be more than entertaining for a few seconds. They need to entertain for months – at least so long as a monthly subscription model is the goal.
“Games are a very unusual software to develop in that the sale task that the software must perform is “be entertaining,” and there are an infinite number of ways to realize this.”
All software is unique. This has been solved before computers were created. There are an infinite number of ways to build a house or a bridge across a river. The same applies to software such as games.
“Scope becomes lost quickly because you’ll never know if your game has succeeded in its goal until you’re relatively close to fruition of a complete product.”
Why? If the length of time between building something and know it meets the goal is “long”. That is the problem, not the goal or what was built.
“What you invariably end up with is an endless development cycle, continue to refine and improve.”
You say that like it is bad. Endless development cycle means a product is successful with version 1, 2, 3, etc and a good feedback loop addressing your customers needs. Refining and improving is what building solutions is all about. The problem that occurs for some is that progress is measured in years or months while others do it in weeks, days, hours.
UnsGub :
“What you invariably end up with is an endless development cycle, continue to refine and improve.”
You say that like it is bad. Endless development cycle means a product is successful with version 1, 2, 3, etc and a good feedback loop addressing your customers needs. Refining and improving is what building solutions is all about. The problem that occurs for some is that progress is measured in years or months while others do it in weeks, days, hours.
The reason it’s bad is that you need a ‘point’ at which you release the product and the ‘refining and improving’ is done through the program management of patches and expansions.
You’ll never get to that ‘point’ if you don’t have a clear set of achievable goals for that release. That’s why scope control is important.
As someone posted WAY back, it’s all Project Management 101. The whole purpose of which is to mitigate risk and manage to a budget/timeline.
Believe it or not, the cheapest part in designing any project are the ideas. It costs you very little to ‘think stuff up’ but it costs you dearly to start implementing those ideas. So ‘thinking stuff up’ along the way is a necessary evil and one that you need to plan for by gaining feedback early.
My only quibble would be to differentiate short term success from long term success.
Everquest for example, generated excellent returns for its investors and ruled for at least 5 years. The initial design was very solid, its demise was being unwilling/unable to adapt to a competitor that dumbed down the concept in order to attract the masses.
In regards to the point about the game being fun MMO’s are a little unique in the fact that you can’t really listen to your clients about what they want as their goals are very short term.
Ah, I shouldn’t have hit submit comment so quickly, now replying to my replies is going to boost my already copious post ratio. Well, let me at least keep things short, because apparently I’m making some people uncomfortable via sheer verbosity.
I can foresee this debate between “it’s team management 101, stupid” and “it’s a game, stupid” would go on for quite some time. Instead, suffice it to say that there will always be at least these two types of people in software development:
1. Those who are absolutely confident that any problem, no matter how complex and unclear the end goal (e.g. “be entertaining”) can be designed in foresight, and thereby completely eliminate any possible threat to their scope.
2. Those who never bother to even try to set a scope because they figure they know exactly what they’re creating in their head and therefore can wing it without working out the details ahead of time.
Both parties are dead wrong and equally deserve the misery that comes their way.
And then there’s the third approach, famously epitomized by William Goldman: Nobody knows anything. Every decision is a crapshoot that could either work or fail, based on little more than chance. You can’t derive a clear lesson from it, because it could fail to apply in your case, even if you followed the most prudent course, and it would be difficult to see why.
In a nutshell: We’re all groping in the dark, whether we want to admit it or not.
geldonyetich :
Ah, I shouldn’t have hit submit comment so quickly, now replying to my replies is going to boost my already copious post ratio.
1. Those who are absolutely confident that any problem, no matter how complex and unclear the end goal (e.g. “be entertaining”) can be designed in foresight, and thereby completely eliminate any possible threat to their scope.
You misunderstand. Project management is about planning, true, but that doesn’t mean you believe that all things can be designed in foresight.
Quite the opposite really. That’s why a good project plan includes a risk mitigation strategy. The biggest risk being that your assumptions are wrong and need to be corrected. That’s why proof-of-concept phases and methods to incorporate feedback are included into any successful plan.
As I wrote earlier, the fact that you may need to ‘course correct’ and be flexible doesn’t diminish the merit in having a plan. Ironically, if anything, it means having a plan that includes a way to handle ‘course corrections’ is even more important.
Vetarnias
In a nutshell: We’re all groping in the dark, whether we want to admit it or not.
Existentialism. Plato’s cave walls. I love it! I do more than grope in the dark, I relish it.
As pertains to game design in this age, that’s uncomfortably closer to the truth than many of us would like to admit. There’s no hard and fast rules to producing awesome. If there was, the diamonds to rough ratio would be a whole lot better.
sid67
You misunderstand. Project management is about planning, true, but that doesn’t mean you believe that all things can be designed in foresight.
Quite the opposite really. That’s why a good project plan includes a risk mitigation strategy.
This is a good method to operate on. But, as pertains to game development, it’s not good enough.
Go back to our original point of contention, you’re saying that you can’t believe that people in this field (game development) seem to have such a hard time with scope, and my answer is that the scope is harder in this field than others.
It’s not that you’re wrong, it’s a difference of severity. If you’re developing a spreadsheet program, you will encounter setbacks – such as usability issues – but they’re a lot easier to deal with than a game.
Let me use an analogy to explain why (and accept the ease of misinterpretation that would go with such an approach). Basically, creating a game is like creating a joke.
In your head, the joke might sound great. You go through all the effort of evaluating your audience, framing the words of that joke right, perfecting your delivery the delivery, ect.
Then comes the moment you decide to tell the joke. How well you told it is a major factor. So also is the mood of the audience at the specific time you told the joke – maybe they’ve heard too many similar jokes lately, or simply aren’t in the mood for that kind of joke.
You won’t know until it’s time to tell your joke just how well it was received. If it’s a complete dud, you’re essentially forced to go completely back to the drawing board. Even if it goes well, you may decide you can tell and even better joke if you tweak it a little more.
However, no amount of risk management can guarantee anyone will ever laugh.
Do comedians tell their jokes for the first time on an HBO special or do they test and refine the jokes over time in small comedy clubs? Even the most successful stand-ups (like Sienfeld) use the comedy clubs to hone their material.
Risk management isn’t about making people laugh, it’s about controlling the risk that they WON’T laugh. And KNOWING in advance whether the joke is funny before stepping onto the big stage is pretty damn important. At the very least, if it’s not funny — you’ll know you need a different joke.
Risk management isn’t about making people laugh, it’s about controlling the risk that they WON’T laugh. And KNOWING in advance whether the joke is funny before stepping onto the big stage is pretty damn important. At the very least, if it’s not funny — you’ll know you need a different joke.
Sure, but here’s the thing:
The “joke” that is a game takes a long time to create, and you really don’t know how good it is until it’s completed enough to tell it. If it fails to entertain, you lose a whole lot of progress.
Remember, the topic at hand here is a scope creep. My whole point being why games have it harder than other software.
about 7 months ago
yeah i like the “play it often” point. i’m encountering the lack of that on the dev’s part in puzzle pirates, areas of content practically unplayable due to design mechanics that fester and never get addressed. areas that are supposed to be “core gameplay”.
about 7 months ago
“…meaningful PvP that shapes the world AND challenging PvE raids AND an incredible beautiful 3D engine AND a unicorn AND crafting AND player housing AND a pony.”
I am stunned that you forgot to include “fetapults” in that list.
Stunned, sir.
about 7 months ago
AND Castles…
Interesting points. Not much left to do now but get someone to actually do that and see how it works out.
about 7 months ago
Definatly, enjoyed the egomaniacal writings! You should do them more often.
Has anyone ever tried doing the planning for an MMO i public? Maybe we can make an ‘MMO Tycoon’ game of making a game… set the time / budget constraints and see what we can reasonably fit in there.
Who knows, maybe it would be educational to the players and the dev teams at the same time.
Yeah, right! More like “design by committee” and that almost never works.
about 7 months ago
@Gaidin6 The trouble is that the victory conditions for an MMO Tycoon are very different depending on whether you’re playing as lead designer, venture capitalist, or community guy, for example…
about 7 months ago
Don’t need to fix everything, but you could fix the lag in Aion. It’s a bit silly to have 5-10s lag spikes and pings up to 800ms.
Being able to drop a petition 24/7 would be good too.
I think this is a pretty realistic scope.
about 7 months ago
Though I was planning on critiquing, these suggestions are just abstract enough to be beyond critique. Congrats, I cannot refute you’ve fixed everything – other than the devil being in the details and the details being avoided through a wise choice of scope of the document.
about 7 months ago
“Scope” definitely would be the over all theme for the failure of WAR, in my opinion.
They had the opportunity to make a kick ass world PvP driven game, and instead they wasted a huge portion of their resources on dungeons and raids that aren’t part of that scope.
Failure to understand that you can’t launch a better version of WoW when you have a fraction of the budget for WoW is failure.
about 7 months ago
@ibn I assume you realize I was being sarcastic with the “MMO Tycoon” idea BUT figured you’d be the lead designer and the others you mentioned would be obstacles to overcome (venture capitalist wanting the game out the door, community guy wanting the next great game mechanic or more zones, etc.).
In reality I was just wondering if there would be any value to anyone to design “a game” in public (like on MMORPG.COM). People could see that mundane tasks like “Build Server Infrastructure” took 3 – 6 months (or whatever it takes), let alone nailing down ethereal ideas like setting or game mechanics.
Harlan Ellison did an experiment in the mid-70′s at UCLA where he explored the concept of a shared world with some of the best sci-fi writers of the time (the book, titled Medea: Harlan’s World was the result).
I thought something like this might be an interesting experiment, too, since everyone seems to think they can design games better than the folks actually doing it.
Again, not sure how much fun it would be, especially for guys like Lum who does this stuff for a living, but figured it might be a way to show the masses (trolls? can the be taught?) that this stuff is hard. Maybe he could use it as fodder for “LFoL” Parts 3 to 10!
about 7 months ago
“A game that fails due to over-ambition is still better than one that fails because it’s [...] committee-designed sludge…”
- Yahtzee, this week’s review of Dark Void
about 7 months ago
Hey Lum, I agree with what you said.
about 7 months ago
Great read! One can feel the experience that is behind each of these admonitions – and the parts that you left unsaid for good reasons
.
about 7 months ago
I don’t think the average MMO player really knows or cares about the reasons why so many games fail – they just want to have fun. So, while the effort to educate them as to why these failures happen is laudable, it’s ultimately not going to be too successful.
And, reading the as someone who’s been working on MMOs for more than a decade, it’s kind of like it was authored by Captain Obvious. That’s no surprise, and not meant as an insult either – I’ve just been there, done that, and have the t-shirts to prove it.
Maybe it will help some aspiring developer and they won’t fall into some of those particular traps. Although, you’d have to be certifiably crazy to want to make an MMO, if you really knew what it was like. Nothing like spending 5+ years of your life on a product that gets shut down after about a year of live service. Feels great!
about 7 months ago
@ethereal.wolf
I wonder which elements of PP you are referring to, exactly. I know they added some features after I left, but it didn’t solve any of my particular concerns with that game. I wonder if we’re thinking about the same things.
@Vaxhacker and Geldon
I’m not a designer, but even as just an ordinary player I found some of Scott’s points this week definitely ventured in Captain Obvious territory. I don’t think there is a single developer who would disagree with his points, but whether what that developer is doing is running afoul of what Scott wrote. And the bean-counters on top of them just don’t bother with such considerations to begin with; they would sooner have a bad game that makes gazillions of dollars than a revolutionary one that fails.
What also didn’t help is that despite the contents of the first article, I see little that could connect part two to part one. Part one gave specific examples of MMO failure, brief, concise, almost bullet-point, all condensed to fit into a single article, but you saw what he was getting to. Part two, on the other hand, never so much as mentions a single game to serve as an example of the various points. In some places, like that section on technology, you can easily fill in the blanks: Inadequate server capacity gets you Darkfall at launch, “hubris” should get a portrait of Gaute Godager or Paul Barnett. Why not mention Gaute’s “steak” remark, then?
In the case of “scope”, though, I get the exact opposite problem: I can’t think of a single example that would fit here. The entire lesson seems to be: “if you’re a garage-league studio, don’t try to make World of Warcraft”. Except that the most egregious example of WoW copycatting I can think of was Warhammer Online, and that its problem was not exactly scope. And the other example I can think of, Age of Conan, actually pulled it off as far as the scope was concerned, though it didn’t seem to be that way at launch. So that entire section on scope would have been improved with some examples.
What’s interesting is that there is now another MMORPG.com article that details some of those annoying things in MMO’s that developers just can’t get rid of, even though we’re sick of them. That whole “Kill ten rats” and FedEx approach to questing. The Holy Trinity of tank, ranged, healer. Nothing that hasn’t been said before, but that, if left unchecked, may end up killing MMO’s. But here the real problem is that the list amounts more or less to wishful thinking, like eradicating world poverty.
about 7 months ago
[...]As Scott points out, most scoping problems are either related to having unrealistic project goals or deviations from your scope (called scope creep). Realistic goal setting is really a function of experience, so ideally whoever is creating a project plan has the subject matter expertise to lay out achievable milestones.
In my experience as a project manager, scope creep has always been the bigger danger. Over the course of any long project, the scope of that project is likely to change or evolve.[...]
-Serial Ganker
about 6 months ago
If it’s making gazillions of dollars, it’s hard to characterise a game as “bad” – by definition, there would be a lot of people who think it’s “good” enough to part with their money for. It might be a “dumbed down, mass market” game, it might not be the game YOU want to play, but a game that is providing a lot of people with entertainment that they manifestly enjoy is doing just what a game should be – so how is it a “bad” game?
Contrariwise – if a game is a dull, unplayable POS that makes me wish I’d spent the last few hours helping my girlfriend with her clothes shopping instead – that’s a bad game. I don’t care how noble the developer’s intentions were to create the next step in the evolution of MMOs, the result should be something that I enjoy playing.
about 6 months ago
“Part two, on the other hand, never so much as mentions a single game to serve as an example of the various points.”
No need to be specific with examples. Any large software project deals with these issues on a daily bases some successfully and some not.
“so ideally whoever is creating a project plan has the subject matter expertise to lay out achievable milestones.”
This is the path to failure. One person, even everyone in the end, does not have expertise to layout milestones for a team. Everyone is going to hit unknowns usually on discovered when they are doing the actual work. Your process has to handle these common issues if you are going to be able to release a known product to your customers.
about 6 months ago
The tricky thing about game development is that, in attempting to push the envelope, what was previously Captain Obvious territory rapidly becomes a forgotten prologue. Even a pipe dream atop all the other demands you attempt to meet.
As I said, Lum’s article was relatively irrefutably correct via abstraction/choice of scope. He didn’t get into the gritty details, just laid down the easily forgotten guidelines. He had some good reasons for this:
First, because the gritty details will vary heavily from project to project, and nobody has the necessary omniscience to imagine every little individuality.
Second, because this is an article on MMORPG.com, not a comprehensive designer website. He’s explaining things that might be useful for a newbie designer, but are primarily aimed at MMORPG players who want to know where things went wrong.
So, yes, I could point out there are obvious shortcomings to the message, but this would be very shortsighted of me: looking deeper, it was a good choice of document depth.
about 6 months ago
@UnsGub
You missed the point — which is to have clearly defined and ACHIEVABLE milestones.
Your scope is going to change, no doubt about it. But WHEN it changes, you need to consider how that impacts your milestones and that you adapt your scope through change control to ensure that your project will still be successful.
Project that fail do so because they allow the scope creep without considering the impact on the milestones. And THAT is the real path to failure. Particularly when we are defining success as REACHING those milestones.
about 6 months ago
I sure hope I don’t completely ruin the tags on this post. Preview? Edit?
That’s an [i]un[/i]reason. If any large development project runs into these problems regularly, and there’s no need for examples because everyone is familiar with them, why even bother writing the article?
about 6 months ago
Sigh.
about 6 months ago
@Tremayne
The distinction is perhaps more difficult to make for video games – if you have fun, you have fun. Compare that to movies: James Cameron still can’t write a screenplay, and Avatar, $600 million later, will inevitably win for Best Picture. The problem is that I’m constantly having run-ins with WoW fanboys who insist that WoW is teh bestest game of all time, in everything, because it has 11 million players to prove it. Any criticism is futile, because if it were bad, it wouldn’t be played.
@Geldon
I see what you mean, though I don’t think it will change much for MMORPG players. You know they will complain nonetheless at the next game, and may even look upon Scott’s article as an excuse for developers.
Beyond that, I’m puzzled by Scott’s use of pronouns in the article. “You”, for instance, is aimed not at players, but at developers. Sample: “You will have to convince your stakeholders, your team members, and your prospective players…”. Players themselves are referred to in the third person, even though they are assumed to be the intended readers. I suspect it’s a style decision to make player-readers feel they are eavesdropping on a confidential discussion between two developers; but you need something confidential being said to maintain the illusion. If Donald Trump were giving financial advice to a (nonexistent, purely for narrative purposes) business rookie in front of a middle-class audience, wouldn’t you expect something a little less obvious than “buy low, sell high”?
Furthermore, Cymbaline’s post also demonstrated (I’ll have to rely on her judgement, as I haven’t played some – most, actually – of the games on that list) that some of the failures mentioned in the first part can’t be explained by the contents of the second part, even though they are so vague as to be stretched almost to infinity. And really, is “had no market for it” (as with Auto Assault) a design flaw?
Scott is an intelligent and lively writer, but I think he dropped the ball on this one. I’m not sure why, but I would have liked to see him discuss some recent or ongoing failures (according to him), except Aion, which is, as we all know, perfect.
about 6 months ago
I’m sorry if everyone is disappointed but I’m not going to point fingers any more so than I did in the first part. I don’t think a chart describing “OK, the following games fell down in viewing themselves as a service: X, Y, Z” would benefit anyone save people who like pointing at car wrecks (admittedly, that group is a large list).
about 6 months ago
I’ve said it a couple of times on this blog and I say it again: I disagree that “your team will have to come up with everything from scratch” , the technology is there, people just don’t know, they prefer to burn their money on Gamebryo.
about 6 months ago
@Vetarnias: mainly that you are completely dependent on human players to run any type of voyage. this means if you’re wanting to do a less popular activity like pillaging on viridian server (where atlantis voyages are king) it can be very difficult to load anything larger than a sloop successfully. or to run any type of voyage in the non-peak hours. its not uncommon for players to spend more than 4 hours trying to load a flotilla or an atlantis voyage. additionally alot of the players are unreliable and will leave the ship in the middle of a battle, increasing the potential of the battle navigator getting shafted. there was a fairly long thread in the pp game design forum of people asking for skilled bots to at least reduce reliance on human jobbers, but it seems to have fallen on deaf ears.
about 6 months ago
@Scott Jennings
Perhaps you consider adding specific examples as “pointing at car wrecks” (and, given where that article was published, you are probably right in fearing that it will be viewed as such and consequently enjoyed for the number of dead bodies it leaves in its wake), but I would rather see the use of specific examples as a more clinical process, in this case an autopsy or something close to it. The purpose isn’t so much to poke fun at their failures, but to learn from them. Perhaps the average MMORPG.com reader isn’t interested in that, so I understand your restraint, but I think it would have made for a superior article if you had attached specific games for each of your parts.
@ethereal.wolf
I was on Hunter, and it was fast becoming the same thing when I left. As a so-so battle navigator, I had given up on trying to hold pillages, even on a sloop (not to mention that I rarely if ever broke even), because it was impossible to find someone who would stay after even one defeat; I was much better off selling my services as a sailor to others, but it gets tiresome after a while. By the time I quit the game, we had decided to call our small flag “Instant Gratification” out of desperation at this very problem.
I’m not sure that adding bots would be the solution to that, though. Sounds more like skirting the problem and removing one of the “MMO” aspects of Puzzle Pirates in the process.
about 6 months ago
about 6 months ago
@vetarnias: there was some excellent discussion in the extra swabbies thread about how enabling more autonomy does not necessarily reduce socialization. i also think clinging to rigid ideas of what an “mmo” should be is the reason the problem continues to fester and hasn’t been properly fixed. even a reduction to partial dependance on humans is better than the complete dependance they have now. as you pointed out yourself, the current arrangement makes for a shitty game experience.
about 6 months ago
I preferred this article to the first part. The first part was a short look at why a number of MMOs failed and ultimately I don’t think that short look really provided enough insight into what went wrong. However, it’s a popular article because the MMORPG.com forums got to go, “Yeah, devs suck! Epic fail lolcats!”.
Part two is a “here’s why things don’t work out” article and is much smarter for not just pointing and yelling, “Yeah, devs suck!”. It’s about the process behind the development of a MMO in a market where players want you to promise them the earth but the scream and carry on when things aren’t delivered exactly as they appear in their head. Or about how easy it is for a game designer to come up with a cool-sounding idea that becomes a development nightmare (or, worse, just doesn’t quite work out).
about 6 months ago
@Cymbaline
What you are objecting to is the means Lum went about it. You wanted him to take each given example and point out how he would have done this or that differently. Instead, he chose give the general reasons that would have brought about each flaw.
I can imagine several good reasons why he chose the later approach over the former besides that (as he said) pointing at carwrecks isn’t particularly productive. For example, because hindsight is 20/20 and it’s somewhat unscrupulous to claim you would have been able to learn from these mistakes before they were made.
You can only blame yourself there. Because the approach chosen by Lum here was to go for the abstract reasons why mistakes are typically made, I can actually look at many of your examples where you wrote “No?” and come up with many, many examples of how those reasons could apply to each.
For example:
@Vetarnias
“You” is a tricky habit that I often fall into as well. It’s common in American dialogue to refer to a hypothetical you in a hypothetical situation (often being described in a “you would have had to have been there” reference to the writer). However, when read, it’s often taken very personally.
I wouldn’t get too hung up on it. I don’t need to prove that the article was intended for the average slub on MMORPG.com to enjoy. This is because this is self-evident by the fact it was posted to MMORPG.com.
about 6 months ago
That article reads like a checklist of ‘reasons you should not try to make an MMO.’
about 6 months ago
@Cymbaline
You wrote an awful lot of “No?”s for things that had valid Yes’s, even YESS!!!’s. Auto Assault was considered fun? Doesn’t your given problem for Hellgate point directly to a scope problem? (“Wanted to charge like an MMO without being one” sounds very much like a scope problem.) Ultima Online “failed”? It sure lasted a while! Isn’t SWG fundamentally changing the universe’s mechanics a simultaneous scope change and fun-source change, which would jar anyone used to the old fun-source and scope? And weren’t there many complaints about bugs in SWG?
Or did you frame those as each having only one problem, and asking whether that one problem you chose fit the categories given? Because I’m sure there’s was more than one problem for each.
about 6 months ago
Heh – it’s funny how many of my experiments with game development generated data that felt that way.
about 6 months ago
No, I didn’t, and no, he didn’t. I don’t want him to say what he would have done differently, I want him to point out where it went wrong. “EQ’s 72 hour wait queues for bosses is a failure of fun. Had the developers actually tried playing through such encounters on a real server populated by lots of people where they’re just another face in the crowd and not someone with debugging powers, they would have found it a bit less fun.” He did choose to give general reasons, but I’m having a hard time connecting them to the examples he gave in the first part, and, as the author, I think he should have done that for us, and not left it to us to guess.
Further, I disagree with Scott in that I don’t think that saying “this failed because it wasn’t fun” is pointing fingers. I think it’s illustrating your point with a concrete example, and I think that’s always helpful in making your case. To be fair, I don’t know who designed EQ, and they don’t know me, so I’m not really even capable of pointing fingers or offending people (anymore than some random guy on the internet screaming “you suck!” can offend a designer). Maybe I would feel differently if I were in the industry and could actually piss people off and burn some bridges.
Also, I love charts. And video game car-wrecks.
No, I can blame Scott – and I did. When you’re writing a paper on what is broken and why, it is standard procedure to connect the two.
Regarding your example of Hellgate, I completely disagree with your scope reasoning. They didn’t want to be an MMORPG, and they weren’t trying to be. They just wanted to charge like one. They weren’t a victim of scope creep or scope failure in general. As far as tech, the “failure” that Scott sited in the article (not one that you think the game had, because that’s not what we’re arguing) was charging like an MMORPG without being one. That’s not a tech issue. Your customer service issue I might buy. And again, your fun issue addresses what you think is wrong with the game, not what Scott pointed out as the failure in article 1.
My whole point is: don’t leave me to guess at what you meant – say it!
This is really the same thing that I just mentioned to Geldon, but yes, I’m framing them as each having one particular “failure” (note, that they had a failure, not that they failed, which is a crucial distinction that many commenters on MMORPG.com failed to make in article 1, as EQ and UO certainly didn’t fail) because that’s what Scott did in the original article. As per one of your points, he didn’t state that Auto Assault wasn’t fun, he stated that it had a very small, strange niche and a poorly defined target market. He didn’t mention the bugs in SWG, he mentioned that they yanked the table cloth out from underneath their existing player base.
about 6 months ago
“But WHEN it changes, you need to consider how that impacts your milestones and that you adapt your scope through change control to ensure that your project will still be successful.
Project that fail do so because they allow the scope creep without considering the impact on the milestones. And THAT is the real path to failure. Particularly when we are defining success as REACHING those milestones.”
Projects that fail are just making the wrong choices sometime about scope but there are many issues at play. Obvious the path of choices here is not easy. If milestones are measure of success it is doomed. Choose to disregard what makes up a specific milestone maybe the correct course.
Project change on a daily basis and everything has to be able to response. Team roles, features, tech, process, milestone, resources, dates, etc. There are more than enough constrains in large software projects adding in SCOPE, CHANGE CONTROL, and MILESTONES could be constrains that lead to failure or success. They are just tools that may or may not help.
We live in the world of dev writing code in the morning and customers having it in the afternoon with huge global systems. How ones builds, deploys, distributes software is a feature of that software. MMOs still have yet to design that feature well into their games. At least some have down to months or weeks.
about 6 months ago
I’m planning a car trip from Seattle to New York. I need to be there in 7 days.
My planned route takes me through the Dakotas and the Midwest. A few hours into my drive, I decide that I want to stop at Mt. Rushmore.
It’s not on my planned route, but I have enough flexibility in my schedule that I can make the adjustment and still get to New York in 7 days.
I couldn’t, say, suddenly decide I wanted to go stop at Dallas, Texas. Not if I wanted to reach New York in 7 days for that job.
MMO devs do the equivalent of deciding to stop in Dallas and then end the trip in Kentucky because they couldn’t make it all the way to New York.
Flexibility is all well and good but at some point you need to a) have a plan and b) stick to that plan.
Our milestones are the baby goals along that path. Areas where we can check in and assess how we are performing against that plan.
If the plan is not going well, then obviously you are going to need to adapt. But that doesn’t detract from the virtue of having that plan in the first place.
about 6 months ago
Not an undertaking I’d be in a hurry to undergo. MMORPGs were epic endeavors involving hundreds of thousands of players. With this, there are hundreds of thousands of perspectives of perceived faults. I wouldn’t pretend I could cataloger every imagined sleight.
On the other hand, if you just wanted the quick and dirty breakdown of the larger flaws in the game, I’m pretty sure that’s what his first article did already. It would seem you simply wanted him to repeat himself.
Maybe you should try writing your own “here’s how I’d fix what was wrong with the games I wrote about” document from the perspective of Lum’s first document and see if you end up with something all that different.
Work with me a little here. Is it really that hard for you to connect that reason why they couldn’t get away with charging to be an MMORPG is because the necessary features to be considered an MMORPG were not in their choice of scope? That’s what I wrote, I just assumed you could make that leap.
No, from your very first comment, your mind has been in “find something to disagree with” mode. I’ve been there. It’s not hard to find something to do disagree with until the end of time, but it requires a suspension of your attempt to truly understand what was written.
about 6 months ago
You’re either not reading what I write, or not understanding it. I don’t want a laundry list of everything that every player thought was wrong with EQ. I want the two articles connected. I want the problem (singular) pointed out in article 1 (in the case of EQ, 72 hour timers on bosses, to be concise) linked with the causes of failure in article 2.
Again, this is not about “here’s how I would fix it.” This is about connecting the two articles. Column A lists a game and a specific failure. Column B lists four causes of failure in MMORPGs. Draw lines between the two where relevant, with the necessary explanation to make those lines make sense.
No, I can’t make that leap, because I don’t agree with it. Again, you’re not listening to me. One of our four items in Column B was “Failure due to not keeping scope in check.” What you’re saying is more like “Failure due to not keeping pricing in check relative to scope.” They both touch on scope, but they are, in fact, different things.
The irony, it smells like melted glue and slightly overcooked pancakes. I understand the two articles. I don’t think they were adequately linked. I understand that you think that Hellgate’s failure was attributable to scope. I disagree, to the extent that I don’t think it was attributable to the kind of scope problems that Scott mentioned in his second article, which leads us back to the sentence two periods prior to this one. Addressing the irony, I think it’s you who is having difficulty understanding what is written. I’m not. Scott understood what I was bitching about, and disagreed (and I disagree with his disagreement). Fine. That’s gravy. You and I are not disagreeing – you’re failing to understand me, and trying to tell me I’m wrong because of things I never said.
about 6 months ago
Well, it seems I have at least provoked you into the identical mindset I usually have when I approach forums these days. I suppose that’s an agreement of sorts.
However, for somebody who is not disagreeing with me, you certainly seem to be stating to the contrary a lot.
In any case, I suspect we’ve come to the point where we can refer to our previous messages for our answers.
about 6 months ago
Sigh..
That second quote was intended to be:
about 6 months ago
@Cymbaline
Part of the problem might be that Scott’s choice of examples in the first part included examples of both failures that were later overcome by the game’s developers and fatal mistakes that quickly sank the game. Sure, it’s all in hindsight, but so are all postmortems, their implicit purpose being to prevent the same situation from happening again.
Everquest’s 72-hour quest obviously didn’t kill the game, while the cause of Auto Assault’s failure was in its market-less premise, not any specific design. Some posters didn’t make the distinction between the two (a specific failure in a game, and a failed game), because the collection, while it cites classic examples, is too eclectic, and sometimes it’s not too clear what the lesson was (which might explain the general approach to part 2). When a seemingly ordinary failure in design is cited for a game anyone with a cursory interest in MMO’s knows has failed, why shouldn’t we think that it was this specific failure which killed it?
Yet at first glance, I can’t see, from part 1, why AC2 died and EQ2 endured, as both mistakes cited were corrected before the game died. This would imply an intangible aspect beyond the initial mistake that explains why a game with a disastrous launch like Anarchy Online (which isn’t in the part 1 examples, even though it would be an ideal example for the tech section of part 2) managed to recover, while other games that launched without many glitches sank.
Perhaps it is impossible to draw a lesson from the failures of part 1, partly because the context is essential (and varies wildly), and also because we cannot isolate this particular failure from other failures game X may have had, especially if other failures included such subjective-yet-essential considerations as fun.
I’m drawn back to that old debate on this blog over Zitron’s review of Darkfall, and how part of the debate was overtaken by a discussion of design versus fun. If it’s fun, is the bad design excused? Why should a reviewer’s sense of “fun” take precedence over a gamer’s sense of “fun”? If you want an example of such a subjective consideration, just look at Scott’s assessment of Tabula Rasa — in one word, the cause of its failure was “meh”. I can’t disagree with him, as I didn’t play TR, but now try to draw a lesson from it: “Don’t make boring games”? Perhaps that’s why part 2 ended up like it is — because the drawing of lessons is a treacherous game to play, even in hindsight. Might as well give the MMORPG.com crowd its panem et circenses, then.
about 6 months ago
[quote]No, I can’t make that leap, because I don’t agree with it. Again, you’re not listening to me. One of our four items in Column B was “Failure due to not keeping scope in check.” What you’re saying is more like “Failure due to not keeping pricing in check relative to scope.” They both touch on scope, but they are, in fact, different things.[/quote]
Technically, scope is inclusive of everything but in the context of these articles, you are right.
I would argue that any ‘pricing’ dispute is really more of a reflection on “Service” in that it’s a customer relations issue.
The four areas that Scott lists (Scope, Technical, Design, Service) are VERY broad areas in which just about any failure could be defined.
I think part of your problem is that you are more narrowly defining these categories than Scott.
about 6 months ago
Isn’t saying that a game has too small a niche or market the same as saying it’s not enough fun for enough people? These are issues that blend into one another.
about 6 months ago
There’s a slight difference. A game might be fun (meaning: enjoyable to play) for a lot of people, but if it has a very niche market, very few will actually try it.
about 6 months ago
Alright. That doesn’t really sound like what happened with Auto Assault, though. For instance: I heard a “Car Wars”-ish or “Deathtrack”-ish game was being made called Auto Assault, and got excited. Sounds like I was the niche. But then I heard it wasn’t fun. So I didn’t try it.
about 6 months ago
While there’s a difference, niche and fun aren’t exclusive categories.
In Auto Assault’s case, they had a shot at a whole new niche. It’s not like there’s a whole lot of car war MMORPG alternatives.
However, the bottom line of any game is that games are entertainment. If a game isn’t fun, don’t expect people to hang around.
You could get away with just selling a brand slapped on a crappy game if you’re just selling to ride the box sales. For example, the average movie tie in game. However, a MMORPG with a monthly subscription model require longevity to survive.
Not that selling crap to a starved niche was their goal. I was in Auto Assault beta towards the last few months. There was a reason why scope was at the head of Lum’s list. They simply ran out of time finish the game. It happens to most MMORPGs, really – that lack of polish can kill the fun. WoW finished their game a year before it was released, and spent the rest of the time just polishing.
about 6 months ago
Sort of – niche games are fun for a relatively small set of players. Generally speaking, the designers know that going in and build both the game (to appeal as much as possible to that niche) and the business plan accordingly.
Bad games want to be fun, but fail at it. They don’t appeal to the people the designers wanted them to. You can have a bad mass market game (Age of Conan and Warhammer are prime candidates here) and you can have bad niche games (back to Auto Assault). Sure, you get some outliers who like the game but there just aren’t enough of them to keep the servers open – most of the target market have said “meh” and walked away.
about 6 months ago
This is IT project management 101 material. Do people in your industry really not understand how critical scope control is to a successful project? Have you thought about outsourcing project management to people who do this for a living?
A good PMO will make your job easier, not harder – that’s how you tell the good ones from the bad ones. If all your developers hate the project manager, or all he does is ask for status and adds no value, then he’s a bad one.
The second half of the article reads like an Agile primer. Tackle big projects in small bites, get user feedback early and often, and use that feedback to modify your design concepts.
about 6 months ago
It’d say it’s less that game developers don’t understand scope control so much as because game developers are producing a game.
When developing most software, you have a task that the software must perform and set about breaking that task down into a workable design to realize in a functional program.
Games are a very unusual software to develop in that the sale task that the software must perform is “be entertaining,” and there are an infinite number of ways to realize this.
Scope becomes lost quickly because you’ll never know if your game has succeeded in its goal until you’re relatively close to fruition of a complete product. Further, there’s no real limit to just how much enjoyable you can attempt to capture, given adequate time in resources.
What you invariably end up with is an endless development cycle, continue to refine and improve. At first, hoping to eventually realize an enjoyable result. Then, hoping to improve that result to the point where it’s highly competitive.
MMORPGs have it extra hard because they need to be more than entertaining for a few seconds. They need to entertain for months – at least so long as a monthly subscription model is the goal.
about 6 months ago
Geldonyetich needs to Get. A. Life.
about 6 months ago
He has one; he’s a gaming pundit
about 6 months ago
“Games are a very unusual software to develop in that the sale task that the software must perform is “be entertaining,” and there are an infinite number of ways to realize this.”
All software is unique. This has been solved before computers were created. There are an infinite number of ways to build a house or a bridge across a river. The same applies to software such as games.
“Scope becomes lost quickly because you’ll never know if your game has succeeded in its goal until you’re relatively close to fruition of a complete product.”
Why? If the length of time between building something and know it meets the goal is “long”. That is the problem, not the goal or what was built.
“What you invariably end up with is an endless development cycle, continue to refine and improve.”
You say that like it is bad. Endless development cycle means a product is successful with version 1, 2, 3, etc and a good feedback loop addressing your customers needs. Refining and improving is what building solutions is all about. The problem that occurs for some is that progress is measured in years or months while others do it in weeks, days, hours.
about 6 months ago
The reason it’s bad is that you need a ‘point’ at which you release the product and the ‘refining and improving’ is done through the program management of patches and expansions.
You’ll never get to that ‘point’ if you don’t have a clear set of achievable goals for that release. That’s why scope control is important.
As someone posted WAY back, it’s all Project Management 101. The whole purpose of which is to mitigate risk and manage to a budget/timeline.
Believe it or not, the cheapest part in designing any project are the ideas. It costs you very little to ‘think stuff up’ but it costs you dearly to start implementing those ideas. So ‘thinking stuff up’ along the way is a necessary evil and one that you need to plan for by gaining feedback early.
about 6 months ago
Great article.
My only quibble would be to differentiate short term success from long term success.
Everquest for example, generated excellent returns for its investors and ruled for at least 5 years. The initial design was very solid, its demise was being unwilling/unable to adapt to a competitor that dumbed down the concept in order to attract the masses.
In regards to the point about the game being fun MMO’s are a little unique in the fact that you can’t really listen to your clients about what they want as their goals are very short term.
about 6 months ago
1-3 posts a day is not that indicative of needing to get a life. If you don’t like the frequency of my posts, here’s a thought: post more.
about 6 months ago
Ah, I shouldn’t have hit submit comment so quickly, now replying to my replies is going to boost my already copious post ratio.
Well, let me at least keep things short, because apparently I’m making some people uncomfortable via sheer verbosity.
I can foresee this debate between “it’s team management 101, stupid” and “it’s a game, stupid” would go on for quite some time. Instead, suffice it to say that there will always be at least these two types of people in software development:
1. Those who are absolutely confident that any problem, no matter how complex and unclear the end goal (e.g. “be entertaining”) can be designed in foresight, and thereby completely eliminate any possible threat to their scope.
2. Those who never bother to even try to set a scope because they figure they know exactly what they’re creating in their head and therefore can wing it without working out the details ahead of time.
Both parties are dead wrong and equally deserve the misery that comes their way.
about 6 months ago
@Geldon
And then there’s the third approach, famously epitomized by William Goldman: Nobody knows anything. Every decision is a crapshoot that could either work or fail, based on little more than chance. You can’t derive a clear lesson from it, because it could fail to apply in your case, even if you followed the most prudent course, and it would be difficult to see why.
In a nutshell: We’re all groping in the dark, whether we want to admit it or not.
about 6 months ago
You misunderstand. Project management is about planning, true, but that doesn’t mean you believe that all things can be designed in foresight.
Quite the opposite really. That’s why a good project plan includes a risk mitigation strategy. The biggest risk being that your assumptions are wrong and need to be corrected. That’s why proof-of-concept phases and methods to incorporate feedback are included into any successful plan.
As I wrote earlier, the fact that you may need to ‘course correct’ and be flexible doesn’t diminish the merit in having a plan. Ironically, if anything, it means having a plan that includes a way to handle ‘course corrections’ is even more important.
about 6 months ago
[checks watch] Well, it’s been a few hours…
Existentialism. Plato’s cave walls. I love it! I do more than grope in the dark, I relish it.
As pertains to game design in this age, that’s uncomfortably closer to the truth than many of us would like to admit. There’s no hard and fast rules to producing awesome. If there was, the diamonds to rough ratio would be a whole lot better.
This is a good method to operate on. But, as pertains to game development, it’s not good enough.
Go back to our original point of contention, you’re saying that you can’t believe that people in this field (game development) seem to have such a hard time with scope, and my answer is that the scope is harder in this field than others.
It’s not that you’re wrong, it’s a difference of severity. If you’re developing a spreadsheet program, you will encounter setbacks – such as usability issues – but they’re a lot easier to deal with than a game.
Let me use an analogy to explain why (and accept the ease of misinterpretation that would go with such an approach). Basically, creating a game is like creating a joke.
In your head, the joke might sound great. You go through all the effort of evaluating your audience, framing the words of that joke right, perfecting your delivery the delivery, ect.
Then comes the moment you decide to tell the joke. How well you told it is a major factor. So also is the mood of the audience at the specific time you told the joke – maybe they’ve heard too many similar jokes lately, or simply aren’t in the mood for that kind of joke.
You won’t know until it’s time to tell your joke just how well it was received. If it’s a complete dud, you’re essentially forced to go completely back to the drawing board. Even if it goes well, you may decide you can tell and even better joke if you tweak it a little more.
However, no amount of risk management can guarantee anyone will ever laugh.
about 6 months ago
Three game developers walk into a bar…
about 6 months ago
Do comedians tell their jokes for the first time on an HBO special or do they test and refine the jokes over time in small comedy clubs? Even the most successful stand-ups (like Sienfeld) use the comedy clubs to hone their material.
Risk management isn’t about making people laugh, it’s about controlling the risk that they WON’T laugh. And KNOWING in advance whether the joke is funny before stepping onto the big stage is pretty damn important. At the very least, if it’s not funny — you’ll know you need a different joke.
about 6 months ago
Sure, but here’s the thing:
The “joke” that is a game takes a long time to create, and you really don’t know how good it is until it’s completed enough to tell it. If it fails to entertain, you lose a whole lot of progress.
Remember, the topic at hand here is a scope creep. My whole point being why games have it harder than other software.