let it leave me like a long breath

further progress with the history generator

here's the initial html output, that's just dumping all history data into a lightly-formatted html file.

here's where it's at now, with most references between interactions linked, but with no actual index of events (looking at the actors list just gives you their state, not a list of every event they were involved with)

still, it's getting there. i mean, obviously the dataset i'm using right now isn't exactly the most robust, but the output data format is getting into shape. like, i have a lot of plans for how to use this -- games, etc -- but probably the most immediately-reachable one is that i kinda want to set up some kind of automated tumblr, where i generate some gigantic sprawling universe history and then have it start by posting a single random event/actor/object/location/whatever from the whole thing, tagged with its references to other things in the universe like "this is the plant (whatever), which grew in {location:4632} during {time period:45462} and was used by {this culture:12835} as a dye", and then let people send in asks that are those tagged chunks to get whatever thing that is. kind of slowly uncovering the structure of the universe.

and obviously in terms of content i'm nowhere near that being interesting to do, but at least i'm getting closer in terms of generating a properly-formatted output.

actually with this it's been a mix of feelings, because this is something i've wanted to do for ages (years and years) and always figured it would never really happen, or happen, you know, in the vague-and-hazy 'future'. but now it's happening now. and it kind of sucks? i mean that is not really an output that's particularly interesting to read. but also, that's a dataset that i've been working on for all of a week, on a parser that i'm still working the kinks out of, so you know it's important for me to not compare this project, with its week of actual work plus maybe a few months of infrastructural work, to something like dwarf fortress that's been under active development for the past decade.

anyway you know, it's got a lot of potential. just gotta work to make that potential into something actual.

VOID {
  desc: in a time before time, there was the endless hungry void
}
_ {
  desc: ILL-ADUMMDER, god of fire, burst into existence
}
_ {
  desc: the flames of ILL-ADUMMDER's body scorched the void, and the ash became a host of burning demons, eternally praising it
}
_ {
  desc: the demons created the slave race of celestials to perform labors
}
_ {
  desc: the demons created the slave race of celestials to perform labors
}
_ {
  desc: the celestials rose up in rebellion and bound the demons in the web of IMM-ADUL
}
_ {
  desc: ILL-ADUMMDER created the slave race of celestials to perform labors
}
_ {
  desc: the celestials rose up in rebellion and bound ILL-ADUMMDER in the cords of AZ-NIH
}
_ {
  desc: the celestials rose up in rebellion and bound the demons in the chains of ADORELTZOL
}

Yes This Is A Coherent History

i mean it's a start, and i've gotten some of the worst kinks ironed out, but it's both very janky in terms of simulation and very simple in terms of data.

you start off emitting a pulse of 'basic' mana, which i'm going to codify as M 2 1 1 for reasons that will become clear soon.

the first tool is a beam splitter, which separates out your mana polarities. so M 2 1 1 splits into two mana bands of M 1 1 0 (hard mana) and M 1 0 1 (soft mana). the hard mana bounces off the splitter surface whereas the soft mana passes through, allowing you to isolate the components.

the second tool is a mana collider, which merges two beams of mana. it operates as such: M g a b + M h c d = M (g + h) (a + c) (b - d), and can only be performed if g == h. this means soft + hard = base. but this isn't commutative, so hard + soft = ???, a different mana type w/ the equation M 2 1 -1. i'm gonna call this kind of mana 'anti-mana'. (you can also do soft + soft to get M 2 0 0 ('active' mana) and hard + hard to get M 2 2 0 ('still' mana)).

you can then combine that generation of mana, in sixteen different ways (base + base, base + anti, base + active, base + still, anti + base, anti + anti, etc etc and so on), which will get you nine distinct frequencies of third-generation mana. and there are eighty-one ways to combine those nine frequencies, with twenty-five distinct frequencies of fourth-generation mana. and so forth onto infinity.

