Heh, not so much magic. Those libraries are meant to be glued. Some less known publicly available engines use that approach already (without nodes), and there are many gamedevs who use it in their in-house tools.
[this turned out much more elaborate than planned. It’s a big topic :)]
The grand goal is that anyone can at least try to make games, or participate some part of game making process without investing months or years of their time getting familiar with the very basics. Unity, UDK and the like fall roughly in the same category, but they are rather unsatisfying for game programmers, and on top of that they try to lock you into their proprietary systems.
Playing with ICE nodes was probably the most fun I’ve ever had, but it was deeply disappointing that I couldn’t really do anything with that knowledge other than some flashy animations. Probably my biggest advantage now is that I’m primarily interested in the node logic and everything else revolves around it. It’s not just an afterthought, and I’m hoping to apply it as widely as I can.
Flakes will allow users to get used to the system inside Blender without ever touching the game engine. The same skill set translates to the game world quite easily. It will also be very convenient to experiment with effects and behaviors right in the viewport and later drop them into your game with very few modifications.
Even in the best case making games is still very hard, and it’s impossible for me to make a convenience system that works for all game types. Instead I (and hopefully others) would make basic frameworks for different game archetypes, which users can slowly peel open and extend to their needs. All nodes can be opened to see how they work, and once you understand them, you can easily make modifications. Granted, you can do the same with syntactic code, but the learning curve and user experience is entirely different with nodes.
Nodes are very modular, and there will be a lot of different building blocks that users can mix and match. People can also collaborate across different game projects. Someone might do an AI sytem for their game and someone else might grab it and customize it for theirs. There absolutely needs to be a central repository for user submitted content and the gui must have direct access to it.
Basic types and methodologies should be loosely standardized to keep things compatible with each other.
The big caveat is that I will be using an approach that is quite different from what people might expect from a “game logic” editor. Everyone will have to learn a little bit of programming theory, adopt a certain mindset and maintain some degree of “methodological rigor” if they wish to use it beyond the basics. Without that it’s not going to be pleasant for complex games. I’ll do a writeup of how I expect it to work at later time.
My biggest worry is that people who try it will try to use it without learning the basics first and quickly conclude it’s crap when they can’t do something the way they want.
It should be obvious that this is not a short term thing.