Hello everybody👋. I'm just curious; I've noticed you guys mentioned a relationship graph multiple times, mainly for its dependency graph feature. But, if it's not just a dependency graph, what is the rest? What other relationships between objects can this graph showcase?
top of page
bottom of page
I literally just had a quick, out-of-nowhere brain blast. What if the dependency graph in causality had a similar structure to that of scratch's? Scratch is a popular block-structured visual programming language known for its immense simplicity. Basically, in scratch, there are objects (backdrops, sprite, etc.). At the start of a project, these objects don't do anything, they just exist. To make these objects to do something you have to use commands (it, basically, tells the computer what that object will be doing). But that's not the full story, because you can't just have an object do a command whenever, wherever. Everything has to make sense. Here is where you set rules. For example; when (happiness) = (20), say (I'm depressed). Of course there is more to just that, but this is the bare bones of scratch. Anyway, this is just a weird idea, that I thought would fit causality perfectly😁.
Wow! That's so cool!
Hi,
This is the right question to ask. The answer isn't 100% easy.
Basically, we need multiple graphs. We need a dependency graph (we already have one in the data). We also need a mind-map that's a visual version of the same hierarchy as already exists in research. We also need free-association maps, basically just stuff people can randomly connect to indicate some kind of connection between things. And then we need some kind of relationship modeling, that shows that certain events happen along a certain kind of relationship. Finally, we need relationships to be a real thing in Causality, because you currently have the make the impossible choice of which character "owns" the relationship, so you can pick a folder for the beats.
The problem is that you'll want to make connections across all of these things. You'll want a particular beat in a relationship to be dependent on a certain plot event in a murder-mystery dependency graph having happened.
And that means that all of this can't be 5 different graphs. It HAS to be one graph, whether it wants to or not.
So what we're making is a witch's brew of all these maps together.
* A dependency graph is easy. It's just beats or tags or targets with lines between them indicating the order they have to happen in. Then you'd make a target for happiness to be over 80%, and wire it into a beat where his happiness plummets, which would only work if he's happy before the crash.
* A free association map is also just objects on a board, maybe also beats and images, with lines between them indicating abstract "association".
* A relationship map would be boxes with beats in them indicating the events of the relationship, and wires going to the characters that are part of the relationship. I should say that this isn't settled, but one possibly way.
* A mind-map is really the odd one out. Everything else is just stuff with wires between them. A mind-map has a strict layout. The idea I'm most attracted to is that it's multi-root mind-map, where instead of having just one tree-trunk, you only have branches. If you have a plot thing that's a subfolder in research you put just that subfolder into research and tell it to render as a mind-map. Then you get a mini-mind-map of just that subfolder. Then mind-mapping can coexist with everything else. You could just in and make any leaf in the mind-map link to an emotion target, or have free-form association etc.
Point is that having all of this be separate maps creates walls that are a problem within minutes. All modes have to be available at the same time, because you need to criss-cross between them. I think it's worth forcing them together in the same canvas, even if it involves compromises here and there.