but also, anti-mana is interesting, because if you decompose it you get M 1 1 0 (so, hard) as well as something new: M 1 0 -1. that's a new fundamental mana frequency, which we'll call 'antisoft'. with antisoft you can create some new mana flavors, by combining a soft/antisoft pair or an antisoft/soft pair. this means you can build a total of six second-generation mana frequencies: base, anti, active, still, and 'sharp' and 'dull', from the soft/antisoft pairs. (an 'antihard' mana frequency theoretically exists but isn't reachable, because the combination equation is noncommutative in the second value, and so it can only produce antisoft. if it was noncommutative in the first value, it would only be able to produce antihard and not antisoft.)

what's interesting about that, is that still mana (M 2 2 0) matches up with hard mana (M 1 1 0), and sharp mana (M 2 0 2) matches up with soft mana (M 1 0 1). then dull mana (M 2 0 -2) rounds out the triad of basic mana flavors by lining up with antisoft (M 1 0 -1). so those are kind of the basic building blocks of all mana frequencies.

(splitting mana is actually more complex than above, since there's a general rule that basic mana is kind of a special case for. you can't split anything that has a 0 in one of its components, since that's already split. a hard mana pulse hitting a splitter will just bounce with no decrease in intensity; likewise a soft mana pulse hitting a splitter will just go through. if both components are nonzero, then it decreases generation and splits the beam into pairs. there's also a fourth case, where both components are already zero (active mana is M 2 0 0). in that case, the beam intensity is halved, but the output is just two beams of the same generation. so where basic mana decomposes, active mana takes both paths without decomposing.)

the REAL question is how to make the mana flavors do interesting things without making them entirely arbitrary

so i've been thinking about making an index of all the various two-week projects i've been trying out, since despite having made a bunch of posts about them, i had never really made a centralized index, or even a list of what they all were, even for my own use.

so this is that list.

---

1. (nov 1 - 15): procedural generation / possibility space, 'nemesis system'
   
   • data files / output
     
   • more complex data files
     
   • basic actions running
     
   • final reportback
   
   
2. (nov 16 - 30): zombie web game
   
   • final reportback
     
   • 'game'
     
   • (also got nil values and more complex lookups working for the nemesis setup)
   
   
3. (dec 1 - 15): (nothing)
   
   • final reportback
   
   
4. (dec 16 -~31): hex embedding for graph generator
   
   • initial test to final result
     
   • final reportback
   
   
5. (jan ~1 - 15): locust tf twine game
   
   • demo
     
   • final reportback
   
   
6. (jan 16 - 31): hex shapes, lock-and-key generation
   
   • initial shapes
     
   • basic collision
     
   • more advanced (broken) collision
     
   • basic (working) collision
     
   • fewer artifacts
     
   • coastline generator
     
   • ugly outlines
     
   • more complex shapes (broken)
     
   • more complex shapes (working)
     
   • lock-and-key placement, one-way exits
     
   • treasure
     
   • final reportback
   
   
7. (feb 1 -~15): rust opengl rendering
   
   • final reportback
   
   
8. (feb~16 - 28): procedural generation / possibility space, plant l-system rendering
   
   • haskell combinatorics code problems
     
   • ABOP renders
     
   • random plant renders #1
     
   • random plant renders #2
     
   • final reportback
   
   
9. (mar 1 - 15): procedural generation 'nemesis system'; predicates & mutations
   
   • predicates; mutations
     
   • here is where i got really stuck on the combinatorics problem
     
   • final reportback
   
   
10. (mar 16 - 31): hell's half-acre
    
    • tiled research + actual map loading; no real post about it though
    
    
11. (apr 1 - 15): DO YOUR TAXES
    
    • (but also:)
      
    • more robust shape rendering for hex dungeons
      
    • adding pitch controls and lighting to the svg renderer
      
    • initial svg house render
      
    • further svg house renders
    
    
12. (apr 16 - 30): disorganized grab-bag
    
    • stilts and fences on houses
      
    • shape-in-shape constraints for hex dungeons
      
    • room-specific patterns for hex dungeons
    
    
13. (may 1 - 15): opengl rendering of plants, houses, and graphs
    
    • opengl rendering for plants
      
    • further opengl plants
      
    • hex graph (plus house) rendering in opengl
      
    • final reportback
      
    • also i got the initial try at fast dependent bind working for the combinatorics data type (no post about it yet)
    
    
14. (may 16 - 31): mana physics clicker game
    
    • initial post
      
    • abstract on mana physics
    
    
15. (jun 1 - 15): myth generator
    
    • reportback w/ lots of links
    
    
16. (jun 16 - 30): myth generator (cont.)
    
    • second reportback w/ a few more links
    
    
17. (jul 1 - 15): city-builder
    
    • reportback
      
    • 'demo'
    
    
18. (jul 16 - 31): gpipe renderer
    
    • reportback
      
    • general post about gpipe
      
    • some renders
    
    
19. (aug 1 - 15): input handler
    
    • reportback
    
    
20. (aug 16 - 31): landscape generator
    
    • initial synopsis
      
    • first screenshot in series
      
    • source code
      
    • final reportback
    
    
21. (sep 1 - 15): l-system trees
    
    • first screenshot in series
      
    • reportback
    
    
22. (sep 16 - 30 2018): procedural magic system
    
    • reportback and examples
    
    
23. (oct 1 - 15 2018): haskell form input handler system
    
    • reportback
    
    
24. (oct 16 - 31 2018): (nothing much)
    
    • i got composed l-systems working on the 28th; that's about it
    
    
25. (nov 1 - 15 2018): [NANOWRIMO]
    
26. (nov 16 - 30 2018): [NANOWRIMO]
    
27. (dec 1 - 15 2018): qliphoth
    
    • reportback
    
    
28. (dec 16 - 31 2018): polyhedra data model
    
    • reportback
    
    
29. (jan 1 - 15 2019): planetoids
    
    • initial rectification
      
    • planetoid wall joins
      
    • reportback and examples
    
    
30. (jan 16 - 31 2019): form handling / FRP event system
    
    • short reportback
      
    • big reactive-banana post
    
    
31. (feb 1 - 14 2019): (nothing) (i'm sick)
    
32. (feb 15 - 28 2019):
    
    • gpipe shader uniforms
      
    • also landscape 'zoom' subdivision / better hex surface polygonization
    
    
33. (mar 1 - 15 2019): stretchy edges in graph grammars
    
    • reportback
    
    
34. (mar 16 - 31 2019): nothing
    
35. (apr 1 - 15 2019): erratic but mostly further work on stretchy edges
    
    • did my taxes
      
    • reportback
      
    • first embed test
      
    • final embed test
    
    
36. (apr 16 - 30 2019): nothing (some light polyhedra work)
    
37. (may 1 - 15 2019): SOLID POLYHEDRA AND "VILLAGE EDITOR"
    
    • reportback
    
    
38. (may 16 - 31 2019): making the forest map from hex shapes + some lofted tree spaces
    
    • forest space
      
    • forest space 2
      
    • forest space 3
    
    
39. (jun 1 - 15 2019): wang tiles (apparently these don't work in chrome; i don't know why b/c i refuse to install chrome.)
    
    • wang tiles test #1
      
    • wang tiles test #2
      
    • wang tiles test #3
      
    • wang tiles test #4
      
    • wang tiles test #5
      
    • wang tiles test #6
      
    • wang tiles test #final
    
    
40. (jun 16 - 30 2019): fixed graph hallways rendering; partially expanded graph embeddings to handle connections with 3+ edges
    
41. (jul 1 - 15 2019) -- nothing
    
42. (jul 16 - 31 2019) -- nothing
    
43. (aug 1 - 13 2019): picking
    
    • reportback
      
    • day-by-day progress
    
    
44. (aug 14 - 31 2019): triangular texel shader, texture atlasing
    
    • reportback


45. (sep 1 - 15 2019): pc model, uniforms, and camera control
    
    • reportback


46. (sep 16 - 30 2019): goldberg polyhedra coordinate system
    
    • reportback


47. (oct 1 - 15 2019): render buffer updates


48. (oct 16 - 31 2019): combinatorics data file syntax/parser
    
    • reportback (for both october projects)


49. (nov 1 - 15 2019): PROCJAM 2019 (knotwork star generator)
    
    • reportback
    • knotwork star generator


50. (nov 16 - 30 2019): darkness game
    
    • reportback


51. (dec 1 - 15 2019): render buffer stuff


52. (dec 16 - 31 2019): FINISH TWINE GAME
    
    • reportback (for both december projects)

---

since this 2-week project project was originally planned to run til the end of 2018, and i started in november 2017, that means this latest one (may 15th - may 31st) is the final one in the first half. so i guess we'll see what stuff i get up to in the latter half.

oh right, posts

this two-week project was basically "put together an opengl renderer for all the generation code i've been working on". at first i was gonna try rust, but... basically rust is really frustrating. so instead o went with the lambdacube library in haskell. and that's probably temporary, since lambdacube has some issues of its own (it's mostly-abandoned in a partially-finished state and i couldn't figure out how to get shader uniforms working, which is _kind of_ a big deal since that's like, basically the simplest thing to do in a shader).

but i did get everything rendering, and i got random houses rendering with random plants in random graphs, so that's pretty neat. (here's a graph render and here are some plant renders) the next thing i should do with that is... i think go back to the 'landscape' generator, and see if i can do anything about rendering actual landscape features in 3d given the graph output. what would also be nice is getting subgraph generation working, and then rendering actually complex worldmaps. that's still a ways off, though.

oh right been a while

