(I’ve been writing this over the last week or so, and I’m no editor so apologies if it’s a little jagged)
I got into the take-off training in Star Citizen. It made the hairs stand up on my neck and arms.
Let’s put the first card on the table: It’s alpha or pre-alpha or something. Early development.
Ok – the experience should be gauged accordingly.
My expectations of an alpha/pre-alpha flight training session would be a series of small tests of the appropriate systems to get a feedback cycle going. You don’t want a long feedback cycle because that way stuff gets overlooked and takes much longer to get polished/fixed. Any developer worth hiring knows this.
I expect coder art in the UI maybe, art-stand in objects (“REPLACE ME”s), audio placeholders.
It certainly shouldn’t be up-front polish, because that’s going to make the burden of changes/fixes so much heavier, stuff is going to get swept under the rug and it’s going to be a bitch to work with.
Back to the game:
Once selected, the training session starts off in a hangar bay inside what I guess is an asteroid with two ships – one for the instructor and one for you.
You are harangued by the instructor to run over to him – you start on the ground as a pilot in FPV, not in the plane – to speak to him for some kind of NPC-dialog test where you have to listen to this /long/, voice-overed dialog from the instructor before he tells you to get to your ship.
The dialog continues as you run to your ship and you are given voiced-over, verbal instructions to get you started, but it all takes so long that it’s easy to miss the instruction to turn your spaceship on, or the instruction about how to get mouse control to interact with your ship, or …
Then you are locked out of inputs while the instructor takes off, and you’re expected to have caught the multi-key/button sequence to press in order to be able to watch his ship take off from the other side of the hangar, line up with something that’s overhead to him but not you, and fly up and out of the tunnel. You can’t see more than half of this, but you have to sit and wait while it happens.
Then it’s your turn, but there are no live instructions. You’re expected to have remembered everything you just heard and do it yourself.
The final heckle raiser … you’re specifically told by the instructor that this whole thing can be skipped, it’s not actually a requirement. In the live game you’ll have an auto-takeoff button that will talk to the tower for you, move onto the taxi way, strafe under the launch tunnel, fly through the two airlocks involved and get you out into space.
There’s a whole lot of audio dialog here.
Now – there are other elements that bothered me, but I’m giving those BOTD as first pass issues (can’t skip dialog, for instance, when you have to rerun).
It’s one of the worst flight training tutorials I’ve ever encountered, even after I allow for it’s alpha status. The problem isn’t what’s missing but what isn’t. I want to learn to fly, I should start *in* the cockpit and probably with a trainer guiding me from inside not yelling instructions from outside.
I’m not even protesting the first-person aspect, except that it’s *inside* the flight training tutorial. If that has to be there, that should be how you decide what you want to learn: Walk up to the instructor and say “teach me to take off”, “teach me to land”, etc.
Let’s cover specific development issues with this approach:
1. It’s all voiced over. That’s a lot of $$$ for an alpha implementation, and it suggests things are intended to be set in concrete.
2. All the controls are enabled from the get-go. You aren’t “weened in” as most games have been doing for years now – that is, until the ship is started, there are only two or three buttons that work: start the ship, exit and maybe headlook/mouse look. And the game waits for that action to be completed before enabling/allowing anything else. This is a FUNDAMENTAL to training tutorials in the modern era and it is NOT present in this alpha, while all the other stuff that doesn’t need to be is. This is the sort of fundamental that should be developed first and be a horrible source of bugs in the alpha, not something that you’re going to develop later. Because it changes things.
3. Waiting for the other craft to take off takes what seems like forever. This is absolutely not fun. Coupled with what the voice acting says, it suggests the voice recording and animations and implementation was all fleshed out before it was tried. Or worse, that even when it was tried, someone approved it for further fleshing out.
4. Adjunct to (2) and (3): as the instructor is slewing to the launch tunnel, he tells you – that is, voice actors have been paid with providing a voice performance of these words: “be careful not to pitch the aircraft because then it’ll be really hard to line up again”.
Somebody recognized that the controls were clunky, too exposed at this delicate phase of training, and that the training was probably not being done in the right order. This isn’t a computer-generated voice or some pop-up text. This is a voice actor.
Those words had to be scripted, directed, acted, recorded, keyed, edited, trimmed, translated, fitted.
If this was maybe beta or RC, sure – I could see that as humorous. But in alpha/pre-alpha? That’s wiping your ass with hundred dollar bills.
As I’ve said before, these are smart, talented individuals many of whom have a great deal of experience.
Which tells me one thing: This has been played out internally to manipulate and assert control over lower-downs. We saw this kind of manipulation by McQuaid in Vanguard and higher-levels at Schilling’s 38 Studios (to cite just 2).
Someone decided how a thing was going to work and is not about to have something as stupid as player feedback change that. So the first pass has “blind polish”. That someone had a full lineup of developers, artists, soundies, etc, tasked with working on this simultaneously. As Hammond would say: “No expense spared”.
It’s a simple manipulation trick: line the thing with gold so when your people come back saying it doesn’t work, you have an automatic elephant-in-the-room of “so you’re saying you got paid good money to do a bad job?”. When you’re in that meeting, with all eyes baring down on you, it’s a great way to derail you from saying “Hey, I was against putting every team we have on this task”.
One thing that players often complain about game development is that developers don’t do things in serial: they multi-task. “Why isn’t everyone working on fixing this bug?” well, the artists can “art” it out of existence, it’s a software bug, or the developers can’t “code” the sides of the building not to glitch because it’s a polygon issue that needs art love. And so on.
But that doesn’t seem to be happening with SC, and what’s happening is what every developer who’s worked on a game and spoken with customers has explained will happen: Things take longer because of downtimes caused by team A waiting for team B or teams C and D waiting for teams A and B to finishing bouncing things between them. And it ALL has to happen before you get something you can sit down and say “oh, this is difficult, lets not do it in an asteroid”.
At that point in time, though, you’re just not going to say that. You’ve done the art, the voice, the physics, the animations, the decoration, all kinds of extra coding.
The solution that gets forced onto the table will be presented in a way that says “we’re 90% of the way there, just make it work”. I think I’ve drawn the Google comparison before: the people on the project continually let themselves believe they were just a quirk away from making it successful.
What would I have done differently?
1. Basic training system (cues/prompting/feedback) developed and tested first,
2. Simple in-space test of basic controls and flight and maybe some audio cues with stock sounds/audio,
3a. Flesh out the UI and audio,
3b. Flesh out the training components,
3c. Flesh out the play space to make it more interesting,
4a. Repeat 3,
4b. Storyboard the remaining elements,
5. Apply what we’ve learned to 2-3 other training sessions that have been planned for feasilibility testing,
6. Incorporate what we learned from 5 back into the initial training build,
7. Repeat 3, 5 and 6,
7. Use feedback to repeat neccessary steps.
You have to build a core of “fun” or everything is wasted effort. “Cool” – as I’ve said before – rapidly turns to “cold”. And here we have a complicated “realism” take off system developed up-front.
If SC is going to get out of the door – ever – they need to focus on actual gameplay deliverables and not get distracted with things like this.
Let me add this caveat – I know that many SC geeks, especially some of the harder core deeper pocketed backers/evangelists, are going to love taking off by hand.
Some of the time: When they’re role playing or goofing around or making machinima.
But manual takeoff is going to account for less than 1% of takeoffs, probably less than 0.1%, after the game releases, and the vast majority of players are going to bitch about how long takeoff takes while they sit there with the autopilot taking off.
So the effort that went into fleshing it out for it’s first public viewing … is terrifyingly wrong.