MMO Development Lesson #1
Do not launch an unfinished product. There may be extenuating circumstances that somehow necessitate the launch of a buggy product from a business perspective, but the game will most likely fail in today’s market, especially if it’s not particularly unique. Do everything in your power to launch a high quality, polished product, because first impressions can make or break a game with the level of competition in the genre today.
There’s nothing wrong with an unfinished environment, provided that what you ship is finished and polished.
In other words, if you start off with one playable area but plan to expand to 50 playable areas, that’s fine. As long as the one you launch with works perfectly.
Content can be expanded, systems should not be.
Cael’s words are correct as long as the content you provide won’t grow stale before the new content arrives. Even then, some people will rate you poorly on the “depth” even if that lack of depth isn’t something they’ll ever need. I have tabletop wargaming friends that dislike prepainted miniatures because “I want to be able to paint them myself.” Remind them that they’ve been playing with the same unpainted warhammer army for a decade and they replay “True, but I COULD paint them…” Many people look for content that they’ll never need…
right, but GG might be looking at this both from a customary user perception of polish and an internal one. Internally, a company has to have its act together before launching. Sometimes the defects users find are symptoms of disorder behind the hosts. Personal experience. Just sayin’.
If i may offer:
Open, Last, Preorder beta is not a beta. Its your first chance to hook your new player base and get them interested for the years (Hopefully) to come. Final beta stage is where you will get your most loyal customers…. Or not. Its a marketing tool, not a beta. No matter what it says in your beta schedulable. This, to players mind, is the first free trial.
Yea, this is what really disappointed me in several aspects of EQ2. I also didn’t enjoy visiting bugged zones and bugged raid encounters. (lol, seems like every raid encounter was/has been bugged numerous times) Anyway, they cut out zones from launch, and every expansion so far. I guess adding them latter as “a bonus zone!zomg!” makes it alright though.
Anyway, I agree, don’t release games with mechanics that will be 75% revamped thrice over, or with content missing that was previously said would be included. Take your time with the development process guys.. it’s not about making money. It’s about being awesome. Awesome like that game that really polished when released.. uhm, I think it was called.. Duke Nukem Forever? -bah I forgot.
Heed your words Ryan. Don’t worry about others
Part of the issue on the dev side is that we don’t limit ourselves in scope very well, especially when it comes to MMOs. This will be one of the lessons: No feature creep. When you have years to make this massive game, sometimes you plan on getting a lot of things in by launch that may not make it in a complete form.
So yes, Cael is right. It’s much better to limit yourself in scope rather than create a whole bunch of incomplete features before launch.
Part of this would be to define what “finished” means. As has been mentioned, if parts of the game are release accessable but unplayable, that’s just bad. Not only does it frustrate players, it will generate bad feelings and bad press. Notice SOEs unfortunate reputation with players, because of problems they allowed to happen with the releases of EQ and its expansions, public perception has been an uphill battle with every game they have put out, and despite facets or expansions of SWG and EQ2 being good, they still get slammed. Their reputation is also appearant with the Vanguard deal. While Vanguard was at Microsoft, most people were hopeful and optomistic, but once it moved over to SOE, the doomsaying began, and it has been and remains loud.
As Tide touches on… the company having its act together internally is important. If you are selling an MMO, that means you will have people with problems online wanting them fixed right now. If you launch without a decent suite of CS tools that allow the proper investigation of logs and abilities to recreate reported bugs, and to resolve immediate issues (like, moving a character if they are stuck.. telling them to reboot, delete files, relogin, try again, reboot, delete other files, etc is not a good solution). And you should have a CS team in place… at this point in the MMO business, the metrics are there, you should be able to estimate how well staffed an MMO CS team needs to be, train a few and hire temps if you must, but lack of hands is a poor excuse these days.
And lastly… while trying to gauge player interest can sometimes go awry, you must have a plan in place for how to deal with both the failure of your game and the “unexpected” success of your game. You may never use the plans, but if you need them, you’ll be glad you have them.
Ryan:
Change your world. Watch Guy Kawasaki’s The Art of the Start speech, and then read his blog religiously. One good article relevant to this “lesson” is The Art of Bootstrapping. FYI: Guy Kawasaki is now a Silicon Valley VC, but he is known better as the former Chief Evangelist of Apple.
Reality #1: Eventually the people paying the bills want a return on the investment. Addendum: Careers aren’t built on not launching games.
Yeah, Ryan is right, the goal is to release as high quality product as you can. But, nobody really sets out and says, “I want to ship a shitty, incomplete game that people abandon in droves!” I think if there were any realistic way of salvaging a half-finished game at the time the people decided to ship, they would have. Even the most insane people I’ve known in the industry don’t follow the Klingon programmer quote, “Perhaps it is a good day to die. I say we ship it!”
The trick, as Ryan suggests in his comments, is exceptional planning. You need to plan out your work ahead of time, and you need to avoid piling up tasks at the end. Leaving some “wiggle room” for the issues that always pop up is important. Spending time on a reasonable prototype is also time and money well-spent.
Why don’t we plan better? Because game development is still more black-magic art than easily explainable science. When you start having to employ a few hundred people all working together on a creative endeavor, things don’t fit neatly into little org charts and Gantt charts. Beyond that, every group that sets out to do an online game thinks they know everything that the previous idiots that made previous games didn’t think of. But, once you’ve been through the meat grinder a few times, you do usually know better.
And, as the addendum above says, sometimes simple experience isn’t enough. There are a number of people I’ve run into that have worked on multiple projects but that still don’t have a clue about what it really takes to run a game. But, they have a launch on their resume, so they’re golden!
My thoughts.
developer blogs, it looks like. Shorter than signing them up in a feedreader, I suppose. Alas, it only grabs the gaming category from here. Which means you miss out on the awesome Sunday Poem I posted yesterday. Really. Go read it. [Link] Nerfbat » MMO Development Lesson #1 Do not launch an unfinished product. There may be extenuating circumstances that somehow necessitate the launch of a buggy product from a business perspective, but the game will most likely fail in today
I don’t think anyone plans to release an unfinished product; I think they fail to plan for that day where the money runs out and the only thing left to do is slap some shrink wrap on it and see how much you can pack into the day 1 patch.
Some teams err too far in favor of “baby steps” – a reiterative process of “build, evaluate, fix” that people call “modular”. This isn’t a magic wand, however, and your planning has to be excellent or else it becomes “build, evaluate, retune, refit, repeat”.
WWII Online’s terrain project didn’t have a fully fleshed specification with usage cases, etc, it only had a rough goal. Once the terrain system was programmatically “working”, team members were tasked with populating the 1/2 scale European terrain, only to be halted after less than a week with a small library of critical bugs. The programmers had to be pulled back off other projects, which they were already eyeball deep in, to fix the bugs. The fixes required a fresh terrain start, putting both programmers and terrain editors weeks behind schedule.
Meanwhile, in the absence of goals for the terrain system, the un-verified progress of the first week was allowed to be used as the basis for setting expectations of deliverables. With “delivery” as the sole goal for the terrain system, it stayed locked in a cycle of “do what we can, fix the bug list, redo whatever the bugs+fixes cancel, repeat”. Eventually the coders’ hands were tied from doing anything that would result in a loss of content, and once the terrain system could be used with extreme-caution it was left alone.
The opposite extreme is to try and build the whole project at once (more or less) with the goal being functional completion of all systems and technical acceptance of all assets (sound/graphics/quests). Wondering how that’s an extreme? Well, that’s a software development approach to building a game. That’s how you build a wordprocessor. Building a game is more like the culinary arts – the ingredients you use make a particular kind of product, but how you prepare them, how you combine them and how you polish them can produce wholly different flavors.
For instance, I think SWG at launch was a success. It covered every taste, but creating such a spread of material meant there was no real depth to anything. I think the achilies heel of the launch SWG was the assumption that you would get more out of SWG by experiencing different branches of the skill tree. And it almost might have worked, but you either had to destroy any role-play of your character to do it, or you had to go to a different server.
Lucas drew endurance for Star Wars from making his characters no-more than two dimensional, the way heroes are preserved from antiquity. Hercules the strong, Noah of the Ark, Jason the Argonaut, Arthur the Just, William the Conqueror… Star Wars characters are like superheroes, with enlored attributes. When a child plays with his SW figurines, they have fixed roles and talents.
My hunch is that SWG development was microfocused until very late in the project. Everyone was busy trying to deliver their part of the cornucopia that nobody was really in a position to try and see the project as a whole. When the game shipped, arriving players got a delicious taste of the StarWars universe as they had imagined it, only to find it was merely a sampler. “And that concludes Bounty-Hunter-101, move along to the next display please”.
So to deliver a shipping-ready product on time, you need to allow not just for technical finesse and development, but also for tempering the mix. You should make sure that you aren’t going to find out what kind of game you have until you reach open beta or later. Your open beta shouldn’t be the first time you get to taste the spoon…
If you’re building a character-building, zone-based MMORPG, you should prioritize the fundamentals – grouping, combat, skills, quest engine. You still have plenty to build after that. Plus, by having your teams working together on a microcosm of the game itself, you will establish conventions and standards much more quickly, get much more focused feedback on tool development early on and be far better placed to discover recurring problems.
“No feature creep.”
I’m a project manager who’s working toward a Black Belt in (F)LSS and a CAPM/PMP, and I can tell you that till your teams adopt a rigid project management methodology, you’re doomed to repeat the failures of your previous releases/implementations.
Now, I’ve met some of the PM’s from SOE, and they impressed me to no end, but as they say, the proof is in the pudding. They’ve certainly gotten better at SOE at delivering quality, but unfortunately they seem to have had to learn from mistakes made along the way. Experience might be the best teacher, but it’s a lousy accountant.
What I’d ideally love to see one day is one of the gaming companies bringing an actual PMO (Project Management Office) online to oversee and develop the processes of the development teams. I can’t begin to express the value of a few quality project managers involved right from the word go.
I’d have to disagree, Kendricke. That is one of those lines-in-the-sand between Game Development and conventional, “Best” software development practices.
The end product here, the major component of success, is that most ethereal of unquantifiables: fun.
I guess, summarizing my previous post, there has to be room for “art” in an MMO project (by which I don’t mean graphics).
Earth and Beyond was developed with standard, clinical, PM. It was a technically excellent game, it included some high-potential concepts and features – several elements of the game live on today in other games – but it just wasn’t “fun” for the vast majority of players.
Gah, darn focus stealin’ operating system. I wanted to close with:
That’s not to say good project management has no place in MMO Development, but you can’t just lift if straight from, say, business systems development (although it might otherwise seem to share much in common). But the PM systems I’ve had experience with during my 15 years as a business/network systems developer seemed to lack the flexability required to deal with something with such an artsy primary characteristic on such a large scale. (Web development seems another close candidate until you look more closely)
Oliver, when I was working in quality assurance at SCEA, my leads demanded that I discontinue researching SQA because “games are not software; they’re totally different because they’re fun.” That’s utter bollocks. Games do not own “fun”.
Well, I wouldn’t take it to that extreme. “That’s not to say good project management has no place in MMO Development, but you can’t just lift if straight from, say, business systems development (although it might otherwise seem to share much in common)” Key word “straight”.
There are similar requirements in developing major websites: I worked for a number of media companies struggling to get to grips with the fact that developing sites wasn’t just putting up some pages with pictures, for web projects like Stars in their Eyes, Cold Feet, Coronation St; I worked for Page3.com briefly. Designing a good, user-retaining, non-retail, non-product website has some of the same risk. But they generally involve significantly less people.
Its not that games own fun, but fun owns games. Its incredibly difficult to project the “fun” factor of your project until you have significant components of it to work with. Single player games can generally tackle this by having a mockup, perhaps a single level. I think its much harder to do for most kinds of MMOs, and the risk of a major rescheduling of the project.
Take SWG – by the time it became clear that the “individual snowflake” approach to itemisation was going to be a real risk, it was already an embedded part of the design and implementation of most of the game.
What I’m describing is not an abandonment of PM, but based on 15 years of experience in the business/system/banking/military development disciplines fields and 4-5 years of gaming development, the need for a gaming-adapted form of PM.
From everything I’ve seen (experienced, read, heard, discussed at conferences) gaming has a lot of scope to shake off its garage-background an learn concepts from other discplines such as testing, automation *and* project management. Games without decent PM – such as WWII Online, Anarchy Online – and games which followed the rule book for another discipline too closely – Earth & Beyond, AC2 – prove that it needs something else. PM for banking is subtly – but critically – different than the PM that works for, say, a military contract.
Out of curiosity, what other kinds of project would you consider to have “fun” as their primary and critical component?
PS – My role on those web-projects was a network systems engineer helping to prepare and build the infrastructure (e.g. I wrote the Stars voting engine that could handle 8 million votes in 30 minutes instead of 250k-before-it-craps-out Anderson designed Sun-Firestar cluster did), and building their content management systems and workflow systems.
Just thought that perspective might color my comment correctly
[...] MMO Development Lesson #1, more or less just said: Don’t launch before you are done, unless you have to, even though you’ll probably fail unless players can’t tell what’s a bug and what’s by design. Do things that you think are helpful, because then if your game fails, maybe you won’t feel so bad. [...]
Psychochild:
Pretty much any software development past a few hundred lines of code suffers from this. You plan, you do charts and flows, and outlines, and detailed specs, you even use Zed for the core stuff…but the specs are often a moving target and planning for that is not easy to say the least.
I’m not in the game / entertainment industry, I write software to test hardware and materials, but as I said, this problem exists in all facets of software development.
si no es un concepto particularmente único.Haz todo lo que esté en tu poder para lanzar un producto de Alta Calidad con un buen acabado, porque las primeras impresiones pueden tanto impulsar como acabar con un juego en el mercado actual. Fuente: Nerfbat
[...] http://www.nerfbat.com/?p=201 [...]
[...] MMO Lesson #1: Do not launch an unfinished product. [...]
[...] Fuente: Nerfbat [...]
I agree with you here Ryan. An unfinished project is kinda risky. I mean all of the mmo’s that I have played are usually crap unless they are finished. Take Lunia for example, horrible game. Why? because it’s a beta. Now I’m not saying all are crap. Iv’e come across a few, that were worth playing, like 2 Moons, great game. Took awhile to lvl tho…