I think they should just be upfront and give realistic dates instead of optimistic ones.

https://en.wikipedia.org/wiki/Software_development_effort_estimation

Full disclosure: I spent $60 on the original Kickstarter, but when the scope started going bonkers I didn't toss any additional money into the pot. I don't think I'm a cheerleader for the project, but it'd be nice to have a game in my hands for the money I paid.

I'm pretty confident they genuinely don't have a more accurate idea of the remaining time internally for a number of reasons. I'm not defending their PR style or their development practices, just saying that I understand why they can't set a release month.

First, software estimates become harder to make as you increase the size of a project--intuitively, you may think double the size would take twice as long, but it ends up being much less efficient. Accounting for interactions between systems and problems caused by coordinating programmers accurately requires input data about similar projects and preferably previous work from the same people. Without empirical data it becomes guesswork--and nobody is good at guessing if something will be 200 man-years or 250 when you don't have other examples. When a company like EA, Ubisoft, or Activision set up rotating game releases for things like CoD or Madden, they have a dozen games in the bag that make their estimates for the next item off the assembly line more accurate.

Second, the less you know about a system, the harder it becomes to estimate dev time--and CIG has been tilting at windmills the rest of the industry has moved on from (e.g. shared 1st and 3rd person animations). Even when you know a process is iterative, it's difficult to estimate how much time you will throw away unless you think all experiments will fail--in which case you probably skip those experiments. The problem becomes worse as you know less about what you're going to build, and CIG has a habit of following the ideas of Roberts as they form.

Finally, when you spin up a multi-year project with a large team it can be tough to know how good your team will be--it sounds silly, but if you have a studio of 30 and you're going to build one of 150 that's 120 unknown hires that may be better or worse than you expect. You might get lucky and have a talented person who throws themselves into overtime because they have a passion for the work, or you might have a bad hire who makes the job of every person around them harder and therefore slower. Obviously you want to interview carefully, but when you need dozens of positions waiting for ideal fits can drastically delay your project, too--I've been on interview teams where we've been asked to green light somebody shaky because so few people are available for senior or expert positions and we need to get started on tasks for that position soon.

Tossing out a number like 12 months is sometimes really saying "I'm not sure, but that seems like a long time so we'll go with that." There are entire estimation systems that are based on engineers calling things small, medium, or large without trying to be more specific because it's so hard to be precise at scale. Obviously that's a horrible way to deliver something that has already been paid for, but reading between the lines I don't believe they have a strict project schedule in place.

Ultimately, I believe that it is better to promise less than you're developing so that you can cut scope without disappointing people and make your customers happy with "extras" if you hit your targets. When the public face of your company is an idea guy who gets excited about possibilities, however, that's really tough to pull off.