okay so my two week project as of four weeks ago was actually 'work on hell's half-acre more', which i did somewhat (i looked into how the 'tiled' map editor works and how its maps can hook into game code, and i implemented a very basic little map loader. and also fixed a few bugs) but didn't really make a whole lot of progress with. and then from the last two weeks the project was basically, uh, "do your taxes", because i had put them off until the last minute. so that wasn't really ideal.

but what i ALSO did was some misc other work. for one, i opened up my graph-expansion level generator and expanded its ability to collide and render shapes -- previously, i had basically hardcoded in the rendering code for 1x2, triangular, and diamond rooms, and anything that wasn't precisely that exact size would just fail to render entirely. i parameterized that rendering code so that i could generate 1xn rooms, and triangles and diamonds of any size, including asymmetrical diamonds. (i also wrote collision code for trapezoids, but i didn't try to do any rendering code for them, so they're still not fully implemented. e: i did some rendering math and got trapezoids to work too. yayy this means i can generate every convex shape except for arbitrary irregular hexagons. which is, you know, the biggest shape domain that includes the most values, but you know w/e trapezoids is still progress) this pretty radically expands the ability of the dungeon generator to make big maps, since... like in my head each 'tile' in the map is basically the space for one item or monster, which means all the maps generated so far are pretty compact. but now it would be possible to make maps that are only made from very large pieces, which means more space for variation.

(also, the only convex shapes remaining are trapezoids and irregular hexagons, and those are both realistically possible to implement. at that point you could make any kind of convex shape and have it work correctly, which would be really good. in part because the easiest way to represent a concave shape in this is as a collection of convex shapes glued together.)

ALSO i worked on some 3d rendering stuff. so when i was working on the plant generation, i needed a little 3d renderer so i could output plant models. it worked pretty well. but recently i was like "hey i'd like to get back into larger-scale generation", so i was like, hmm, well, procedural buildings maybe? so i repurposed the 3d svg generator for things other than plants, and made a little generator for houses. there are a few examples up on my screenshots blog. so far i've only been generating buildings by hand, since i'm not 100% on how i'd want the generator to work, and there are uhhhh more than a few glitchy houses that generate busted geometry. listen i've only been working on this for like a week, cut me a little slack here.

this is CONCEPTUALLY modeled via use of constructive solid geometry -- all these houses as globs of primitive objects intersected and unioned together to make coherent 3d geometry with no messy hidden faces -- but uh i've never done any CSG stuff before, really, so right now the code is more than a little broken and inefficient.

one of the goals for this whole set of procedural products is to kinda create a procedural almanac? so like, have a procedural history that produces procedural cultures, which are filled with procedural people, who live in procedural settlements in a procedural world and who are surrounded by procedural flora and fauna. and be able to trace the connections of things, like, such-and-such adventurer is from this culture, and here are their settlements, and this settlement uses this grain staple, and here's the biological tree of that grain going back through time, etc. you can see the 'people' part of that with the whole nemesis system, random orcs or humans or monsters setup, and you can see the 'flora' part with the plant generator; these houses would be part of the 'settlements' part.

i don't really know how close any of that is to any kind of fruition, but you know, that's the concept at least. it also gives me some direction for future generators, like, hey what would a procedural animal generator look like?

anyway my schedule got kinda messed up but i guess it is time to pick a new two-week project. i might pick up the graph generator again and try to fix the big three problems with it currently (after which it would become a much more useful and interesting tool). or maybe not. i guess we'll see what i've been up to in two more weeks.

i guess it's time to make the next gamedev challenge post

oooof

okay so this one was myth generation, using the same basic generation system as i was using for the nemesis character system. i started off modularizing the program some -- making it take input args to determine how it should run, all that stuff, because initially i had to change code around and recompile every time i wanted to switch it from generating a set number of actors vs. actually running events. i added in predicates, to control which actions could run, and then i added in mutations, which let actions change the actors. i fixed some bugs and got those systems working properly. and thennnnnnnn i got stuck in a combinatorics puzzle for the next week and a half and didn't really make a lot of progress. so that's not great.

i mean i have come to a certain level of enlightenment about the nature of the combinatorics problem this poses, and i got to the point of outlining a solution, but i never was entirely certain about how to implement it. so all-in-all mostly frustrating, especially since i very well could have _not_ done all of the combinatorics wrangling and instead focused on adding new features or capabilities to the program instead of just trying to make it more efficient. i'll get that code working at some point i'm sure.

now: uhhh idk i guess i gotta pick another project

the myth generator is... working slightly more. this is essentially a continuation of this post about the nemesis system, since i'm using the same basic infrastructure. at that point i had gotten an extremely rudimentary form of actions running.

my current gamedev challenge thing is myth/history generation, which is basically the same exact thing only with a different dataset. the main issue is actions: what actions can do, what effects they can have, and how actors select actions. currently i've added

1. predicates on actions, so that who can run them can be limited
   
2. mutations on actions, so that running an action can change any participant
   

i've also tweaked some of the generator settings and made it more argument-driven, because previously i had to tweak the code in main and recompile every time i wanted to change the type of output.

these are big improvements, but there's still a lot more to be done before this is anywhere close to being usable. on the technical level, i need to add the ability for actions to create or destroy actors (think: a city being founded or abandoned, an artifact being constructed or destroyed, characters being born or dying).

on a structural level, i need to add in the concepts of time and space -- it's currently possible to have locations and to require two characters to be in the same location to act together, but that would mean having a bunch of actions like ACTION %1 ? %1.location == foo { %1.location @= bar } ACTION %1 ? %1.location == bar { %1.location @= foo } to denote a pathway between the locations foo and bar, and then have every other action have a specific predicate %1.location == %2.location. and that would enforce the same exact map for each run-through of the history, so no randomly-generated maps. it would be a complete mess. what would be really neat is hooking up the graph generator to this, so that the landscape is enforced via having an actual graph representation of its shape, but neither this nor that are really in good enough shape to handle that right now. and there's no concept of time elapsing or any kind of progression.

it's technically possible to enforce a 'plotline' in actions now, but it's so unwieldy as to be impractical. what would be nice is, like, actors having a set of drives based on their characteristics, and picking actions based on what's allowed by their drives / weighed based on their drives. i don't really know how i would codify that, though -- part of writing my own syntax is figuring out ways to meaningfully and compactly encode things like that, and i don't really have a solid concept yet.

that being said i should probably start putting together an actual myth-styled dataset now, instead of just reusing the nemesis one. not that that couldn't be a part of it, just, a myth generator necessarily has a much larger scope. meaningful myth generation also definitely requires actions generating new actors, especially if the myth generator only starts with a primordial god or an endless abyss or what-have-you.

