It's funny reading the back-and-forth here, with the staunch incumbents beating back wave after wave of marauding invaders. I don't really care to get involved in that, but thought I might tackle one of the arguments that's often employed as a defence of CIG and SC, and elaborate on exactly why I don't believe my pledge is or has been well-managed. That argument is the one about only game devs being able to understand game development. This is a point that I vehemently disagree with.
I am a software engineer, and have been since graduating from university. As I understand it, a "game" is a piece of "software" and as such is "engineered" in much the same way as any other piece of software. Having said that, a game engine and its accompanying game logic and art / audio assets are generally toward the top end of complexity. Game engines are multithreaded (and anyone who's written any kind of software will understand the nature of that problem) mammoth amalgamations of code that are designed to take creative and logical input from game designers and programmers and deliver it to a computer's output devices in such a way as to be both pleasant to the eye and ear, and to match the intentions of the designers with a minimum of fuss. Add in asynchronous and unpredictable external inputs (networking being the big one) and you have a problem that is very hard to solve. For what they do, and the hours that they're expected to work, game engine programmers are both underpaid and undervalued.
I've worked on a wide range of software products, some successful and some not so much. Invariably the ones that were most successful were the ones where requirements were well-managed, where scope creep was contained and where time and budget were key drivers for delivery. When you design a piece of software, you typically have a high-level set of requirements. In SC's case, those requirements were fairly well laid out in the Kickstarter and were the basis of the initial round of funding. Clearly game development is relatively fluid, but the product as sold was intended to be a particular thing. In a fairly rigid software development, these high-level requirements would typically be broken down into more achievable -- and importantly, measurable -- lower-level requirements. These in turn would then be agreed upon by all stakeholders (typically in game development, the publisher(s)), estimated for time and budget and funding laid out. If you don't already have a team, this is when the HR machine rolls out.
Once you've got your key designers on-board and bought into your vision and the requirements for the game, you'll outline your high-level design. You'll probably do some storyboarding and get some UX people involved. But with the best will in the world, fun is subjective so you'll keep an open mind and be ready to be flexible with your vision. You'll identify the biggest risks to achieving your goals, and you'll put plans in place to mitigate them. You'll decide whether you're going to base your software on existing products or whether you're going to roll-your-own. From the Star Citizen point-of-view, all this means that CIG should have identified that networking would be one of the most critical components, and should have been one of the first things to have been nailed down (as unfun as that is for the backers). Knowing that 'fidelity' is a key requirement, and knowing that this is essentially a multiplayer game, early work should have been targeted at identifying the key state information that would need to persisted across connected clients, and identifying a budget for both that and extras. I, like many others, was wowed by CIG's demonstration of procedural damage states but concerned about the implications of persisting those states across potentially hundreds of clients in real-time. I'm not convinced that when CIG were designing that feature, networking was taken into account at all. It was more driven by a technical desire to deliver more than any other game has delivered, regardless of how feasible that was. If they'd look at their networking budget they might have scrapped the idea before going full out implementing it. Even if the networking budget was good, how about processing and graphical budgets? If all those are good, does the gameplay justify such a complex mechanic? [Given your design for the flight model, will you ever actually see bits of spaceship fly off and if you do will you notice that they were broken off realistically in the heat of battle? Therefore is it worth the expense?]
I digress. One of the important things about a game is that it's fun to play. It's a fundamental requirement. If you fail to meet this requirement, your product will fail. The great thing about the games industry is that it's full of tropes, so it's fairly straightforward to pick and choose tropes that are considered fun. It's not *innovative* but it's easy. We know that FPS gameplay with cover and stealth dynamics are generally fun. We know that flying a spaceship is generally fun. We know that noodling around large MMO environments can be fun. So a game that incorporates all those things should, strictly speaking, be fun. But there's a lot of nuance to taking something that *should* be fund and actually delivering on it. Flying a spaceship could mean anything from point-and-shoot to full management of systems. How an FPS (particularly a single-player) one is fun depends on your interaction with the environment, and the balance between challenge and obstacle to progress. Noodling around in a huge MMO environment requires more than just being able to dance (emote). That doesn't even touch on *innovation*. CR has always been about innovating and pushing what's possible. FPS in zero-g is *not* a common trope so there's little in the way of evidence to show what is and what isn't fun. Flying spaceships is somewhat common, but being able to get up and walk around them while in flight, and the activities therein are *not*. Elite innovated somewhat with its space travel so CIG have something of a yardstick of fun, but in terms of the FPS element of it, there's really nothing.
So how do you go about determining what does and what doesn't work? Well, rather than dreaming up fantastical notions like carting cargo around by hand one piece at a time or being a space waiter, you *prototype*. This is no different from any software development where requirements are fluid. You skip the onerous audio and artistic work, you say to hell with the fidelity and you throw something together that quickly demonstrates the idea and you focus group the heck out of it. The biggest asset that CIG have is its backers, so getting gameplay out to them as early as possible should have been the goal. But that's really where things started to go wrong for me. CIG (and CR in particular) are so driven by fidelity and by perception that I suspect they didn't feel they could throw prototypes out there like that. Everything released to the backers had to be polished. We can see that they've changed tack on that of late, with the illuminati (or whatever they're called) being effective surrogates for gameplay testers. But that's still too little, too late.
Because of this blinkered approach to development, the game has iterated slowly -- glacially even -- to where it is now. It's at a point where what's been implemented is sort of fun to play for a bit, but that is fundamentally missing most of its gameplay. Gameplay that's slowly being added, polished, changed, polished again, etc. when it's the gameplay that should have been nailed down at the front-end of the project and fripperies like ship variants and clothing should have been implemented toward the back end. Beyond a certain point, budget (and therefore scope) should have been fixed. After even a year in development, the requirements for this game should have been nailed down, but even now they're fluid. Everything I see about this project speaks to a hugely creative mind who wants their game to be the biggest and best out there, but who should *not* be in control of budget or delivery. Chris Roberts should ideally be lead designer of this game with a management team who have experience in delivering games on-time and on-budget. I'm happy that the whales continue to fund the game; it increases the chance that I'll eventually see a completed game for my piddly contribution. But I don't think anyone can look at this project in hindsight and say "job well done".
But I'm not a game developer, so what do I know?
Great post imo. My game developer friend noted early on to me that they need to nail down the networking, because if its not the game can really suffer. There's a recent post on Glass Door for CIG that says
I believe we should make an official announcement as to what players should expect will actually be part of the game when the persistent universe goes live. This roadmap should be clearly defined and explained monthly as to the status of the systems. Information is currently too scattered with many external sites assuming things and us not exactly clarifying them. With all of the 10 for the "x" episodes and Media shows we produce, there is some outdated information that should be updated publicly so there is no confusion about something we added or cut after that video was created.
There's a few others on there saying similarly. Many of those basic game mechanics are missing. Trading etc. Instead CR's vision of fidelity seems firmly planted at every turn.
