September US sales

[Angelalex242]

I wonder how they ever made these mistakes in the first place.

Didn't they have anybody playtesting it? Commenting on the look, feel, and even story of the game? These are all flaws that should've been kicked out of the beta...or even alpha...version of the game.

Surely a playtester could've clued them in that their 'features' are not features, they're bugs.

[GhaleonOne]

because someone told me at E3, the demo version DID have a targeting system in it

The game wasn't at E3 publically, save for a little blurb in the Nintendo press kit magazine thingy. Unless it was there in a non-playable video format, and for private press groups only, then that's definately not true.

Edit - Actually, I'm pretty sure UbiSoft didn't even have a playable copy of the game at that point.

[DaWrestla]

Surely a playtester could've clued them in that their 'features' are not features, they're bugs

I've wondered that about every single crappy game every produced.

You would think so...

[Kizyr]

Had there been playtesters of the original Japanese version, this element would've been ditched. I'd bet all my silver that no one seriously play-tested it. Beta-test for bugs, sure, but no testing for playability. KF

[phyco126]

This is it then, I think it's a sign for a call to arms! Every Lunar fan out there needs to buy 10 Lunar: DS's! Or so help me....

Actually, I kind of agree with Angelalex242. Even the smallest inconviencence in the game can probably cost thosands of dollars in lost revenue. Sort of like a Hotel, you hear that someone saw a dead fly in their room, it translates to you as a dirty hotel. So you end up staying somewhere else and spread the word. *shrugs*

[drumlord]

Had there been playtesters of the original Japanese version, this element would've been ditched. I'd bet all my silver that no one seriously play-tested it. Beta-test for bugs, sure, but no testing for playability. KF

AFAIK, QA in Japan is the same as it is here. Their real responsibility is to just find bugs so that they can get fixed. That's QA in pretty much all of software development. My web team, for instance, we will work with the QA to find solutions to problems, so they are contributing. But it's not to the extent of rebuilding a battle system in an RPG. There are some things that can be changed easily and quickly and some things that are integral. I think some of the flaws of Lunar:DS were made before development started and weren't really up for debate once people realized they were bad flaws.

[Rune Lai]

They may sound abysmal, but at 40k sales, that would be roughly $1.5M (the NPD numbers reflect that most places are selling it for $40). Take out a good chunk of that for retail, distribution, licensing, printing, and advertising, and you should still be above the average cost of developing a DS game, which is $344,000.

You forgot manufacturing. Or does that fall under printing? Those carts don't come cheap. That's why handheld profit margins have traditionally been thin.

Also, since the suggested MSRP is $29.99, it's possible the extra $10 most retailers are charging is just being pocketed by the stores instead of going to Ubi and GA. I don't know enough about retail to understand how that may or may not work, but if the stores are keeping the excess, then the increase in price will have no affect on Ubi and GA's bottom line.

Either way, I think if 30-40k is all we see worldwide, the series is going to be dead in the water. Lunar DS interview in Nintendo Power sounds too much like a test scenario to me--sticking their toe in the water to see if anything will work, and if it doesn't, the experiment will end. Why make a game for little or no profit when it's possible to make a game with more?

Edit:

There are some things that can be changed easily and quickly and some things that are integral. I think some of the flaws of Lunar:DS were made before development started and weren't really up for debate once people realized they were bad flaws.

Generally, by the time QA gets a hold of a game, it's too late for any major gameplay changes. We see a game in the last perhaps two or three months of 12-24 month dev cycle (depending on the complexity of the game). Assuming Japan's QA works the same, by the time the testers could say the playability sucked, the majority of the gameplay was set in stone.

It's unfortunately common for a tester to hear "That's a great idea but we can't do that now because that would require a major engine change and we don't have time for that."

The publisher-side producers and the dev team are generally the only ones in a position to catch all the gameplay flaws while there's still time to fix them, but the devs tend to have blind spots (it's their baby after all) and some producers are ambivalent. At my work the QA Leads get to review design docs on upcoming games while they are still in the concept phase so it's possible for us to red-flag things while they're still on paper, but this is very unusual and I've never see it done anywhere else.

[Alunissage]

I remember looking for DS specifically at E3 and seeing no evidence it existed.

And yeah, it doesn't seem that anyone's interested in hearing gameplay critiques from testers, just whether or not it will crash. Although it's unfortunate, since even just removing the breakage would have made things much more bearable, and tweaking the battle AI and/or attack stats of the characters would have helped a lot.

It's also a shame that Ubi felt this need to get the game out so quickly. Adding the battle speeding buttons shows that someone there at least thougtht the battles were messed up, even if better fixes weren't possible in their timeframe.

[drumlord]

Generally, by the time QA gets a hold of a game, it's too late for any major gameplay changes.

Yeah, that's what I meant. I have a few contacts within US game companies who get me info on games as they progress. A couple of them are testers and they don't have any input on the games they work on. They usually tend to think the games suck in many ways too. It's just too late by the time they get to work on them.

