Construct 0.99 (unstable) released
We finally made the 0.99 testing release - and as expected there were some serious problems with it, since a huge amount of code was changed for this build. So we'll follow up with 0.99.2 with a lot of fixes in a couple of days, which should be a stable build. If you haven't read about it yet, 0.99 introduces new 3D features (3D mesh distortion, a mesh editor, and Z elevation for sprites), new project bar organisation, and controls to manage the usage of VRAM in your application.
The road to 1.0
The next major build release of Construct will be 1.0. We have now implemented all the features we want for 1.0, and until then, we will focus solely on bug fixes. There are around 150 open items on the tracker, and through the 0.99 minor releases (.2, .3, .4...) we will aim to get these as close to 0 as possible. Once we're satisfied with the bug fixes, we'll release version 1.0!
Beyond 1.0
After 1.0, we will continue to maintain the 1.0 branch with bug fixes and minor features, but we will change focus to start work on our next project: Construct 2.
As you probably know we're all volunteer student developers, and we've essentially learnt how to program properly in developing Construct, a huge and ambitious project which has been, overall, a success. However, in our relative inexperience when starting the project a couple of years ago, we made some poor design decisions, such as how to lay out the overall structure of the code behind Construct, and the technologies we used. As a result, we've ended up with some difficulties in maintaining code these days, and given our much increased knowledge of programming from our experience developing 1.0, we think we can do a lot better. Further, new technologies have since become available - like the MFC Fluent UI system - which would be a big step forwards for the editor usability.
So the plan is to rewrite Construct 2 from the ground up. This isn't as epic a job as 1.0 has been: parts of Construct as it is right now, are very well written, like the new renderer and project bar. We can just lift those directly to the new codebase and reuse them with very few changes. That also eliminates the many hours of debugging and testing that has gone in to those areas. Also, given our experience with 1.0, we should be able to write code faster with less time spent on debugging and back-and-forth changes. This also makes it possible to involve a whole set of new technologies, such as an OpenGL renderer, unicode, ports to other platforms, cross-compiler SDK, XML/folder-based projects, even more 3D features, and so on.
The last thing we'd want to do is shoot ourselves in the foot long-term by trying to coax the current codebase in to doing things it was never designed to do, and that seems to be common in the software world. Short-term, we will probably fall behind our competitors as we work on it, but long-term, we'd come out with something truly kickass And it always pays to think in the long term. The downside, though, is with such a complete rethink, it's unlikely .caps from 1.0 will be able to be ported in to Construct 2. Importing the old .caps would mean making 2.0 100% backwards compatible, including the dubious design considerations, and impede progress considerably. I know this will frustrate some people, but we're not dropping the 1.0 branch - we will continue to maintain it. Plus, it's necessary, for a clean, fresh start.
If we do it right, we won't ever have to have another rewrite after 2.0. Everything will be upgradable from there in to the future. And the future is what we want to be thinking about