( here's a sample output )

okay gamedev challenge reportback

again

i mean as should be expected at this point

this was on my list as "evolution/genetics system", and it was something i kind of put on there because it was a thing i had always wanted to do, but it was down near the bottom when i just started listing unrealistic longshot ideas, because like... genetics seems hard? genetics seems really difficult and completely unrelated to any code i've written ever.

so then it was kind of a surprise to be idly thinking about my enumeration code and have this train of thought like "it would be nice to be able to walk around inside the deck and see the values as they change, rather than only having a single index that tells you nothing about the structure of the value. i think you could tracked how values were added together you could get a list of all the independent axes of interaction, so you could actually get an n-th dimensional rectangular prism representation of the enumerable space you're building up. and then it would be possible to get a list of all adjacent values, and randomly walk through the possibility space. ...you know that is sounding a lot like random mutation in a genetic space"

SO THEN i spent a while putting that code together (and as you have seen in some of the posts about Data.Enumerable here i figured out lots of it but not all of it), and then i started working on actual plant rendering, since plants are a decent start in terms of simulating evolving things. at first i started by reimplementing some of my really old l-system code, and then trying to code up various l-systems that were mentioned in the algorithmic beauty of plants. i didn't get super far in, only to chapter 3, but that's deep enough to get to some fairly fiddly systems.

after a while i kinda put together my own l-system setup, by having a plant data structure that could generate an l-system expansion; there are some screenshots of my generated plants on my code screenshots tumblr.

but the actual simulation of plants growing in a real 3d space is... a lot more intricate than just running an l-system. i have been reading a lottt of academic papers over the past few weeks, some provided by friends who have journal access, but mostly pirated off of scihub, so, thank you scihub for existing or else i would have had to spend like $500 on downloading papers (or obviously more realistically just not being able to do it at all)

i'm not going to get into the nitty-gritty details, but from my reading it sounds like it's still a bit of a hassle to manage plant growth as driven by light and water absorption. l-systems just kind of expand, they don't really respond to their environment, and while there's some study into environmental-response l-systems there's not a huge bulk of papers. there are some really neat l-systems that do manage nutrient distribution, but it seems like they do that by running two completely separate 'root' and 'plant' systems and kinda gluing them together at the base and somehow sending communications through them. so while i did get a 'genetic code' (my plant data structure) and a way to mutate, crossbreed, and grow it, i didn't get a full simulation working, since that would mean... actually simulating growth and pollination and seed dispersal, or at the very least a fitness metric that vaguely imitates that, leading to a second generation being selected.

still, all of this is going to be really invaluable for when i return to this at some point and try to get nutrient flows working. the goal here is a little plant simulation that properly absorbs water from the ground and light from the sky and stores those in specific parts of its body and uses energy stores to grow further roots and leaves. that's a way's away, not the least because i'd have to figure out how to formulate that as an l-system, but i made a lot of good progress here.

hey i have a math problem i was hoping somebody could solve

okay so as you may already know i wrote some haskell code for enumerating through values, and that was real neat and useful and generally speaking i accomplished a lot with it.

now i'm trying to expand it. specifically: the code as written lets you enumerate through values, but in constructing the values any sense of relative position is lost. you can do something like V2 <$> from [1..10] <*> from [1..20] and that will let you enumerate through all 200 values, but if you have an index representing, say, V2 3 7 (index 62 btw) you can't say "i want to see the indices of all values that are one unit adjacent". basically there's no way to inspect a deck.

SO i had the idea to track mergings of decks. change the data type to

data Enumerable a = Enumerable
  { count :: Integer
  , segments :: [Integer]
  , selector :: Integer -> a
  }

and make the applicative instance

instance Applicative Enumerable where
  pure v = Enumerable 1 [1] $ const v
  (Enumerable c s f) <*> (Enumerable c' s' g) =
    Enumerable (c * c') (s <> ((c *) <$> s')) $ \i -> let
        j = i `mod` c
        k = i `div` c
      in f j $ g k

so that V2 <$> from [1..10] <*> from [1..20] value would have 'segments' of [1,10], meaning that there are two axes: one that increases/decreases in steps of 1 and one that increases/decreases in steps of 10.

and so then you can decompose indices into movements along those axes, like so:

decompose :: Enumerable a -> Integer -> [Integer]
decompose (Enumerable _ s _) i' = snd $ mapAccumR split i' s
  where
    split :: Integer -> Integer -> (Integer, Integer)
    split i c = (i `mod` c, i `div` c)

and it will say: okay index 62 there decomposes to [2,6]. and then you can do something like...

mutate :: Enumerable a -> [Integer] -> [[Integer]]
mutate e i = tail $ recombine $ zip i mutvals
  where
    mutvals = uncurry spread <$> zip (maxAxes e) i
    spread m c = snd <$> filter fst
      [ (c > 0, c - 1)
      , (c < m, c + 1)
      ]
    recombine [] = [[]]
    recombine ((base,vars):rs) = ((:) <$> pure base <*> recombine rs)
      <> ((:) <$> vars <*> pure (fst <$> rs))

maxAxes :: Enumerable a -> [Integer]
maxAxes e = decompose e $ count e - 1

mutateI :: Enumerable a -> Integer -> [Integer]
mutateI e i = construct e <$> mutate e (decompose e i)

to have it spit out all decomposed values that are one unit distant. so then:

λ> let foo = ((,) <$> from [1..10] <*> from [1..20])
λ> select foo 62
Just (3,7)
λ> mutateI foo 62
[52,72,61,63]
λ> select foo <$> mutateI foo 62
[Just (3,6),Just (3,8),Just (2,7),Just (4,7)]

and now you can navigate around within a enumerable deck. very neat. i'm currently using this to put together some really basic plant mutation/crossbreeding code (since you can also crossbreed two indices by decomposing them, and then picking values randomly from the two sets) and it's generally working pretty well.

the PROBLEM is:

the original formulation of Enumerable is also an Alternative and a Monoid:

