I just saw a report of the enchangements they are planning for Blender 2.5. One of the enchangements was a node graph to create game logic in Blender Game Engine. While the proposal is definitely and improvement over what they have in there, I think in general boxes and arrows are super horrible way to create game logic. Let me elaborate.
This idea has been bubling under for quite a few years now. I've been in two projects where the game logic has been build using some sort of flow graph. While it is intuitive model to create something a bit more complicated than when this do that, the final noodle soups look really horrible and are impossible for anyone to debug.
I have been trying to put the frustration of using the boxes-and-arrows editors into words, abd finally when I read a book called The Back of the Napkin, I realised what was the problem. The problem is that the designers are forced to answer all the questions with one answer.
The Back of the Napkin is about visual problem solving. One of its' ideas is that certain types of pictures answer certain types of questions the best. If the only means to create game mechanics is flowgraphs, then the designer is most of hte time answering to question How. If your level editor also supports some sort of timelines, you may be able to answer the When question too. Trigger volumes give opportunities to asnwer few where questions too.
In all system I've seen so far all these questions are answered using separate tools. This breaks the big picture. You do something in timeline editor and then something somewhere else, even if technically you could be editing the game in one unified view, zoom in when necessary, and build the best picture (and representation) to describe the required task.
Mashing up these different representations is really important to let the designers to get their work done. Trapcode Soundkeys is good example of such mash up. It kind of is against all programmers reason. Draw boxes to get output of an audio analyzer? That's a lot of bullnoodle right there! But it works, its intuitive and you immediate get it. It answer the the questions where and how much really well and you can adjust it easily based on what you see coming in.That is why the idea logic blocks and flowgraphs as main means of gameplay logic must die. Creating gameplay logic is not about logic only, it is about answering complex questions with understandable "pictures"!
P.S. Yes, the MAX/MSP/PD crowd gets some of these things right, but not all.
I am kinda stuck on this as well. I don't think that noodle soup is the right answer for exactly the reasons that you describe, but I think that MITs scratch and GameMaker come closer to a good solution for graphical programming than max/msp/pd do.
ReplyDeleteBoth of the above have at a base level the concept of objects and events, and in the case of gamemaker, the opportunity to drop into scripting at any point to describe more complex mathematics.
While gameMaker doesn't support object encapsulation (one of the things that makes max/msp great), scratch has some experimental branches that are starting to play around with it, and it is wildly complex and amazing in terms of results.
I don't think that these systems do anything to make debugging less of a chore, and I would even argue against them as prototyping environments in most cases. But they are interesting as a gateway into "real" code.
Even if you are able to inject some code in there, it is still a bit a hack :)
ReplyDeleteI would like to be able to organize stuff based on different point of views. Sometimes the best way to organize data is time, sometimes ordered list. Sometimes the data could come from a query and you may want to score it based on something, etc.
None of that is really answered by any of the system I've seen. They concentrate on building data flow and logic causalities.
Here's a video of my old experiment: http://vimeo.com/10461028