blog

[loud noises continue] (2025-30 weekly post)

this week, my work on the three daughters fragments continues. bc im still early in first drafts, i dont know where i am with it, or where im going. isnt that such a wonderful thing, no rules but the generative?

i should be looking at places to submit my girl novel, and yet…

im not

my three daughers devlog 1

at the start of working on my three daughters, i wanted to put together a sort of planning document on the project: its goals, its affect, how i want to put it together, so on. in short:

• a (long form) piece of interactive fiction i’m calling (with no apologies to the more widely used chinese term) a web-novel
• written in my favorite, signiture fragments
• the verbs of choice are search, contemplate, and lie

influence

the story’s old, but the idea for how to structure it’s basically a straight line from her story and other sam barlow games: FMV hyperlink games in which you, the unseen character, seek out answers as well as the questions that led to them. this fit perfectly into the story i had because

story

i hadn’t quite the shape of it yet, only the idea, as well as a title and a first line. the title: my three daughers. the first line: I have two daughters, of which I’m very proud. there’s a lot more to the story, subject to change bc im writing it still now, but the whole idea’s already there: the title has three daughters, the mother only claims two. why’s she lying and what about?

fusion

writing a liar is easy, everyone does it, its old hat. what i struggled with more was the second aspect of my narrator’s personality: avoidance. every time i sat down to draft the story, the same issue recurred. either i’d go on to long describing the other’s daughters, the mother’s life, the themes of the story, anything, in order to put off the “reveal” of the obvious third daughter for too long or, conversely, i’d bring the daughter up too soon, immediately crashing the illusion of the book

(of course, aside, writing avoidant characters is maybe the major struggle of my work, but at least im not usually doing first person, where they gotta do it. like all great works of art, avoidant obsessions are never best described by those who bring them into the world)

thus (see title of this part) my current draft for the story: what if we add another person to the mix, a player so to speak. the mother doesn’t want to tell the story and never will, but what if we add someone external who wants to hear it? you, dear reader/player, can be the active participant (i hope it works)

experiential shape

i dont have a sam barlow sized budget or any real interest in video, but i do got wikipedia. the shape of the story’s simple then: split the narrative into nodes, each which hyperlinks out to a few others. users can click on the words that interest them most (of course, the prose will influence this), and the computer will keep track of what they click. as more information comes out, the nodes will expand or change to reflect that. this way my narrator can lie and leave things out, but the reader/player can drill down into the text until lies break

how tho?

1. i’m writing the fragments in a notebook now, with lots of underlines, annotations, and arrows pointing out where text will change
2. eventually, i’ll put this in the browser, my text-renderer of choice, and use javascript to track a lot of boolean seen/unseen flags
3. i’m not yet sure how to store the text once its written. json seems “standard” given this is 2025 and i know javascript, but im tempted by the more heavily structured shape of xml, maybe bc while working i’ve been watching gdc talks on caves of qud. the biggest deciding factor will probably be how to deal with small bits of updating text (ie “two daughters” -> “three daughters”), whose arbitrary shape may be easier to read in xml

issues

• how to type it up: ie, markdown that generates the pages, or straight into code
• length: how long would someone wanna read it?
• save/loading (just cause i’ve never done it before). it might be nice to hash the save data into the url as well, for use with browser syncing and bookmarks
• readers: who will read it

end

not sure if i’ll have many devlogs on this till im further into a coding stage, but its so far been fun. bye bye

[loud noises] (2025-28 weekly post)

this week: an attempt to resume my interactive fiction story My Three Daughters, of which more later. I wanna write out a sort of planning document for it. Thus: a tiny post. Goodnight

weird al yankovich blew his brains out in the 1980s after people stopped buying his record (2025-28 weekly post)

yeah this week’s title is weird, this weeks title is fucked, but i’ve been doing them all as quotes from things ive read or listened to during the week and I completely forgot to look for any this week, so all I got is a quote from King of the Hill i saw at a werid al concert (dont worry im ashamed) which has not left my mind since i heard it. weird al yankovich blew his brains out in the 1980s after people stopped buying his record. this is probably true

but i aint wrote much this week. i’ve had some therapy ‘homework’ (boo) that involved journaling this week, which took up a lot of my bandwidth and, of course, writing hours. so i have been just so woefully unproductive

however: that’s right, this sunday i rode on a plane, which is a place i just can’t stop writing, im always writing nonstop on planes, its near admirable. so there, plane-side, middle seat, i got back into my fun little novella Songs About Men, added a few pages to it. it might be my next project: a fun, entirely unmarketable one, just for myself

anyways, my condolonces to weird al and his family in this tough time. i hope his funeral dirge has something to do with food, or at least a plot summary of some mid movie or television

ants devlog 4: what if an ant could sense when food's nearby?

wait, let’s make use of the tools given to us by default: here’s the commit for this post’s code, on Github

had i thought on this far enough ahead, perhaps we’d have had a PR with many commits, one for each change, but in that idea’s place let’s follow a simple three act structure (out of 5, as you will see very soon our work ends with a large and tragic turn)