instance Alternative Enumerable where
  empty = Enumerable 0 $ const (error "no value")
  (Enumerable c v) <|> (Enumerable c' v') =
    Enumerable (c + c') $ \i -> case i - c of
      x | x >= 0 -> v' x
        | otherwise -> v i

instance Monoid (Enumerable a) where
  mempty = empty
  mappend = (<|>)

BUT: this new formulation would require some additional segment tracking. Applicative is really easy to store because it just creates n-dimensional prisms with totally regular axes. Alternative is a lot trickier, because it would involve... adding offsets? something? the actual lookup math above is really simple, but if i wanted to store that as a segment i'm pretty sure i would need to stop using just lists of integers.

i've looked at a lot of math and i've tried to mark out the patterns it would make in indexing and i have yet to really figure out what i should do with it. i think the GOAL is to have it treat all choices as adjacent? so like pure 1 <|> pure 2 <|> pure 3 <|> pure 4 would be different from from [1,2,3,4] because the alternative would consider 1 adjacent to all of 2, 3, and 4, whereas the basic enumeration would only consider 1 adjacent to 2. (and then from [1,2] <|> from [3,4] <|> from [5,6] <|> from [7,8] would consider 1 and 2 to be adjacent to each other and to all of 3 5 and 7. ditto 3 & 4 with 1, 5, and 7.)

it's just uhhhh i am totally failing to see whatever structure i need to see to codify that up, so, if anybody has any thoughts i would like to hear them.

(spoilers this two-week project is gonna be trying to make something like this.)

okay gamedev challenge reportback

a bit early, because i got tired of rust + hit on a new idea that's really grabbed my attention.

so, rust. the first thing: rust's library ecosystem is very much not robust. there are some fairly comprehensive geometry/math libs (cgmath, mint), but after that, in terms of "3d rendering engines", it's... very slim pickings.

at first i looked at piston, which was a gigantic mess of half-finished code and leaky abstractions that was immensely frustrating to try to use. specifically i was like "okay now let's load a texture and place it on a polygon", and they only have examples for loading raw texture bytes.

(one of my demands here was "i am not going to use any graphics library that expects me to manually serialize texture byte data", which i don't think is an unreasonable demand at all but apparently several graphics library authors disagree with me)

they had a function that gave you a Texture object from a filename, but it was a texture object that was completely distinct from some other texture object that seemed to be the one that was actually used, and there was a bunch of lower-level gfx code that wasn't really restructured at all, so it seemed like they were expecting you to sometimes use a piston abstraction but sometimes you'd have to talk to the gfx code directly and it was a huge mess. and none of it was really documented, so all of that is basically just guesses i made from looking at the rust doc and trying to line up types, with no real clue if i was looking down the right path. so that alone was nearly enough to get me to just give up there.

anyway then somebody else recommended three-rs, which was comparably way less busted.

three-rs basically worked decently? or rather: the version on cargo is version 0.2.0 and has basically no documentation at all, and also has a Window::new function, which you need to get the general assortment of three-rs rendering objects, that expects "a shader path". that's really weird because 1. you need at least two shaders (vertex and fragment) to do anything, so a single shader is useless and 2. they mention precisely nowhere what the shader should actually do (input uniforms, etc). so i looked at the code examples, only to see them using a one-arg version of Window::new that did not appear to actually exist.

i forget how exactly i figured it out (looking directly at the github source, probably?) but eventually i realized the version hosted on github, which is where the examples linked to, while also called version 0.2.0, was radically different and much further along in development. after cloning the repo and building it locally i also discovered that it had a bunch of actual documentation written. so after that giant hurdle it was decent.

(btw the newer version has default shaders, hence the lack of that arg for Window, but it still talks about having "a shader" whenever you need to provide one, and it's only through guesswork and asking other people that i discovered that what it wants is a name like "foo" that it will automagically rewrite to "foo_vs.glsl" and "foo_ps.glsl" and load those as the vertex and fragment shaders. this isn't even mentioned anywhere in the docs, they just say "a shader" or "a shader name" as if that's clear.)

generally most of the time was spent struggling with the library itself as opposed to the language, which, given how fiddly and how little a grasp i have on rust-the-language, wasn't really encouraging either. in like a week of use i found one library panic bug and one place where the library just kinda threw away uv data because apparently literally nobody had ever used this library to draw textures before, which is like... yeah the rust library ecosystem is not robust.

there was still the issue of there not really being explanations for what anything does -- one of the issues i was having was that textures appeared to be loaded automatically using linear interpolation, which looked like absolute garbage for my lo-fi textures. so i was like, well, what in the world sets that, because it's not mentioned anywhere. i searched for "blend" or "linear" or something like that, and that got me some types (Samplers) that seemed to be talking about texture interpolation functionality, except... the load_texture function didn't take that as an argument, and always forced you to use the 'default' one. there was a separate load_texture_from_memory function that did, but, it didn't take a filename; it required you to manually construct texture bytes. so i griped at somebody to do something about that, and they did, and that turned out to be the thing that fixed it, but until that patch had landed i still wasn't actually certain that the Sampler arg actually did interpolation. it certainly seemed to be the thing in code that did that, but there wasn't any documentation about it anywhere, aside from in data declarations and type signatures.

i eventually got a super basic demo that draws some textured hexagons and also has a billboarded sprite drawn that switches its sprite index as you rotate the camera around. nothing really worth showing off.

i guess i might return to rust at some point later? but really because my only other options are haskell (not good at realtime anything) or java (terrible libraries, requires a giant IDE to do anything, requires oodles of boilerplate code everywhere), or like, learning c++ (no). plus it's a language that's doing something interesting, so i feel like i kinda have an obligation to support it over the waves of "let's just write everything in javascript" that are kinda consuming the code scene these days. but so far, uh, not really liking the language or any of its libraries all that much.

okay gamedev challenge status post time!

there's technically another like, 36 hours before it's "over", but i think i've pretty solidly hit the limit of what i can add in that time.

so when i made the last post-mortem post i was all, yes, 3d rendering, that's what i'll be working on next, and if you've been following me on mastodon or on my programming tumblr you have probablyyyy noticed that's not what i've been working on. instead, i started working on the graph generator again! since i mean, i did only work on it for a week last time.

that's mostly because right after i made that post, i 1. watched some gdc, including a randomized lttp run, and 2. did some bloodborne chalice dungeon crawling. so i was like "hey you know what's neat? random dungeons and random unlock trees", and that got me thinking about getting back into working on a dungeon generator. or, specifically, a dungeon unlock flowchart.

so when i left off last time, i had a working graph embedding that drew nice hexagonal graphs.

i initially wrote down a bunch of 'power-ups' which each had a bunch of different powers, because one of the neat things about the lttp randomizer is that it considers alternatives: you need the master sword OR the cape to cross the barrier. you need the book of mudora OR the titan's mitt and the flute to enter the desert palace. i, uh, also basically instantly threw those away, since alternatives are (probably???) a lot trickier to solve for. instead, i mostly focused on 'keys' and 'locks'.

but this wasn't specifically a key/lock update, it was more just a generalized "improve the graph generator" effort. there were several things i got working additionally, that were maybe just as important: first, differently-sized rooms, and then differently-shaped rooms. (the rendering for those is actually still super ad-hoc, since i wasn't able to generalize it. so literally only hexes of any size + those three shapes (1x2, triangle, diamond) are supported. also, even if i fixed the renderer, only convex shapes work for the placement code i've written. so there are some serious limitations here that i'd like to fix.)

i also started experimenting with actual generators -- sure, i put together this big graph expansion framework, but that's kind of useless without an equally-intricate set of instructions to build the graphs. everything i'm using right now is really rudimentary, and is still mostly just "randomly pick a room, randomly place it against an existing room", and there's a whole world of more complex operations that i'm totally not using right now.

but the main thing are the lock-and-key puzzles i got working. there are only a few basic expansions that i'm using:

• take any two connected rooms, and on one end add a key. on the other end, add one or two locked doors leading to dead-end treasure rooms
  
• take any one room. add an open edge to a new room, and move a random percentage of the first room's keys to the new room
  
• take any two rooms that have an open (not locked or one-way) edge between them. break that edge, and in its place add a looping circuit: add a new room, and add edges between it and the two initial rooms so that there's some random combination of open, one-way, or one-way unlockable edges between the three rooms, pointed so that you can always run a loop around them (there's also a version of this that runs on a single room, adding two new rooms with a looping circuit)
  
• take any two rooms that have an open edge between them. keep that edge, and add one room off each room (with the new connections maybe being one-way or one-way unlockable), with the two new rooms connected through a locked door. one of the two new rooms will have a third new room attached, with the key.

so those are all comparatively simple expansions, and they all preserve connectivity (if a room was reachable at the start of an expansion, it's still reachable at the end). so i can just run those expansions as much as i want, and it'll slowly complicate the dungeon layout.

it would actually be possible to add in alternatives fairly easily (like, an expansion that places two side rooms with a key each, and then adds in a room with two locked doors connected to it), and then trust the other expansions to complicate that further, but i haven't actually experimented with that much. something that would be much harder to handle would be 'small keys', as in, one-use key tokens that each unlock any one of a number of small key doors. i think just having random graph expansions would end up with cases where it could be impossible to progress if you use your keys to open the wrong doors.

(the next major step contentwise would be to make different expansions based on different room types, like e.g., have a forest-with-river zone that generates cosmetic, un-traversable 'across the river' edges, and only allow one-way unlockable exits when they transform a stream edge, and then render that in-game as knocking over a tree. add in more shapes of things, and have certain room types only be certain shapes, to allow for hallways and rooms and the like. stuff like that could add a lot of character to certain zones, since you'd traverse them in different ways. right now the dungeons are pretty uniform in structure, since the same expansions are running across the entire thing.)

there are a few really big limitations of this system, currently. one, the embedder is kind of dumb and can only place new rooms, not move existing rooms around. this actually has some really major repercussions in terms of generation implications: if any two rooms are generated next to each other, they will always be next to each other, even if we run a million expansion iterations. it's impossible for a new room to push them apart. which means it's impossible to, say, start the generation off with a few locked-circuit iterations, to make a bunch of loops, and then run the rest of the expansions to spread those loops out, so that the entire map (in most cases, statistically) will end up looping back on itself at the ends.

two, it's impossible to separate edges unless they're specifically matched on: there's no way to say "split this room in two and move half of its edges to the new room", for example. that means it's also impossible to recursively subdivide a room. imagine generating a simple map, but where all the nodes are huge hexes with lots of space inside them. then turn each node into its own dungeon level, making sure to put rooms at the correct places along the edges of the hex so that they end up maintaining proper connectivity. that's a major goal for this project, and it's still totally impossible.

third, it's basically impossible to propagate information through the dungeon. i had a planned expansion that was "find a room with an open connection and a locked connection, and then in the room of the open connection add a new room, with that connection locked with the same key" (to spread out locked doors so that each key isn't ever only used in one room, basically), and it's not actually possible currently to say "the same key", because that information is only known in the matched subgraph, and only used in the expanded graph, and actually those two things can't share information at all. likewise, i kinda wanted to have a 'difficulty' level, that rose by one with each step, except again the state of the matched node is only known in one place, and it's not where the data for the expanded node is.

i have a few ideas for fixing those things, or at least some of them, but the code is really not there yet. so i think this is a really neat thing that i've put together, but also there's sooooo much left to do before it's what i would call 'finished'.

still, on the whole i'm really pleased with this! it's an actual use for this code i've had sitting around for a year, and in these two weeks i've taken it from "here's some hexagons" to something that could be an actual, genuine map layout for a game. it still needs a lot of work, though, even for that: adding start/finish lines, or enemies, or boss rooms, etc, even ignoring all that complicated algorithmic junk above. but pretty good progress for two weeks, and i'm pretty hyped for whatever it is i decide to work on for the next two weeks.

---

also i've been doing this by having the embedder output an .svg file of the graph, and so far i've just been taking screenshots and posting pngs. but here are some Original, Authentic svg images:

a few ~50-room dungeons:

• dungeon-047.svg
  
• dungeon-048.svg
  
• dungeon-049.svg
  
• dungeon-050.svg

a few ~100-room dungeons:

• dungeon-053.svg
  
• dungeon-054.svg

(there are other in-progress shots/blurbs on my code screenshot tumblr if you want to read the whole backlog)

oh right yesterday was the 15th so time to close one two-week project and start on a new two-week project. so it's POSTMORTEM TIME.

this two-week project was actually more of a three-week project, since i stopped working on the graph embedding thing early. this latest one is a porn twine game, so in a lot of ways both the most gamelike concept AND the most, uh, pornographic concept.

at first i was like "sure, it'll just be a slightly-interactive story, i can write that in three weeks no problem". and then i started outlining it. and outlining it. and the initial skeleton, which was a series of passages like "okay at this point you're in the desert town, and you do this" "okay then you head to the locust hive" "then you do some stuff at the locust hive" "then you head back", got fleshed out and fleshed out, and i added a worldmap and some mechanics and set up game variables, and the outline grew and grew in size. then i was like "okay, well, maybe i can at least get the outline finished before i run out of time". right now the outline is at 22k words and it's mostly complete, but it's definitely not entirely complete. so i guess that's the usual lesson in content creep; everything always ends up bigger than expected.

so i'm gonna be putting this down for a bit -- though i did run a patreon poll with a draft of it, and basically asked people 'should i keep working on this on hell game dev time', and got mostly 'yes' answers, it's just i think i wasn't clear enough about the "keep working on this while i also work on hell game, thus cutting development speed of both in half" aspect. on dev polls if you have options that are like, "only A", "only B", "both A & B", basically everybody is going to vote for both, just because, hey, more, and you gotta be reallyyyyyy clear about the time impact of that, which i don't think i was enough. so i'll probably keep working on it sometimes, since it's a nice small(ish) self-contained project that has a very limited amount of tfs and has its entire plot structure roughly outlined, which are things i was kind of missing from hell game.

IN THE MEAN TIME, time to pick up another two-week concept to work on. i think i'm gonna go with... work on 3d stuff. that's not an actual item on the list, precisely, it's just that i have a bunch of things that kind of assume i'll have a 3d rendering setup working, so, time to get that. i did make a java project that handled isometric rendering, which i dumped these sprites into, so, uh, you know, probably not a sprite porn game, but maybe something like a sprite porn game. we'll see.

also saving it for last, but here is what i have so far of the porn twine game, if you want to check it out and give me your thoughts.

okay i've been spending a lot of time posting on mastodon lately

this latest gamedev challenge project is growing into something huger. or rather, as i turn it from a vague outline into something that's approaching being technically complete it makes me realize that it is actually kind of a big project. much smaller than hell game, but not exactly trivial itself. roughly the first half of the game is coded up, and it's playable all the way through to the ending. there are like, mechanics and sidequests (well, one sidequest), and it's to the point where i'm looking for people to play over it and give me their thoughts about how the game flow is, so, if you want to play through a game outline hit me up.

okay i might be calling the latest gamedev thing a little early. more details on that later on in the post, but first i gotta explain what the current gamedev thing is about.

if you've been following my rarely-updated code screenshots blog you may have seen a bunch of posts over the latest few days. that's what i've been working on!

now let me tell you what all those inscrutable hexagon graphs are for.

okay so a year or so ago i was captivated by this video (relevant portion beginning @ 1:36), where somebody outlines a map generation system built around subgraph identification and expansion. this might sound a little gimmicky or overly-specific at first, but actually if you're familiar with l-systems, this is actually the next step above them -- where an l-system can identify a structure in a tree and substitute values to grow the tree, this graph system does the same thing with a subgraph in a graph. so it's an extremely general and powerful system for procedurally generating, uh, graphs. (and only slightly hampered by how an aspect of it is known NP-complete. this isn't as important as it sounds, given in practice the subgraphs matched on will be trivial)

let's talk about dark cloud. dark cloud is a ps2 game, kind of a successor to 'soul blazer' on the SNES, where you go around doing dungeon crawls to undo seals on parts of towns, which you then reconstruct. there's also dark cloud 2, also known as 'dark chronicle', that takes the basic concept and executes much better.

what i consider kind of formative to my opinion of dark cloud, moreso than actually playing it, is this e2 writeup, which i'll excerpt part of here:

There are 207 dungeon floors in Dark Cloud, 100 of which are optional post-game bonus action in the Demon Shaft. That still leaves 107 dungeon floors to hack, each at least once but probably many times as you build up your weapons or, no, wait, that's all there is to do in Dark Cloud. Just keep this number in mind as I describe a typical dungeon floor and multiply this excruciation by 207.

First, I would do great injustice to this game if I did not elaborate on its random dungeon generation engine. You see, I love games like the old AD&D Forgotten Realms game Dungeon Hack or the updated Blizzard Entertainment Diablo series. These games invent layer upon layer of randomly generated dungeon for you to explore and plunder. Quite literally, this is an unlimited adventure. This is a key feature for replayability, and I looked forward to its implementation in an action-RPG like Dark Cloud.

But apparently, someone forgot to explain the mathematics of probability to the designers. If you design an array of, say, 1000 different types of rooms to be spread along winding corridors -- you're going to get 207 levels of intrigue and danger and surprise at every turn! However, the designers chose a smaller number.

Much smaller.

Keep guessing.

They chose three different rooms to repeat for 207 floors.

I still get angry thinking about this.

Three rooms. You'll know it when you come to them. The first is a square room, with or without some obstruction in the middle. The second is a much larger rectangular room with maybe a couple obstructions scattered throughout. The third is what I like to call the "brain room" -- a room shaped like two hemispheres of the brain connected by a narrow corpus collossum. That's it. Each area has a different tileset, different monsters, and a different character-specific door lock. But that is the entire game right there.

So essentially, you are playing the same dungeon floor over and over again -- each with slightly more difficult monsters.

(my understanding is that that's actually slightly incorrect -- rather than 'three rooms' it's actually two room templates: one a room of {3,5}x{3,5}, optionally with a pillar/hole in the middle OR a 'brain' dividing wall; the second template being a much larger room with random pillars/holes scattered inside it.)

of the many things dark cloud 2 did better than dark cloud is that it used different dungeon generators for each area. some of the areas did have pretty generic mazy maps, but others had much more unique generators. the chapter 3 'starlight valley' area is near and dear to my heart, and its dungeon was a series of forking canyon paths on the edge of gorge above a river, with bridges connecting back and forth across in spots. not necessarily better, but definitely novel.

i've written before about how procedural generation sucks and is fundamentally about reusing content. this graph system is, among other things, a generalized system to make dungeon maps in a certain 'style'. use a base graph and expansion deck that's canyon-themed to get a canyon-style map. use a base graph and expansion deck that's swamp-themed to get a swamp-themed map. this is one way to use the same system to make different "feeling" maps.

now, i wrote all that code like a year ago. but. the one part i didn't write was the code to embed the generated graph. a graph is just a mathematical object: a list of nodes and connections between them. if you want to draw one, you need to have a function that maps each node to a position, and (ideally) that'll be a function that makes the graph look nice, instead of a tangled mess. this is actually pretty tricky to write, and my understanding is the standard method is to basically treat it like a physics problem: nodes all repel each other, and the edges between nodes are springs that pull those nodes together. add them all into a big physics simulation, and keep adding forces randomly near edge intersections until they're all resolved. that's... really complex to code from scratch, and physics is really not my domain at all, so for a long while i let that code languish with no possible way to draw any of it, and it was only recently that i was like "oh hey i could try printing those graphs onto a grid". so that's what i did.

this is something that's still really unfinished -- i only have one set of expansion rules, and it would be good to add more control options for how the expansion rules are selected (currently it just rolls randomly to pick one and sees if it can find an embedding), but getting it working this much has taken the code from "not usable" to "usable", so, that's a pretty good step.

(i was actually considering using this for a procedurally-generated dark souls/bloodborne kind of game -- making one big graph that would be the "world map", and then making each node of that big graph into an area using an area-specific expansion deck. that would be an entire separate endeavor though -- all i've really done in this week is make the structure; making a good expansion deck enters into the realm of game design & is an entirely separate challenge. but it's... not a 'goal' exactly, but something i'd like to get this finished enough to do.)

BUT ANYWAY, that's really neat and i'm definitely going to revisit that code later, but in the moment i got just about as much of the main goal as i think i can get without a lot further effort, so i might stop working on it early and start on the next thing. b/c i'm currently in the middle of a big expansion of the hell game body system, and kind of longing for writing for a less mutable body. i threw a tiny twine demo together in a few hours (mostly debugging/trying to remember how twine worked) earlier today, and i think the next gamedev project is gonna be, you know, an actual game, rather than more working on weird library code. so that might be a three-week project. i'm not gonna commit to that without a little more time for deliberation, but, that's what i'm thinking about doing now.

well it's the 15th (uhhh 16th actually) so that means it's time for a reportback on the latest gamedev challenge thing.

uhhhhhhh

i basically did nothing w/ it for all two weeks :/

part of the issue was that i wanted to try this thing out in 3d, which would mean doing it in java, which would mean making a new java project with libgdx installed (which is kind of a challenge on its own) and then doing a bunch of wrangling with its renderer to figure out how to procedurally make polygons. and that was enough of a runaround before actually getting to express any actual game concepts that i just... never got around to doing it.

so i mean this is six weeks in w/ three challenges and so far the results are like. 1/3 is extant an 2/3 are nothing, which is not really very encouraging. i think i need to... figure out what i actually want to accomplish for these.

i think for thing #4 i'm gonna try what worked with #1 and just rework some of my existing generation code into better shape. i wrote an implementation of this graph-expansion generator in haskell, but it had no embedding code so it was impossible to actually render anything with it. but recently i've been thinking about it and realized there might be a simpler way to manage graph embedding without necessarily having to jump immediately into spring relaxation physics, so i'm gonna try that out and see how it goes.

i'm also tentatively considering picking rust as the language for the gamedev challenge, and coding/recoding everything in it so that i can properly mix different projects together if/when i want to do that. problems with that: i don't know rust and from my attempts at trying to use rust i really don't like it. so. we'll see how that goes.

so it's the end of the month and that means time for the second gamedev challenge game.

uhhhhhhhh about that

okay i so started on some kinda urban dead zombie thing and got the rudiments of movement working, but then i had one really aggravating day of trying to work with the rendering framework i'd made so far and basically gave up on it for the rest of the time. so that's not great. (the 'final' version is a tiny bit more advanced than that demo, but not really any more complete.)

i actually ended up working on the nemesis procedural generation code more -- adding in nil values (because there was no way to say 'generate x or nothing'; it was always 'generate x or y'), getting nested field lookups working, and adding in syntax/generator support for invoking further subgenerators. i wrote up a data file for procedurally-generating demons, maybe for hell game (here's a sample output), but currently just for kicks.

lessons learned: uhhhh don't just give up on things. or rather, there is a reason why i haven't had good luck with doing code or writing sprints, and that's because i get disheartened and give up easy, and probably it is better to think of things as just two weeks of messing with library code, rather than as gamedev. idk. the upside of this, though, is that if/when i totally fail at a given challenge, the two week deadline kind of limits how much damage i can do.

anyway the next thing i'm gonna try my hand at is some kinda world-generation stuff. not "procedural" precisely, so much as like, letting you put down some landscape-shaping things and see how the simulation evolves over time. the big thing i'm worried about with that is that it's gonna require some pretty substantial rendering structure, so i don't know how much of the time is gonna be taken up by working on that vs. actually doing any game stuff.

oh right so it's the 15th which means this half-month gamedev thing is over, so i should have a game and a reportback.

uhhhh about that

so after the last post the only additional thing i really did was unify "generators" and "actions" so that an action was just a generator that took at least one arg. i think part of the issue here was that 'nemesis system' isn't really a... game. it's a mechanic. and without that focus on having a fundamental game loop there wasn't really a clear concept for what i would actually _do_ with all the stuff i was generating.

(also given that i was writing this in haskell it was kind of an open question how i'd even 'release' the game, because i definitely can't make a windows build and i couldn't really expect other people to be able to build random haskell programs either.)

so that's something to definitely keep in mind for next time. there are a few more things on the game concept list that are essentially just mechanics ("alchemy system" is one, for example) and i think in those cases i'll have the two weeks be, like, taking an existing prototype and adding a new major mechanic to it.

and AS FOR the next time, the next thing is gonna be... a HTML zombie survival game. in the style of urban dead, but with more of a focus on long-term survival and like, construction. maybe even growing food. which should be fairly simple to throw together, and will be something i can actually release. (it's not going to be literal zombies. probably weird shadow monsters)

okay so gamedev. i got "actions" parsing and evaluating, which have a syntax like this:

%ACTION %1 %2 {
	text = %1.name and %2.name interact.
}

and i whipped up some really basic random selection, initialized the world state, and set it running.

the results are about as you'd expect:

ACTION {
	text: ginoz-diz and lįbagalą interact.
}
ACTION {
	text: ginoz-diz and chûckrir cha-grišrôt interact.
}
ACTION {
	text: llęfigįfy and caalbek interact.
}
ACTION {
	text: ghuzrug and rickgrûck cha-rûzzrûr interact.
}
ACTION {
	text: brukk-zonish and lįbagalą interact.
}
ACTION {
	text: khamkoh and ghovbig interact.
}
ACTION {
	text: breriz-lokk and caalbek interact.
}
ACTION {
	text: llęfigįfy and ląllųbwhi interact.
}
ACTION {
	text: rilush-nukk and higanęla interact.
}

okay, we get it.

there are a few problems with this most basic setup. one, the action selection code is kind of dumb and will happily select the actor as the person they're acting with; two, there's no way to limit what an action can apply to; three, there's no way for an action to change the actors involved in any way.

i have some ideas for how to solve those problems -- in order: add unique identifiers to the actors, and/or zipperize the actors list, so that it's possible to get a list of "one actor plus all actors who are not that actor"; add a special-case _predicate field to actions that takes a boolean operation and is used to filter actions only to applicable actors and targets; and add a special-case _result field to actions that takes some assignment/mutation operations -- it's just that they generally involve writing new big complex parser chunks, which is the most time-consuming part of this. so, it's doable but not really the EASIEST.

also i think (since hey this two-week span of dev time is half over already!!) instead of letting the player make a custom character, i'll just let them select one of the autogenerated characters to control, since that's much simpler to do. then, when their character comes up in the action list, they'll have a choice of events to run, rather than having the event automatically picked.

i mean, secretly, the reason i picked this 'nemesis system' concept to go first is that it's a super flexible system that i could use in a lot of different projects, just with different data files (which is also the reason why i've been so fixed on having it use data files vs. have anything hard-coded). you might recall the same basic concept started off life a year or so ago as a dwarf fortress-style procedural mythology generator; with a somewhat different data file (and, you know, all the action stuff coded up) that could be what this does.

("mythology simulator" is in fact another thing on the gamedev concepts list, and it will in fact just be fixing up the code part of this while writing new data files. but i mean, i'm not gonna do that right after this b/c that would be a little too close to cheating)

well i spent way more time than i should've messing with the dumb technicality of monad instances, but i got something that seems to work nicely now.

( raw data file )

the final generator i'm using is PEOPLE, and the program kindly informs me that there are 501,545,375,139,762 distinct combinations available. (the vast, vast majority of them are from names)

here are a few examples: ( output )

anyway now i really need to start working on something aside from just expanding the generator. like: actions! i have a rough syntax worked out for how they'll fit into the data file and be parsed, and after that it's just a matter of... parsing them and running them.

the goal with these challenges is, aspirationally, first week doing architecture, second week fleshing out a playable prototype. which means i need something playable in the next few days, and that means: actions + generated population + pc control of an actor, all of which are reasonably big things to do. so uh, gotta get on that.