Hello! I read the weekly updates every week (redundancy!) and every time there’s something about “took longer than expected” or “this is why it is being delayed”. Let’s get real - due to the nature of development and simply being human beings there’s no point in assigning completion dates to anything, publicly i mean.
Instead, i suggest some sort of progress tracker that is updated every week, with a “+23%” change from last week. List features by major releases, such as Alpha 1.0, Alpha 1.1, Alpha 1.2, Beta 0.9, Beta 1.0, Release Candidate 1, Release Candidate 2, etc… Once all features of a release are complete we move onto the next release with more features, not including the ones already “done” in previous releases. It would be somewhat similar to this progress report.
For example, this latest Weekly Update #96 could have the following progress bars as an example:
(some progress bars are missing, ignore that )
All this sounds somewhat arbitrary but it would be focused on progress done rather than delays. I understand that the smaller the team the more impactful delays are because when one of you is focusing on fixing an issue other things are put on hold. Also there’s the issue of interdependent systems: most of the work happens on the back-end and there’s little to show simply because things aren’t connected yet, and only at the very end do things come together and backers can actually see the result and exclaim “finally, progress!”
Don’t get me wrong, i love reading about the insights of internal development, it makes me feel connected. But i feel communication could be more interesting perhaps? What do you guys think?
For assets it might be doable, but for programming, all tasks being interconnected to each other, you’d end up with a real mess, with some weeks some tasks making progress, others going backwards, new tasks added while others removed… and there are still a lot of things that aren’t even set in stone, design wise. For example, we haven’t figured out controls and weapons management for capital ships ( although we discuss ideas in our weekly meetings ), so it’s pretty much impossible, until we experiment, to say how much work needs to go into that task.
For example, this week I was working on finalizing missiles code. I hit something unexpected - retrospectively it makes sense, but if you asked me a month ago how much work would go into missiles coding, I would have underestimated it due to this - when a missile spawns, it technically lies inside the bounding box of the parent ship, making it collide with it instantly ( and explode ). So I needed a system to ignore collisions with the parent ship for a short duration. It ended up taking a few hours to implement it, and it was totally unforeseen. And that’s no exception; for every single feature we encounter problems related to the technical implementation, which we had no way to estimate in theory.
Even though the example lists more information than we got until now it doesn’t need to be more.
Instead of a date for say Alpha, you give a percentage.
You can even calculate it with an estimated release date. This allows you to give out the estimated release date without naimng it.
Still. Delays will be somewhat noticeable with progress slowing down and it is essentially simmilar to giving dates… and that didn’t really work out.