And yeah, I'm not saying 30-40k is enough to warrant another Lunar game being made. Just that it's possible if they had an average staff and production costs that they could break even. Yes, the carts can be expensive, but the DS carts are a fair bit cheaper than GBA, which I believe is part of why the average cost of making a DS game is cheaper. The SDK is apparently put together very well too, which was another major factor in dev costs being cheaper...but I'm not a dev; I can only go on what they state publicly or privately to me.

[Angelalex242]

So, there IS no QA people?

...Dear Lord. That...suggest a staggering lack of common sense. QA pays for itself, if it's done well.

[Rune Lai]

There is QA. It's just that generally by the time QA gets a hold of a game it's too late to make any design changes. QA is responsible for finding bugs. Bad gameplay sucks, but it's not a bug, so many times QA can't do anything about it.

[Angelalex242]

That's STILL a staggering lack of common sense.

QA should be in on the product before it ever gets so far that design changes can't be made.

[drumlord]

No it isn't a lack of common sense. It's an incredibly practical way of developing a product. Design decisions are made by designers. That's why they exist. Developers, depending on the product you are making, can have everything from a bit of design input to being designers themselves. But no matter what type of software you are creating, QA's responsibility is to make sure stuff works. That's their job.

[Angelalex242]

Yes, but there's clearly flaws to that way of thinking. A good QA team should be able to point out things like flaws in the battle system or in 'fun' before the product goes to market. Sometimes, developers have ideas. And those ideas aren't always good.

QA could...and should...debug such ideas before games hit market.

[Rune Lai]

You don't need QA specifically to point out flaws in a game. Generally you have a developer/publisher relationship with the developer doing the majority of the game design. The developer can come up with a game design and the publisher could say "We think this feature is bad, let's not do this, let's try this instead." It may or may not happen depending on the relationship between the developer and the publisher, but there's nothing that says QA has to be the one to say that.

For the vast majority of a game's development cycle there's nothing even playable. By the time a game hit's Alpha you're already 80% through a two-year development schedule. There's no overwhelming reason to involve QA when the game is just a bunch of bits and pieces that haven't been assembled yet. Arguably the problem is when the game doesn't come together correctly, but can you really expect a tester to spot the future problems when everything is just a module or an animation and not a game?

Some things look better on paper than they do on a completed product and for all we know there could be testers back in Japan thinking "You know, the dual combat mode in Lunar: Genesis could have been cool if they only got it working the way they wanted it to." In which case it might not have been a flaw in the design so much as the implementation.

[drumlord]

It's also worth noting that there are sayings in software development (that I will get the wording totally wrong to) like "The first 90% is not nearly as bad as the second 90%" What that is referring to is that people always want a percentage assigned to where they are in development. And 90% tends to be a common one Theoretically the last 10% of development is for QA and polish. But sometimes it can seem to stretch out to its own 90% of development! So with QA's job as it is now, it already adds a lot to dev time. There have actually been games that were canned because QA found them so unplayable that the publishers scrapped the project. So it's not like QA's job isn't vitally important; it just has nothing to do with the design of a game.

[Alunissage]

I recall the Ninety-Ninety rule being stated something like this: The first 90% of the project takes the first 90% of the time, and the last 10% of the project takes the other 90% of the time.

[localflick]

I've never developed software before, but I do design a lot of websites. The clients I deal with always have lots of input and ideas, which are sometimes good, and sometimes really bad. Sometimes they really want these bad ideas implemented, even if you demo them and show why people may not respond well to the changes. They're paying you as a web developer/designer whatever to give them what they want, so sometimes these bad things end up in the final product. There might have been a similar situation with DS.

I can easily imagine this conversation:

"...but some players will get upset if running hurts you."
"Why?"
"Running and dashing doesn't hurt you in EB, and they're used to it as part of the game. Besides, the characters look like they're healthy and it makes no sense."
"Oh. Well, they'll get adjust to it."
"Uh, okay..."

Were they trying to make it an aesthetically great game, or a very profitable one? I like to think they tried to make it the best game they could, but to me, it feels more rushed than Lunar Legend did. Unless they were trying to go for the title of "1st DS RPG" I don't think there was any reason it would sell very well. Lunar isn't a popular series when you look at the big picture. The two main games were awesome, but most gamers either haven't heard about them, or haven't played them. So of the people that do like Lunar, only the people who have a DS, or are willing to buy a DS will get Dragon Song. If Dragon Song was more familiar (like if it had characters from SS, or EB) and fans had a better idea what it would be like, more people might've taken a chance on it. Let's hope the next one's better, assuming there is a "next one."

[drumlord]

I recall the Ninety-Ninety rule being stated something like this: The first 90% of the project takes the first 90% of the time, and the last 10% of the project takes the other 90% of the time.

That sounds about right. The reason I can never remember it is that a web dev book I had expanded upon it to give a third 90% for something.