To see this working, head to your live site.

Just curious

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?

4 comments

4 Comments

Yassin Mohali666

Dec 25, 2022

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😁.

Per Holmes

Dec 25, 2022

Replying to

Hi,

That's pretty much the idea. It's a little logic tree. You create a Happiness < 20 and wire it into some important event that requires that. It's modeled after these learn-to-code things for kids, for example the Disney/Facebook one where you click these puzzles pieces together. They're even called puzzle pieces in the code.

That is actually what the whiteboard was in the beginning, but everybody expected it to the a whiteboard, i.e. 100% time-based left to right, so we had to align the app with the universal intuition. But it means that we lost this kick-ass way to model the logic of the story.

We now already have all of this in the code, exactly because we knew it would come back, and what's holding it back is more pedestrian, that we need a new selection model in the app, because it's buckling and can't handle adding more areas. Shot Designer already has this new selection model, and it's not difficult, but it means rewiring a lot of existing code for it, and it will take time and crashes to do. Basically anything new that need a selection state is on hold for this.

Yassin Mohali666

Dec 02, 2022

Wow! That's so cool!

Per Holmes

Dec 01, 2022

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.