51 lines
1.7 KiB
Plaintext
51 lines
1.7 KiB
Plaintext
2023-10-23
|
|
|
|
i think the story is "done"
|
|
|
|
i had grand designs for a very complicated narrative structure
|
|
but i ended up scrapping 99.9% of that in order to just finish it.
|
|
|
|
using rec as a database i think is fine
|
|
and i think i would do it again.
|
|
but somewhere around 50/60 nodes,
|
|
i started to become unable to keep the whole story in my head
|
|
all at once.
|
|
that is,
|
|
i would look at the graph
|
|
and couldn't immediatly map it to a part of the story
|
|
in my mind.
|
|
i think i could fix that by having the graph
|
|
include both the id and the name?
|
|
but also i suspect that at that size,
|
|
the graph simply isn't a great tool any longer
|
|
for assessing the shape and flow of the story.
|
|
|
|
the recfile itself started to become kind of had to navigate at that size too.
|
|
i created a tags file to help navigate,
|
|
and added some syntax highlighting,
|
|
and make some snippets,
|
|
and that helped a little bit with the cognative load.
|
|
but also i broke the story at least twice
|
|
by accidentally creating a node with a non-unique name.
|
|
so i think that if i were to do this again,
|
|
i made make a 'recins' wrapper
|
|
in order to enforce data integrity
|
|
instead of just creating data by hand in the recfile.
|
|
|
|
i also think that i might create a new schema
|
|
to include 'links' or 'branches'
|
|
because i think elevating that information to its own field/value
|
|
could make it easier to export the data into, say, twine
|
|
or some other kind of text driven engine.
|
|
|
|
there was at least one point
|
|
at which i wish i had the ability to create a 'data node'
|
|
and then query that for a value.
|
|
e.g. "if has_visited? then goto(id) else goto(other) end"
|
|
this might be possible in recutils 1.10
|
|
if jem is successful in adding scripting to recfmt.
|
|
|
|
in summary,
|
|
it worked well enough!
|
|
but started to become a little unwiedly toward the end.
|