This is where information about the independent project based on the original proposal of the Google Summer of Code node engine can be found. This is an effort of me, Sven von Brand, the student originally participating in the project.
The original project didn't go beyond the mid-term because of reasons related to mentor-student communication and work together. This project doesn't follow nor does it currently have the mentor support, but the possibility to continue independently the project was given by Ton Roosendaal. This project will still need future involvement of Blender Game Engine contributors to have the possibility of it being integrated into the main version of Blender.
Why it didn't pass the mid-term
First this project is extremely different from most projects as it is not an extension on current functionalities and it is not an integration of a new functionality in Blender. It is a development environment design and implementation effort, that in case of being successful would replace the current Game Engine development interface and the development process to make interactive content completely.
This is my interpretation of what led to the project to be rejected.
Communication was bad between me and my mentor, because of time zone differences, my mentor having very few free time to dedicate to the project and strong differences in opinions.
The view of the project was different in objectives for me and my mentor
The development methodologies we were used to apply are different and required different backgrounds
The required process to develop the new functionality was heavily a technical implementation problem for my mentor and for me it is a user driven development, which requires software engineering to be applied.
The development process and design decisions for me should have followed a Top-Down design (first language definition and then technical implementation though iterative designs and prototypes, redefining the language as needed). The process proposed by my mentor was a low level technical design before starting development, this needs for someone who's an expert at least in the technologies being used or the system being build.
It is proposed to continue work on the Language Design Document from a user standpoint, do an Architecture Design Document, then have an iterative design and prototype development stage.
1) The Language Document will describe how a program interface can be designed to make a visual component oriented language. It will be revised and further developed during the iterative design and prototype phase.
2) The Architecture Document will describe the elements the software will have, it will describe how the different elements relate, and it will have some technical decision recommendations.
3) The Prototypes will implement the functionality, each prototype will run and will try to solve different questions about implementation. After each prototype implementation changes will be made to the design documents, if needed, and a new objectives for the next prototype will be made. Prototypes should extend previous prototypes unless there's a good reason to discard them.
This work will extend until the end of the year and in the first prototypes a working visual interface won't be the priority. The prototypes will rely on a way to create the different elements and run the elements created.
From the work done, the technical document will not be developed further or should be considered part of this effort, the language design document will be developed further and the proof of concept files maintain their validity.
Help will actively be searched after the prototype phase has it's first results, but help is always well received if someone wants to participate in the project. It must be noted that this project might never be integrated to Blender and it is currently an independent effort, that hopefully has good enough results to be considered by people inside the Blender Game Engine development community.