act i: setting the scene

before anything else, let’s simplify the vars we use in our ant_move() code: previously, we referenced our current ant’s x and y via their object, but if we want to reference them more often in our movement function, as we plan to, it makes more sense to simplify those to just x and y. after all, its what we’ll mean in this the most

any other code in this area is replacing these vars throughout

act 2: a tired joke about not wanting to remove bugs

this ones simple, and well worth taking note of. in our _init() we added a new variable debug_text, set to a blank string, and we end our _draw() with a call to print this variable to the screen (at the end, so we know it’s always on top of everything). at the moment, we don’t add anything to this string, as we’ve more or less cleaned thing up, but a simple call of debug_text = debug_text .. "whatever we wanna check on" keeps our business on the screen. very nice

also: could we loop thru an array of strings to make this easier to add to? who cares! we can still do anything we want to later!

act three: the actual changes we’ve made

notice!

this is wrong. this is very wrong. the sensing function we make is incredibly functional, but the way we choose to use it is very wrong. we just gotta pretend it isn’t for a bit of narrative. spoiler, howver, this will end up bad

should be simple, right? we have a randomized movement function, let’s slot in some new movement types. under our list of movement options, let’s add an elseif and add in a new function for looking nearby

find_nearby_dots

^^ see that up there, that’s what we’ll be calling our sensing function. interested and detail-oriented readers (of whom, at the time of writing, i have none) will notice this is not in the linked commit. that’s cause i messed up rebasing. i have no desire to fix this, so it stands

that said, we can add the function in whole here now:

function find_nearby_dots(x,y,dist)
   local vals={}

   for i=0,dist-1 do
      local x1,x2=x+dist-i,x-dist+i
      local y1,y2=y+i,y-i

      if(0==i) then
         add(vals, {x1,y1})
         add(vals, {x2,y1})
         add(vals, {y2,x1})
         add(vals, {y2,x2})
      else
         add(vals, {x1,y1})
         add(vals, {x2,y1})
         add(vals, {x1,y2})
         add(vals, {x2,y2})
      end
   end

   return vals
end

isn’t plaintext wonderful! the above is essentially nonsense requiring a day or two of doing math (i have an MFA in creative writing), graph paper, highlighters, coordinate writing, refusing to look up answers because I’m doing this to keep my own creative forces occupied, not to make the most technically proper game. i will not be adding these notes to the page as ive moved apartment recently and dont wanna hafta get me scanner out. in place, let’s just explain the finished process:

in essense, thru guess-and-check i determined that for each new pixel of distance an ant is able to sense, another four pixels need to be sensed around it. i dont wanna go into the formula because i wrote it about a week ago and have since forgot it, but suffice it to say in the local variable lines at the top of the for loop we add or subtract a specific amount from the passed distance to create four new points of ‘vision’. they mirror each other quite well, so we can add them with only a few calculations. as you can see as well, the first loop works a little different in how its mirrored (not how our x and y variables are altered by the loop number: this is what causes this), so we get our points of vision differently

each of these points is added to an array, which is then returned: this is an array of all our senses points

math-brained types might notice this only gives us our outer ring of vision. yep: this only returns our outer ring. this is on purpose, as it adds a bit more flexability: we can use the function to determine what pixels are a certain distance of steps away with this one function or, by calling the function from within a loop, determine all the pixels that distance or less. i like that

(for the moment, imagining myself saving memory wheter I am or not, i’m only looking at the outer ring in code later. but, as shown above, it’s an easy change if i’m incorrect)

(also, not how easily this could be re-written to not need an x and y variable: we could simply return a distance amount rather than an absolute pixel. oh well, i realized that when writing this up. maybe, if it ends up convenient, we’ll change that later)

using find_nearby_dots

in this first paragraph here i’m insulting myself a week or so ago for not understanding how my earlier movement system worked. to skip ahead to the explanation, i was not balancing movement well. i was forgetting that my previous randomization took the option of no movement into account to create more jagged, natural seeming motions. this means that while there’s still only about a two percent chance to move each cardinal direction, there’s now a 92% chance to move toward a sensed food pixel, and no chance to stay put. this means that every frame, of which there are 60 in a second, our ants will move. that’s stupid fast, in practice

back to our ant movement functions, surely we can just slot this into our movement functions, right?? surely this is simple. see line 105 in the github, see our local variable to hold these produced sensed squares, scent_squares. we’ve simply added another branch to our movement if statement, which is surely going to add a “more likely” movement choice, in comparison to our 2% chance movements from before

we use our loop pixels function to loop thru the sensed pixels we’ve gathered and check: is it food? if so, we move towards it, prefering vertical movement over horizontal for the sole reason that i use the computer on my phone a lot, so i imagine computer screens as intrinsically tall.

by the way, does this function move us multiple times each way as written? i think so. i haven’t tested this out visually for reasons we’ll explore below

stop fucking around, show me why this sucks

see that? we move too many times per second. its one thing to swarm. this is something else

for next time, we’ll look into refactoring our movement decision code, so we can fix this