NOTES

=== 2020.02.01

# lazy evaluation of file tree
# pick up and drop files
# inspect file contents
# executables
# attribute markup
# error codes

=== 2020.02.02

# locked files

=== 2020.02.06

maybe 'executables' operate on adjacent files, when triggered?

the other alternative I thought of and partly implemented was files
that themselves take up multiple slots, and dropping files on 'parts'
other than the first drop into the slots.

=== 2020.02.13

What is the timing regimen?

When you perform an action, generally speaking, the state is updated
and redisplayed immediately. Asynchronous scheduled actions happen
once per tick, which lasts something like 100-300ms or so. The
intention is that ticks happen on a schedule independent of user
input, tied to the time the program was initialized at. This means
that the first progress-bar update on a long running action might
occur as late as one full tick from the time of user action, and as
early as immediately after the action. The user interface state should
nonetheless change immediately following the user-initiated action to
indicate that the progress bar *exists*, even though it may stay at
value 0 for a full tick.

=== 2020.02.18

What do I want gameplay to look like? It's going to consist of
deciding what sort of obstacles exist, which automation, building,
arrangement, etc. remove.

I could make it more difficult to move around 'heavy' files, or, well,
the natural thing that fits with the filesystem metaphor is to make
'heavy' mean 'large in bytes'. There is also the possibility of
security levels.

How is moving around heavy files accomplished, if not by mere
picking-up and putting-down? I had some thoughts about the idea of
creating paired markers, where maybe if you feed one as an argument to
an executable, it can send a file to the other. But this is a fairly
strong mechanism, assuming the idea is that you can carry one marker
arbitrarily far away. Something that better respects the 'spatiality'
of the tree structure of the filesystem is making you transport it one
step at a time. Maybe executables can send a file up the hierarchy, or
forward and back inside a directory.

Does this create a bottleneck on the way up? Perhaps there are two
distinct operations, (1) and (2):
<<<
move this file up to the parent dir, so that it is
 (1) before
 (2) after
the directory in which it was formerly contained
>>>
and then maybe nearby executables can be triggered by that.

That suggests that executables should
 (a) be able to consume files from either side, and
 (b) be able to be 'woken up' by files appearing next to them

Some care might need to be taken about the ordering of execution of
such wakeups.

=== 2020.02.19

Are there like piles of undifferentiated items, where attempting to
pick it up gives you one of the many items? How do drops work? Do they
coalesce if dropped adjacent to the pile?

If executables send a file up, how is it communicated effectively to
the player that this has happened?

Should there be some way of cancelling long-running executables?

How could I get extra inventory slots? What does picking up in that
case mean? Use it like a stack or something? Should I already be using
z/x instead of space for pickup and drop?

different subdirectories (or network hosts) have different color
themes/fonts/background music/sound?

Where does charge go if a file is divided? Or is that part of the
puzzle, maybe --- maybe forbid a nonzero charge file from being
divided. This makes some pragmatic sense, since probably executables
have charge, and it's 'data files' that are going to be sharded or
whatever.

Brainstorm opaque mysterious vague file types?
 link
 address
 contact
 medical
 rating
 review
 invoice
 payment
 art
 image
 photo
 vector
 music
 script
 savegame
 model
 mesh
 graph
 archive
 backup

=== 2020.02.22

Should I make charging/uncharging free?

How does one go about synthesizing instructions?

Are there maybe 'typed' directories with schemas, where appropriately
typed files go in certain slots?

=== 2022.11.06 META: (:id e426f5af-a7ab-4a61-9179-a5b514959150)

Brainstorming resource flavors and/or names:
cpu cycle --- cycle, comp, iter, instruction
ram space --- cell, file, byte
filesystem space --- inode, node, byte, file
text space --- glyph, letter, char
graphics/UX space --- pixel, rect, sprite
network byte --- transmit, bandwidth, packet
permissions capability juice --- power, perm, acl, status, cap

=== 2022.11.13 META: (:id 5618a941-08e0-4321-afb7-8ea2458cd75d)

Doing some refactoring. Copied over some code from the webgl "text
mode" renderer from smol-vm. Remaining work to do
 - Make it so that we don't recompute the text page every time from Screen's
   internal representation, but instead have Screen's representation be what
   the webgl wants to consume.
 - Make webgl consume a texture instead of a big uniform, maybe?

=== 2022.11.14 META: (:id beb46451-4ced-4447-ba78-a893592a1cf4)

 - Made it so that Screen's representation is what the webgl wants to consume.
   That is: list of pairs of bytes, first byte is character code, second byte
   is color, fg + 16 * bg.

 - Made webgl consume a texture instead of a big uniform

=== 2022.11.24 META: (:id bc25c232-1939-4ed7-a346-2d6f5870a782)

From above:

Q: If executables send a file up, how is it communicated effectively
to the player that this has happened?
A: Maybe have the ".." entry blink?

Thinking about obstacles to automation that need to be overcome.

What are some basic operations?

- Moving files around
- Moving resources around
- Creating/destroying files that can do operations automatically
- Obtaining documentation
- unlocking files (if you have enough permissions)
- triggering execution of other binaries
- view hidden files (if you have enough permissions)

So what are some "binaries" I can imagine the player obtaining?

- miner/charger
- move-up
- run
- compiler
- unlock

Q: What if binaries can send messages to one another, and the player
triggering execution is just one such message?
A: The code for handlers for messages would be stored in specially
named subdirectories of the binary. One could imagine at some later
stage figuring out how to insert primitive message-sends into the
keybinding directory.

Q: How does the "compiler" work?
A: It expects a message to specify which binary to build.

Q: What does the end of the game look like?
A: Maybe gaining root access on some remote machine, being able to
turn it off?

