A Massive Heisenbug Appears.
No, I don't think this is "bad news", or any sort of gist in that direction.
But I'll cut to the chase, yes, this means we will have to delay the release of FleetCOMM; we're backing out on a promised delivery in order to protect the project from a system breaking bug. Apologize all around, and definitely sorry to disappoint.
Long story short; I'd rather be late on delivery, and I would rather delay a project with a smart fix, instead of shipping a harmful bug to our patrons.
However, with failure always comes a challenge, and it's best to show what kind of challenge our software must overcome.
I'll try to avoid sounding too technical (and hopefully, there are some patrons who have some programming savvy, I'm sure they would completely understand what mistakes I've made.) This code structure represents the core binary data that's used in the entire FleetCOMM engine. It's used for all game objects, virals, beams, missiles, you name it, all right here.
Unfortunately, this structure is not completely portable. Example, fleet editing data, and fleet maneuvering data generated on an ARM processor may or may not translate its data properly on Intel processors. Our mission for this game includes having game data that's fit for sharing, and fit for a networked environment. Players on any processor should be able to share their data with any of their friends on other operating systems.
I do not want to introduce this kind of hazard to a networked game, nor even the single player campaign, where players will be sharing fleet maneuvering data across multiple architectures.
So what does this mean for the project? A complete overhaul of our core data, and all functions tied to it. This will require an intense coding effort, and I do not want to hold my breath and try to ship this in 4 days.
As a former code grinder for an unmentionable marketing company, I've had enough forgettable experiences where "code had to be shipped, no matter what". I refuse to serve a bug to my patrons, especially when I have a fix that is viable, and can be accomplished given more time.
However, with software casualties comes a new set of opportunities;
1. By re-rigging and re-initializing core data, I am able to find solutions to make the game for a networked engine that's even simpler. This fix will actually be less code, compared to our current engine; I'll be using some well tested technology to help me kill this heisenbug.
2. The extra time needed, and the coding operation will give me enough of a stable build for Linux, Mac and Windows. Not only does this fix allow me to transfer game data on any of these platforms, it will also allow me to create a networked engine that operates cross platform (ie; Macs playing with Penguins playing with Windows). So by killing this bug, I gain more features. I like that.
3. All of our other assets are already made; music, character animations, planetary environments, atmospheric environments, and particle systems. Only the codebase remains to be completed, which gives our project a safer base for solving our system wide bug. Our artists and musicians have already completed all their work.
I hope this does not propagate any further frustrations with our patrons; and again, I have to extend my apologies for letting you all down. (I'd rather not share how pissed off I am about this, I can only blame myself for the oversight). However, with the recent delays, upon delays coming from Kickstarter projects in general; I feel it's time to take a stand. If I make a mistake, and it causes a massive delay, I might as well present the problem in full, in the spirit of transparency and accountability. I also should present the solutions I take, and not simply hide in the dark.
I'm not scared of failure, and I'm not afraid to show it. Our patrons come first, and you deserve to have honest reports on our progress.
Will report back early January, 2013.
-Slade Villena, Lead Engineer, Mercenary Games