Useless why? I think you are just frustrated that its not progressing as fast as all of us would like. But keep in mind that we don’t actually know how much work is being done and how much work goes into stuff like the new networking etc.
1 Like
Yeah, I mean, incorrect estimates are definitely an issue. They affect overall development timeline.
The real question: is this a situation that they can be corrected in? IIRC, the inovae engine was ~500k lines of code. This is huge. Such a base can potentially reveal bugs/design-assumptions-gone-wild throughout development. Not to mention trying to remember which parts affect which as you add new features. This is not trivial.
If these factors can’t be accounted for, then I’d rather accept the current stream-of-consciousness style dev posts while trusting that the team knows their own deadlines and will be able to compensate for deficiencies. This is because they are adults with professional experience.
Ultimately, spending more time on the framework and at lower level is better than letting issues arise during the game’s development. It saves more time when you have a very solid base rather than hacking together a game with a lot of deep-seated issues.
1 Like
You are wrong, I don’t care about the actual game, so the delays are not the issue. Issue is that all these updates sound so good on their own and use such liberal deadline predictions and then a few months down the line all those positive statements have turned out to be false. That would be plain lying if they knew that they couldn’t do what they say they would do, but we don’t know if they knew, so I’m being conservative and calling it misleading and misrepresentation.
Take something like the installer, error reporting and pledge upgrades, it was stated shortly after the KS that they are aiming to have this done around the first release, it’s now 11 months later and it’s still not in 100% functional state. That is so badly forecast that it makes one wonder how are they making these task schedules.
2 Likes
This has happened many times before (and I’m talking old forums). For a while, Flavien and Keith were falling into the trap of giving dates for stuff which then ran over. Since then, they have made a conscious effort to keep their promises more vague.
However, the kickstarter has required more regular communication, but I feel like INovae has been pretty clear and honest about when problems and delays have got in the way.
Plus, we should remember the overall progress! Dev Access backers have a playable prototype, and that means it is full steam ahead to Alpha! Yes, it might take longer than expected, but again INovae have regularly been clear and honest about it the whole way.
As far as I’m concerned, they have maintained their integrity. Maybe some phrases should be avoided, but week by week updates give a picture over time of how things are going.
3 Likes
The proper solution is not to make promises more vague so there isn’t as much flak when you break them, but rather to make and keep promises.
Let’s be realistic about what we got in the past 11 months of development on the prototype. The art team is on schedule, that is clear, we now have 3 flyable ships with cockpit interiors, stations, ground assets and a NPC hauler. However the coding side has been a desert, we got key binding, refactored physics, ship physics tweaks and probably a few cosmetic tweaks.
2 Likes
I rather have the devs put 500% on their predictions when they tell us. They can have their old predictions in house but I really would prefer if they type out the weekly update and then go to every date and multiply it by 5x.
I rather be surprised by something appearing earlier than than they told us than reading an update and hearing over and over again how close a certain thing is.
2 Likes
Pretty much. I think they should stick with statements that only have to do with the past. “This is what we’ve accomplished over the past N days.” They just don’t have the training/skills/discipline to schedule the project. An excerpt from my favorite nightmare post from Flavien about scheduling software projects.
Those are not the words of a man who can reliably predict project progress.
And in looking through the old posts, the original Alpha date was October 29. The reason that date was chosen was very probably “Well, it’s far in the future and we should have a big chunk of functionality done by then.” So too is the new date of February or whatever. “That’s pretty far out, so we should have lots more done.” I seriously doubt anyone has broken down the project into 3 day tasks.
The last time I did that, the derned project exploded into a 4-man-year year effort, for what looked like a rather small project. And it did indeed take 4 man years.
A note to Flavien: I freely bash on you for your attitude about scheduling, but realize that I have nothing but respect for your talent as an engineer. You just desperately needed a development manager back before embarking on the Kickstarter.
2 Likes
I said it before and I’ll repeat it: development is not an exact science and forecasting how long things are taking is pretty much impossible.
I just wasted 4 days implementing a new memory-pooling system and once I finalized it, I benchmarked it, and it didn’t run faster than standard memory allocations. That’s 4 days wasted and I had no way to know before hand, because usually pooling is regarded as a good thing.
When Keith implemented the Stripe API for pledges, the web hooks got called twice instead of once and that required some tweaks. There was no way to know before actually using it that Stripe would call the API twice instead of once, fucking up our initial implementation. You can’t anticipate those problems. So on surface it looked like we were done with code, but in reality the first batch of testing reaveled many problems that required code updates.
Those two examples are drops in an ocean. I’d love JB or critic to explain how those things could have been taken into account weeks or months before the work was done.
10 Likes
If you know that you always have issues, treat unknown issues as a variable that will take some time in your planning. You have had unknown stuff happen to you countless times, just factor it in as a task that will happen, but you don’t know what it is yet. Check your past task list, if you on average allocate a week for something and it takes a month, the next time you schedule something that will take a week, allocate a month for it. Off the top of my head, from the peanut gallery, i think allocating about 500% of what you think a task will take would work at this time.
I’m curious to know what it is about this particular update that has suddenly sparked this reaction. As far as I can tell Keith didn’t mention anything more specific than “hopefully soon”.
Even massive companies (like the infamous Valve) use phrases like that but expect the community to know what it means - that they aren’t ready to commit to a date, but it’s in progress.
So let’s not bash anyone for using certain phrases. It’s our job as a community to pass the comments through our internal filters and recognise what they are actually saying. At the same time, we need to remember this is a very small, independent development team trying to balance the weight of increasing expectation.
Soon is fine. We can cope with soon. Relax, and be patient.
Also, I forgot to mention, the models are looking awesome 
P.S. We can’t judge them on past mistakes either, only on the state of things now.
4 Likes
The hopefully soon is just a little gentleman’s jab, I have been thinking about this for a while now…
Anyway, since they are ‘aware’ that software development scheduling is voodoo magic. How likely is this below to happen, given their own admission of issues constantly coming up and them having to change their plans?
There is no such thing as realistic timelines in game development, ever. Unless you do part 3 in a series maybe. Whenever you do something for the first time, you do not know how long it will take. People get estimated timeframes cause people ask for timeframes. If you are frustrated about the delays due to technical aspects so far, i am afraid you will be very, very frustrated once we get to the delays caused by design issues and gameplay problems. Everyone always massively underestimates the time cost of those compared to technical issues.
2 Likes
This is the best way to put it. @Sab1e is a hero.
Let me tack on some considerations to help people who aren’t familiar with large infrastructure-type projects.
I understand the frustration. We have missed several deadlines. But it’s doesn’t mean the game is stuck or in development hell. On the contrary, I believe the decisions to be careful at this stage and delay was the right thing to do.
Many features people want can easily be bolted on in the engine’s existing state. VR, joysticks, sweet GUIs, etc…
These are not the hard parts of developing software. The hard part is in the base architecture; the design and organization of low level components work. These components have the most ramifications when it comes to designing the actual game. It’s literally multiplicative in effect. When you’re deep in a large project, it’s more important to maintain a consistent design/not screw up than to constantly add new features like some fictional super-hacker. See WISCA. You have to really think about the parts of it that are affected to prevent creating more work, as well as consider future components that aren’t affected. This is overhead added on top of actually developing the feature.
You may think “but what if they spend too much time on critical component X”. The alternative is rushing a game, and causing so many bugs that you don’t have the money or time to fix them all. This is how small studios fail.
I’m sure the team is allocating their time the most efficient way they see fit. They are not amateur developers. In reality, predictable deadlines only work with fully developed code bases(e.g. relatively trivial things like web/app development). This project isn’t comparable because it’s literally building a foundation rather than just an application. Remember, this game is a first-of-its-kind. They have to discover the most efficient ways to do things themselves, which is much more expensive than using ready-made solutions. Please try to accept the ambiguity that naturally exists with software development.
Again, I think that all member of the team are reasonable and know what they’re doing. I’m sure they reflect on the state of their development regularly enough to prevent wasting too much time on unimportant parts of the game. But it puts an unnecessary burden on them when us community members abuse the discussion forums to express our raw anxieties(even reasonable ones!) rather than well-written suggestions.
1 Like
After this update, I sadly realized, that Alfa won’t come out (at least with all rought gameplay systems) in February, or March, or even May. I am even questioning June…
2 Likes
@cybercritic may sound a bit harsh but I can see he intends to help.
As someone who develops software for as living I am well aware that estimating effort is black magic.
I reckon that I have felt the I-Novae team was overly optimistic with some predictions, specially for being just two people. I personally don’t have a problem with that. It’s more useful to me that Keith and Flavien keep telling what’s on the pipeline so I can make my own predictions.
If announced dates get systematically delayed I can see it becoming a problem in the future. Some people get excited and then disappointed and then the bitching and general discomfort starts. Again, not my case.
Most of us know it’s very hard to estimate dates and I believe delays are the norm in game development but sometimes it’s safer to make pessimistic predictions or --if possible-- no predictions at all.
In any case, I think Keith and Flavien are doing a great job in keeping honest and transparent in their communication. I recommend being extra careful when making estimates and announcing dates, though.
Loving the renders, by the way. All that detailing on the corvette really helps to bring the scale to the eye.
4 Likes
@cybercritic they give us estimated dates because a majority of the community asked for it (including me), assuming that they were just estimations. What I’m going to say is a fact : you can predict release dates like you can predict what will be the weather in 3 months. Both are depending on Chaos, so you can use your models to approximate them, but because of the nature of Chaos, you have a lot more probabilities to be wrong than to be right.
Assuming that, and the fact that the community is asking for it, I see two choices : “It’s done when it’s done” or “hopefully in 3 months”. In the second choice, depending of your state of mind, there is two ways : the skeptical way, and the optimistic way. Keith is somebody optimistic, and it simply influences his judgment and his writes, like everybody. Just assume that and stop asking him to change his words for yours.
I don’t see any good approach in what you’re trying to do. You just want the communication to be more like you would like. They try to be transparent, and transparency lets us see that they simply don’t know when it is going to reach the alpha state.
I give you one thing I use when I’m estimating a release date : I estimate the more precisely I can the time needed to do it, and I multiply it by 3. I’m always gladly surprised 
<= the alpha of I:B is coming for the end of 2017, be patient 
I am an alpha backer as well. I read the whole thread and I have to say: chill, guys. Yes, you left money here to let devs build “your” game. They are working constantly on it. However, this is not an AAA production with hundreds of programmers and artists. Time and money is limited and must be carefully used to get closer to the release.
I don’t mind about delays. The only thing I want in my life is I:B and AQFE and I do what ever is necessary. And if I have to wait another 10 years I will wait for it. /overandout /whiteknightmode off
5 Likes
Nonsense. Scheduling is a reflection of how well the developers understand the problem and the planned solution. With a trivial problem and solution, yeah, it’s going to be easy, and kids with a couple years of experience can predict how long it will take. With a complex problem and a complex solution, it’s more difficult. However, the essential point here is to understand what you’re doing before you tell anyone how long it’s going to take. If that means spending a couple months exploring highly experimental techniques to nail down what it’s going to take to build them out in the product, then that’s what you do. q.v. Flavien’s procedural generation work.
If you’re going to take me to task on this, I’m going to start stomping heads because this is inexcusable stuff. You made a casual comment about the INS guys not being amateurs. Well, on the scale that I use, this is absolutely amateurish stuff. It’s typical of the game industry - and it’s amateur. The gaming industry is rife with like-minded people who know little to nothing about professional engineering, but lots and lots about shaders, polygon pipelines and a host of other niche topics. Game projects implode all the time because the team has no idea what they’re getting into on a broader scale.
2 Likes
That’s because creative endeavors and R&D aren’t known quantities. The reason it took us so long to launch our Kickstarter is because of planets. The biggest reason our networking has been delayed is planets. We’re doing high end R&D to build a unique experience, it’s full of unknown unknowns, that’s why most game companies don’t do R&D or much of anything to push the envelope. They just license UE4 or Unity and call it a day.
5 Likes
Pretty sure this is applicable to any project in life, not just games! But INovae hasn’t imploded yet, so I’m happy. (Slow and steady metaphor here).