Q: A thing I've noticed while trying to implement virtual/procgen'ned files is
that there is a slight conflict with my cache of item locations. What should I do?
A: For a minute I thought I should embark on a big refactor to make locations part
of items, but now I think that's unnecessary, maybe.

Perhaps I just need to wrap querying the fs for the location of an
item, and intercept any requests for yet- unreified virtual ids, and
compute their location lazily instead. This will mean continuing to
wait for actual fs changes to reify anything. As a consequence, if I
do an insert/remove inside a virtual container, I will need to reify:
 - the container, because its state (i.e. its contents) has changed.
 - the subsequent siblings, because their induced state (i.e. their location) has changed.

=== 2022.11.25 META: (:id 7d13be6b-1a26-410a-a712-c7e81f9bc736)

Some ideas about execution.

I considered the idea that binaries don't directly operate on files in
their environment, but rather have to slurp up files, operate on them,
then spit them back out.

For this I might imagine that binaries come with subdirectories, like
code/ and data/. All instructions would be in code/ and slurped
arguments would temporarily go in data/.

Or do I want a wide variety of different "cpu"s each with their own
instruction sets, maybe? That might give some grist for the
factorio-esque production treadmill.

What kind of specializations can I imagine?

- resource-transfer
- large-file motion
- file creation with arbitrary name
- file copying

=== 2022.11.27 META: (:id 4dc9a488-c596-4955-a81f-7a390ab1fe2a)

Two outstanding bugs/infelicities that might require some rethink:

 - 'mounting' the virtual file system at any place other than the root
   leads to it being mounted twice accidentally.

 - Operations that modify items don't automatically reify virtual
   things. I fixed known bugs with calls to reifyId, but this is
   error-prone and bad.

=== 2022.12.04 META: (:id 6019e592-4c63-407d-92f3-ad71f0f27260)

 - I think I've fixed most "Operations that modify items don't
   automatically reify virtual things"? Not sure, probably should have
   made some red test cases.

 - I wonder if the "directories remember their position" feature
   should be a QoL thing that you don't start with and have to acquire
   during the game.

   Come to think of it, I'm not sure if that's robust against remote
   insertions/deletions either. Maybe I should have some notion of
   invisible "mark"?

=== 2022.12.17 META: (:id 5b779cee-7577-4c68-a4da-031b6fab2b13)

Q: Why can't I do something like
<<<
  if ((window as any).f !== undefined) {
        ((window as any).f)(state);
      }
>>>
in reduce.ts for KeyAction.debug?
A: The problem is actually the concrete name `f`: in the path
node_modules/immer/dist/immer.esm.mjs
I find the code
<<<
function f(n,r,t){var e=o(n);2===e?n.set(r,t):3===e?(n.delete(r),n.add(t)):n[r]=t}
>>>
so that function exists at the toplevel already. I'll just use ff, I guess.

=== 2022.12.18 META: (:id 15060dca-deac-4ae6-acb0-9127b94d8794)

Some thoughts on puzzles/secrets:

I like the idea that there are resources or other structures hidden in
items. One source of this can be things that appear to be plain files,
but are actually openable, and can hide an arbitrary amount of
interesting stuff within. Another source can be files that have
resources on them, but which are not rendered in their current state.
For example, I think labels look nice without resource rendering, so
maybe you toggle label into a plain file and find that it has 50cpu or
something.

=== 2022.12.26 META: (:id 595a0700-3d0c-44eb-bd7f-4902af138f4d)

Q: How'd I get a list of common surnames?
A:
https://forebears.io/earth/surnames
cat /tmp/surnames.html \
 | perl -pe 's/<a/\n<a/g' \
 | perl -lne 'm,<a href=".*">(\w*)</a></td>, and print $1' > surnames.txt

=== 2023.01.03 META: (:id 3be55015-990d-4a5a-8736-c9bf4c3f2f2b)

Q: Do I notice any tearing difference during animation if I call
  SDL_GL_SetSwapInterval(...);
with 0, 1, -1, per
https://wiki.libsdl.org/SDL2/SDL_GL_SetSwapInterval
?
A: Not really.

=== 2023.01.03 META: (:id 2acb7c94-a364-4fbe-b537-401e87ad264b)

Q: What's the general narrative flow of the game?
A: I think I'm going to try to first imagine a reasonable complete
narrative that works without introducing the idea of networking, even
though I think that would be separately fun.

"Tutorial" phase

- Show off unattainable secrets
- Guide through basic mechanisms
  + Navigating through directories
  + Executing binaries
  + Some comprehensible error messages
- Culminate with getting access to some basic stuff

"Manual" phase

- Goal is to construct certain object which grants access to next phase.
- Requires searching through some procgen filesystem for resources,
  configuring some already-available tools to transform them, and
  gaining access to another directory.

"Semi-automation" phase

- Goal is to construct certain object which would be somewhat tedious
  to construct manually.

- Requires transforming found objects in several phases, or
  "disassembling" and "reassembling" them, at significant scale.

- Could explore both of the following:
  + automation that needs to be brought "to the site" where the resources are,
    because the resources can't be moved.
  + automation that --- for permissions reasons? --- requires transport of resources

"Automation" phase

- Goal is to construct a certain object which would be far too tedious to construct manually.

- Similar to previous phase but with increased scale

- I want more development in the complexity of the engineering in this
  phase, but I'm not sure what that looks like yet.

"Endgame" phase

- Goal is to construct an object which grants root access to system.
- Try to think of some story reason for needing this.

=== 2023.01.05 META: (:id 5027f8a8-135e-42f4-b70c-de1921df86d0)

Q: Framebuffer example?
A: https://docs.gl/gl3/glBindFramebuffer