ivysly.com - blog

why i still solo dev

Mon, 27 Jul 2026 00:00:00 +0000

it’s because of money. for one, it takes a lot of money to hire someone to do something full-time if it is something they aren’t already obsessed with doing. but it’s true that i could probably afford to do so after selling a game that made a lot of money. the other issue is money.

when developing and designing a game myself, for myself, my motivations are so transparent as to be tautological. i make games because i want specific games to exist so i can play them. that’s the top and bottom of it. i make games in order to play games i want to play. this entirely informs the design process. if some feature more makes the game into a game i want to play, it goes in the game. if it doesn’t, it doesn’t. hiring someone to be a part of this process creates an incentive problem. they aren’t necessarily contributing to the game because they want to play the specific game that comprises the specific elements they contribute. their contributions may categorically be those which the contributor doesn’t actually want to experience themselves, where mine cannot. this is fatal. once money is involved, i can only know that they are contributing because they want to make money. between me and this person, there is always a layer of distrust. they are incentivized to do as little as needed to meet perceived expectations and further their own career. whether or not they choose to act differently is an artifact of their personality, but the incentive structure doesn’t change. this is the unavoidable compromise of creative, commercial, hierarchical projects in capitalism, and the results are unavoidably inconsistent.

of course there are many great games that are great because of a team’s shared commitment to a greater vision (most in fact). even if the specific ideas among individual contributors differ, the predominant attitude in these teams is of co-operation toward realizing a work of high quality. but these circumstances are hard to come by. my game made a lot of money, but it didn’t make enough that i can keep churning through teams until i happen upon a selection of weirdoes who A) share similar motivations to me, and B) have good taste, and C) have the skills to match. i could only cycle so many times before wasting too much time and money and creating ruin for myself. otherwise, i could continue working for free, alone. witness my decision in effect.

i suspect it is getting harder now than ever for anyone to find a group of people to make great games with. it’s getting harder to merely survive for most people, and it was already more than hard enough. the games industry is falling apart. my dream to command a crew of like-minded obsessives seems fainter than ever. it felt easier when i was poor; to suggest a suicide mission is a lot simpler when the stakes are the same for everyone. now there is a power imbalance. i can no longer ask someone who barely lives off their paycheck to work for free, even though i, too, would be working for free. the circumstances between me and this person are fundamentally different now, despite my attitude and approach being more or less identical to the way they always have been. it’s a bit frustrating, but i don’t have much room to seriously complain when my peers are on food stamps.

so it seems then that my last option outside of solo dev is to keep searching for other well-to-do creatives hiding in their own lofty towers in hopes i might convince any of them to waste some time with me. i haven’t had much luck. if you are a highly skilled craftsman with good taste, no monetary needs and lots of time, and for some reason you want to make a game with me, please email me at ivysly@protonmail.com

thoughts about mixins and components

Fri, 05 Jun 2026 00:00:00 +0000

i have been using Lua (now via fennel) with LÖVE for a while, and i have found that one of the interesting and likeable things about Lua is how simple it is to implement mixins.

mixins are an odd, rarely used but convenient concept in OOP similar to interfaces and components but not really exactly like either. a mixin is a class that is used by other classes to absorb its methods without directly inheriting that class.

(local Enemy (Object:extend)) ; the base class
(local CanBeHurt (Object:extend)) ; the mixin class

(fn CanBeHurt:get-hurt [self damage hurter] ; a mixin method
  (print (.. "owie i got hurt by" (tostring hurter) 
             " for " (tostring damage) " damage")))

(Enemy:implement CanBeHurt) ; implement the mixin on the base class

(local e (Enemy)) ; create an enemy
(e:get-hurt 100 "ivy sly")
; >> owie i got hurt by ivy sly for 100 damage

this implement class method (as implemented in the very good classic library) directly injects all of CanBeHurt’s methods to the Enemy class, such that all instances of Enemy can access the get-hurt method. If Enemy already has its own get-hurt method, the implement function will prioritize that existing method and quietly move on.

there are some interesting things you can do with this. i ended up treating them similarly to components. in my implementation, mixins can be applied at the object level as well as the class level, and they have a special init method that is treated essentially as extended construction behavior. for example, some Enemies could randomly spawn with a FireAura mixin implemented on the instance that initializes them with a self.fire-radius value, adds an update callback to search nearby players to damage and a few methods to help with this:

(local FireAura (Object:extend))

(fn Enemy.new [self]
  (when (rng.percent 25)
    ; automatically call FireAura:mix-init on self with all parameters
    (self:instance-mixin FireAura 50)))

(fn FireAura.mix-init [self radius]
  (set self.fire-radius radius) ; set to 50
  (self:add-update-callback 
    (fn [self]
      (each [_ player (ipairs (self:get-nearby-players self.fire-radius))]
        (self:fire-aura-attack player)))))

(fn FireAura.fire-aura-attack [self player]
  (player:get-hurt 1 self))

when Enemy spawns, there is a 25% chance for that instance to implement the FireAura mixin, which calls FireAura’s mix-init method on the Enemy instance, and then injects all its methods (effectively just fire-aura-attack in this instance). what i like about this system is its convenience; all methods and values are top-level. the mixin is effectively invisible. you can access self.fire-radius directly from the Enemy instance, use the mixin methods and behaviors, all without typing FireAura all over the place. i’m not actually sure this is just a mixin anymore with all this extra behavior, but it’s effectively the same idea: inject the behavior from one class into another without dealing with complicated inheritance hierarchies. one could see now how this might be related to components, so let’s compare.

components, in contrast to mixins, are usually more visible, and less entangled with the object that uses them. a component is typically expressed as another data structure explicitly contained by an object. imagine an alternative implementation of FireAura:

(local FireAura (Object:extend))

(fn FireAura.new [self radius]
  (set self.radius radius))

(fn FireAura.fire-aura-attack [self player]
  (player:get-hurt 1 self))

(fn FireAura.update [self owner]
  (each [_ player (ipairs (owner:get-nearby-players self.radius))]
    (self:fire-aura-attack player)))

(fn Enemy.new [self]
  (set self.components []) ; simple list of components
  (when (rng.percent 25)
    (self:add-component "fire-aura" (FireAura 50))))

(fn Enemy.add-component [self key comp]
  ; add it directly to our table so we can easily index it
  ; e.g. self.fire-aura.radius
  (tset self key comp)
  ; also add it to the component list for easy iteration
  (table.insert self.components comp))

(fn Enemy.update [self dt]
  (each [i component (ipairs self.components)]
    (when component.update
      (component:update self))))

in the business of safe, clean code, this is probably superior to mixins most of the time, if requiring some extra work. but nobody said gamedev has to be safe or clean—would i be using Lua if i cared about silly things like type safety?—so what other benefit might object composition have over mixins? i think the obvious answer is that components are non-destructive. you can add a component to an object, then later remove it without pain. mixins tightly couple with classes that implement them, making them less flexible at the instance level.

but mixins are so convenient, aren’t they? i always optimize for laziness, that is, typing less, so i find the benefit of top-level field and method access hard to overstate. i am a big fan of duck typing. i’d much rather check for a simple obj.fire-radius number and ignore when it’s nil then have to go through the extra steps of checking something like (and obj.fire-aura obj.fire-aura.fire-radius). call me petty i guess. so here are some deranged ideas i have had about making components more mixin-like while remaining non-destructive.

option 1: unique field names

create a DSL to register every component with a name and the name of all of its fields, ensuring each field name is unique. something like:

; add a new component to the global component registry with all field and 
; method names exposed for easy checking & removal
(defcomponent FireAura
  field "fire-radius" 50 ; default value?
  method "fire-aura-attack" (fn [self] ...)
  ...)

when you try to define a component with fields or methods that collide with the name of another component, it would error at compile time. doing this would let you apply components essentially as collections of string keys, and since there are no collisions, you wouldn’t need to contain them in separate structs.

(fn Enemy.new [self]
  (when (rng.percent 25)
    (self:add-component 
      FireAura 
      {"fire-radius" 60}) ; default override?
    (print self.components.FireAura) ; >> true
    (print self.fire-radius))) ; >> 60

this is obviously insane. the main issue with this is how brittle it is. what if there are non-component field names we need to watch out for? what about overriding component behaviors on specific instances? we also no longer get a major benefit of components, which is that components can themselves be objects, with all the nice things objects let you do. instead this turns them in to a loose bag of key-value pairs. and despite technically being less destructive, it doesn’t feel any better considering all the ways it could easily go wrong.

option 2: reduce declaration redundancy

a bit of a compromise. if we can front-load component access, then we can do roughly the same amount of typing, if a bit more. however i think we can do better than the following example:

(fn Enemy.some-method-that-uses-lots-of-components [self]
  ; `let` is just fennel's way of declaring multiple variables in 
  ; sequence.
  (let [comp1 self.comp1
        comp2 self.comp2
        comp3 self.comp3
        comp4 self.comp4] ...))

i suspect we can cut this approximately in half with a hypothetical let-self macro that assumes self access.

(fn Enemy.some-method-that-uses-lots-of-components [self]
  (let-self [comp1 comp2 comp3 comp4] ...))

this would compile to the same code as above. where it gets messy is combining other variable declarations…

(fn Enemy.some-method-that-uses-lots-of-components [self]
  (let-self [comp1 comp2]
    (let [derived (* 2 comp1.some-key)]
      ; assume for some reason we couldn't access these earlier:
      (let-self [comp3 comp4] ...))))

suddenly we see more nesting and breaking up of variable declarations this way, making it hard to understand at first glance. maybe instead we could use a macro let& that works like normal let but allows opt-in self-keyed vars with a special identifier prefix:

(fn Enemy.some-method-that-uses-lots-of-components [self]
  (let& [&comp1
         &comp2
         derived (* comp1.some-key 2)
         &comp3
         &comp4] ...))

this feels cleaner but we run into a couple issues. the first issue is i can never remember where & is on my keyboard and i have to look at it half the time lmao. typing symbols tends to slow me down a little. then there’s the problem of dealing with identifiers that actually have & in the name. it feels dirty and slightly limiting. it also isn’t especially readable at a glance unless you format it very clearly.

option 3: evil metatable bullshit

never do this, but what we could do is override __index on our Enemy object to automatically find component values:

(fn Enemy.__index [self key]
  (var value nil)
  (var found false)
  ; search through all our components
  (each [i component (ipairs self.components) &until found]
    (when (. component key)
      (set found true)
      (set value (. component key))))
  (if (not= nil value)
    ; if a component with a value at that key exists, return that
    value
    ; otherwise do a normal __index check
    (. Enemy key)))

(fn Enemy.some-method-that-uses-lots-of-components [self]
  ; automatically finds the actual some-key in self.comp1
  (let [derived (* self.some-key 2)]
   ...))

this is obviously horrible because adding another component with a conflicting field name can silently change behavior in ways that are hard to debug. there are no unique benefits i can think of to doing this that are not covered by other options. don’t do it

option 4: grow up

well yes, maybe i should just get used to a component based object structure and using my fingers to type a little more code. it’s not that annoying. just a little more annoying than what i’m already doing right now. but maybe being annoyed is good sometimes in a time when it is so easy to let my brain smooth over and let trillion dollar robots do my typing and my thinking for me.

i'm getting sick of sexy

Sun, 17 May 2026 00:00:00 +0000

i saw the game Motorslice recently, and i can’t say it doesn’t look perfectly good at what it is setting out to do—though i have not played it—but reflexively i asked myself this question i seem to keep asking myself over and over again the last five or six years: why is the player character so conspicuously fuckable? i understand that sex sells, and i so too hate to knock someone for being true to their vision, but my main gripe about the material, from the critical perspective of a game designer (thus a narrative designer and a character designer and so on), my main gripe is how utterly obvious all these indie gamedevs are getting about sex appeal, without any of the thematic justification needed to make it work. why, again, does the upcoming DoubleShake feature yet another doe-eyed, inoffensively curvaceous young anime woman, graciously stripped of any of the interestingly dissonant design elements present in her parallel Marina, protagonist of ancestral Mischief Makers, herself already a likeable, mostly unchallenging design? don’t we think it would be more interesting, daresay more subversive even, as this trend continues, to star in her place a big, burly, hairy, Mike Haggar sort of gentleman, or an old fat woman, or christ anything else at this point? try this exercise: any time you see one of these games, and there are many, imagine all the sexy anime creatures are Mike Haggar. it’s almost always an improvement.

speaking of Big Michael: though his parents Capcom themselves are known for leading the industry in designing gorgeous video game babes, even going so far as to rework our own stupid superhero designs into items so fascistic in their beauty it feels uncomfortable to even acknowledge them as part of the same lineage as our own shoddy scrawls, yet they also, evidently, possess an incredible mastery over that which above all else great artists value: contrast and restraint. if you simply make everyone maximally cute and sexy, there is no dimension to it. there’s nothing to hold on to. one would quickly lose awareness of Psylocke’s beauty, of bawdy Felicia’s outfit and conduct, without the presence of the hunchback Zangief and his disgustingly bulging, scarred muscles, of the inhuman Shuma-Gorath, of savage Wolverine, of whatever the fuck is Amingo. the key aspect is balance. to its credit, Motorslice achieves this to some effect by contrasting the character against her huge, dirty, mechanical environment, but can we agree at this point that the “beautiful woman versus ugly world” trope is at least a little played out?

i am fully aware of how easy i am to disregard here. my foremost artistic achievement is stick figures. but you don’t need to be a particularly skilled character designer to come up with a character more interesting and thematic than a silent woman who is attractive. i only humbly suggest to the budding indie developer to try something interesting instead of something boring

there is no such thing as canon

Sat, 09 May 2026 00:00:00 +0000

something that’s been a confusing annoying pain in my neck for the last forever is this cultural notion of ground truth in fiction, that somehow a collection of works and adaptations can form a singularly truthful throughline, as if the thing an episode of G.I. Joe has over those doubtlessly outnumbering works of fan fiction devoted to its musclebound subjects is, of all things, credibility. this is a grave category error approaching mass hysteria. we have been conditioned to accept this for decades, for one with the ever extending and obviously violent legislation and enforcement of intellectual property law (finally, we can publicly write a fan sequel to The Little Engine That Could in 2026 without being considered a criminal in the US) and it’s hackneyed at this point to even mention the Bible, which really is countless books written in different languages by thousands of different people, but still somehow one Word. truth has always meant nothing; did you know that Super Mario Bros. 3 is actually a stage play? never mind the fact that it’s a fucking video game

i confess i have no taste

Thu, 23 Apr 2026 00:00:00 +0000

as my status as an artist is self-appointed, in the same sense that a usurper rules de facto—that is, by individually declaring it, and individual use of clumsy brute force to attain it, thus it is the truth, regardless of basic democracy or even common approval—maintaining an air of artisthood seems of greater importance to my ego than that of any natural artist i know. those are born artists, or people who understood their path from a young age, and were willing to work for it. i was never willing to work. i am only a suburban-born, middle-class dropout, raised in a household that revered art only in its humble, suburban, middle-class way, that of novel thrift-store lamps, family movies, Dave Grohl, my mother’s naïve yet proficient and charming portraits and life paintings and watercolors, my father’s technical mastery in copying metal riffs and organizing his music collection. my artistic life was steeped early in the invisible ubiquity of kitsch, which i loved with an almost underserved reverence, it being all i ever knew, yet so important has it been to me that culture considers my art one of its noble elements that i’ve tortured myself into making work out of what is supposed to be the greatest wellspring of joy in life, ART, further pained by the awareness that my shallow efforts will never elevate me above the truth that i am just a well-disguised Darger type: an uncultured, unknowing isolatee, disturbed by sexual and political insanity, and all-around too unwell to be a member of society, let alone the Canon. well, I’m tired of this stupid charade, and I’m convincing nobody.

let it be known that i play fewer video games than working men with a tenth the means and time; that i read little and very slowly; that i just watch new movies at the cinema and random crap i pirate that “seems good”, and that a “classic” film to me is often closer to 1993 than 1941; that, by my observation, holistic consumption is a natural behavior for the natural artist, an obsession not just in his own work but for the art that defines him, yet an uncomfortable and annoying slog for me. there are moments of sublimity, yes, sometimes life changing moments, but they are crowded by an insecure trudging through works i force myself to enjoy, and analyze truthfully, all in the name of “improving my taste”, so i can be a better artist. because that is the whole point of all of it: i want to make art, and i’m concerned with making art that is good, and which i personally like. yet i don’t really care as much about absorbing external sources in the same way a natural artist does. my obsession is singular to making the thing, not looking at other things. deeply, i’m not a lover of art, but of the craft, so the art is in a sense my medicine or my homework—i must take it because it will help me with the thing i truly care about.

but i’m ready to accept that i will gain little by plowing through the world of art at a pace or in a place not suitable for me, and while i extol the benefits of staying uncomfortable with practice and intake, it will do me no good to take so much or such bitter medicine. with this manifesto i only want to declare that i am of relatively few influences outside myself, yet many inside, so far as that, while maybe no longer an outsider artist, i am certainly and forever still an “insider artist”; there will be more classics i miss than which I’ll ever know—let alone reference—and, ultimately, it’s alright. i only want to re-learn how to love deeply the few things i can take in before i burn out or burst open. i’m ready to Let Me Enjoy Things.

gameplay is art

Fri, 20 Mar 2026 00:00:00 +0000

let me first define art: art is whatever i think is art. creating games is an art. playing games is an art. gameplay is art and gamers are artists. artistry is itself a game that creates art. in the case of game development, artistry is a game that creates art that is a game that creates art.

it is now commonly accepted that video game developers are artists. many people however don’t seem to think of gameplay (the action of a gamer playing a game) as art on the terms of art alone. most serious gaming as-vocation is in the form of competition (esports, speedrunning) or as a background activity for online entertainers. neither example is necessarily gameplay-as-art. there is an art to them, but it’s not innate to gameplay—it just involves gameplay to serve its own specific kind of art. all gameplay can be art on its own if only you framed it.

games are still going through their Modern period. there is an abundance of self consciousness. the relationship between game and gamer has never been so uncertain. winning and losing is just a formal convention (and law, as video games are defined and bound by laws, unlike meatspace games which are built of breakable rules), a pretense of motivation with which the gamer can choose to play along or ignore completely. could a game be a tool? obviously yes. maybe we should ask ourselves when making a game: how can this be useful? i don’t mean useful in the sense of therapy. what I’m trying to ask is, in the case of the gamer-artist, how do we better make our games themselves tools of art? videogames as explicit creative medium is a mature form at this point, made unquestionably so by popular titles like Minecraft and Super Mario Maker whose gameplay is itself modal systems of creating play areas and then playing in them, but games without creative tools like these can still be recontextualized by their own residue like demo saves (emulation turned retro gaming into a demo sandbox retroactively) and even a game with no residue is changed by the presence of an audience, even if just the audience of the player.

when designing a game, you are designing a space for gameplay with a certain kind or kinds of play in mind. but the designer-intended mode of play is an infinitely small subset of all gameplay. you can only account for nothing. all I’m suggesting is for you the designer to be aware of how the gamer can transform your game into their art, and design accordingly.

dream journaling for artists

Thu, 19 Mar 2026 00:00:00 +0000

with some awareness of irony as i enter month 4 of my latest creative block, i thought i should write a little post about dream journals, my preferred tool for finding ideas. the practice of dream journaling feels enriching in the same way that making art feels enriching, and the best part is your brain does most of the work without any conscious effort. i’m not going to get into psychoanalysis or dream interpretation in this post, as that’s a more open-ended and personal process. you are free to practice on me if you want, as nearly all my dream recordings are publicly available.

dreams produce the kinds of ideas and imagery that are nearly impossible for the conscious mind to generate unassisted, and by utilizing them in your art you are able to cultivate a style that is striking, personal, and unique. by paying attention to the contents of a dream, you are filling novel corners of your perceptual and thematic libraries, the places we look first when deciding on the form and content of an artwork. even as I currently struggle to make anything, dream journaling provides me an opportunity to bank ideas for later, a strategy that has worked out for me in the past; see: this game, directly inspired by one of my dreams and a work i consider among my best.

dream journaling is a simple practice that is almost self explanatory: have dreams while you sleep, and record your memory of them when you wake up. there are of course several complicating factors and choices to make that prevent people from starting. i have gone through long periods of inactivity myself. here are the common blockers:

“i wish i could do it but i never have dreams”

rejoice! all human beings on the planet (and most other animal species) have dreams every day. they just happen to be easier or harder for some people to access. the most obvious thing to take care of is your sleep hygiene. importantly, you need to make sure you’re getting enough sleep in the first place. sleep cycles occur in intervals of roughly 90 minutes. the most accessible dreams are had during REM sleep, which occurs at the end of a cycle, and the dreams you’ll remember are the ones that occur right before you wake. for many people, if they have a morning alarm, their body will restructure its sleep patterns so that they wake up consistently a little before their alarm actually goes off. the ideal scenario is that you get an appropriate amount of sleep (roughly 7-8 hours for most adults), and that you will be ending your last cycle, in REM sleep, right before your alarm goes off. this will maximize the chance you have a dream you remember, and is optimal for your health too—there is evidence to suggest that interruptions during deep sleep can be harmful.

there are some medications and drugs (weed) that suppress dream recall. it’s usually still possible if you make an effort to remember, though, because you are absolutely still dreaming every night. you can also take certain medications or supplements to improve recall. melatonin is an obvious one. just don’t take more than 0.1mg or you’ll actively disrupt your sleep.

don’t be discouraged if you don’t remember them frequently. if you cast your line you’ll eventually catch one. and as you start to remember your dreams, you’ll start to remember them more frequently and vividly.

“i have dreams I’d rather not remember”

there are different solutions for this, depending on what you mean. lots of dreams are nightmares. if you’re just worried about having dreams where bad things happen, i suggest you push through this—not only are nightmares always full of interesting details, they can also be useful for introspection and working through difficult feelings and problems. i find nightmares more cathartic than dreams that just provide wish fulfillment, because one ends in relief and the other in disappointment.

conversely, if your dreams are so severely unpleasant that they disrupt your quality of life and their effects on you persist when awake, then it’s time to see a professional.

“my dreams are just boring”

no they aren’t. you think they are boring because when you’re dreaming, dream logic is mundane. in the short period after waking, you’re still half operating under this logic, and by the time you forget, you’re only left with the feeling of the dream and that it was apparently boring. waking up and immediately recording what you dreamed has a twofold effect of bringing you into waking lucidity more quickly and allowing that fucked up dream logic to be put into context by real life. once you start recording, you’ll notice that you start to remember more about your dream, and further back—often the further you go, the weirder it gets. it’s not unusual for me to start at the end of my dream and prepend my recording with more and more details i remember about what came before. this makes sense, because typically we remember most what occurred in our dreams just before waking up. when trying to recall a dream to someone else, i think we go through this process without even realizing it.

“i want to do it but by morning i always forget”

this is going to sound silly, but it works for practiced lucid-dreamers and it works for me: verbally affirm that you are going to journal in the morning. plant the idea in your head. you don’t have to fret about it. just remind yourself as you go to sleep about your plan to log in the morning. if you’ve set up your environment to make journaling the natural thing to do, you are more likely to eventually get started in the first place.

“i don’t want to write a bunch down the moment i wake up”

well, it’s inevitable that you will have to put in a little work. what I’ve found is that it rarely takes very much writing to conjure the memory of a dream. i tend to focus on writing down the actual events and objects in a dream, because my memory will automatically fill in the details, vibes and emotions i felt when i was in it. however, it should be said that the more minimal you get, the more likely it is you won’t be able to remember it later. as of writing, there are only a few (maybe 3-4 out of 118) entries in my dream log that I cannot remember, and many of them are years old.

you don’t actually have to write either. a voice memo works just as well for many people. i used to use a physical notebook, but now i just type them in a notes app on my phone, sometimes with speech-to-text. you could even draw a scene from your dreams. a dream journal isn’t necessarily supposed to be a highly detailed log of written events, because the actual entries themselves aren’t fully useful on their own—the memory they evoke is what creates a lasting impact. do whatever is easiest to you. set up your environment to make it as easy as possible. i open up the app i use before going to bed and place the phone next to my pillow, so that it’s already there and ready when i wake up.

however, if you find you still just don’t enjoy doing it or get much out of it even after trying different things, then maybe you should just stop trying and move on. not everything is for everyone.

how to make a successful indie game

Sat, 21 Feb 2026 00:00:00 +0000

tl;dr

i have dawdled on making this post for a couple years now because ultimately i am not qualified. i am a dysfunctional loser who stumbled into market success in the arts, maybe as undeserving a person could get if you believe in anyone deserving anything at all. it’s also hard to write this because it’s going to sound a lot like “fuck you, got mine”, but that’s not at all what i’m trying to do here. in fact, i am actually trying to help the reader to not make a huge mistake and throw their life away. i believe that in most respects i am not aspirational, but as time goes on i receive dm after dm, email after email from people asking me for advice, real, serious life advice, the “should i drop out of college and pursue game dev” kind of advice that could easily fuck up someone’s circumstances if taken to heart. this makes me feel a lot of ugly feelings and think a lot of nauseating thoughts, so i just want to lay it all out here so that i can stop sending the same depressing message to all the people—kids, mainly!—who look to me for guidance.

you might think you want indie game development to be your #1 pursuit. okay. i will assume you don’t have the passive income or other means that would make it an easy decision. i hear some countries just toss you 20 grand if you say you are an artist. good for them. let me ask you to think about this question:

are you content with being poor for the rest of your life?

when i was a kid i always thought i was going to be a rock star. i wanted to be like my dad who was, to me, the greatest guitar player who ever lived, and a rock star himself. thus i spent most of middle & high school making crappy tunes in fl studio. i didnt care about school because i was going to be a rock star. i never had thoughts about getting a job (my parents hated their jobs, it wasn’t who they were, i could see it, and i decided i would never do that, i would do what i wanted to do) because i was going to hit it big. i spent my adolescense in a ridiculous dream that cost me my academic and social development until the obvious reality finally snapped me awake. no matter how good i was, and really, i was not that good, it didn’t matter, because the world is so huge and so many people want to be rock stars. how do i compete with someone smarter and more talented than me, someone who has more connections, more intrigue, more appeal, more money, more luck?

i had to decide that i loved making stuff so much that i did not care if i would be poor and unknown forever. i only wanted to spend my time doing one thing, at any cost. anything was better than working. i am disabled (most people are) so i applied for social security income and was approved. for about 6 years i lived on around $9,000 USD a year, which at the time was already far below the poverty line. for two years i lived in a dining room, and i was lucky. the only thing i had was free time to grind away. that was all i wanted. the moral here is that i never had to ask anyone if i should do this. it was a shitty way to live and i can’t recommend it to anyone else, but i knew what i wanted, that i still want it, and that i will go back to living that way if i have to.

the financial success of my financially successful game was a complete accident. i was not trying to make money with it. i’m a weak, lazy person and i had long given up entirely on any ambition to turn my hobby into a job. it happened to me, and i took the path of least resistance. this is not true for everyone who makes a successful game, but it should highlight the most important aspect of success: it can happen to anyone, and it can pass anyone by. you are not special, and i am not special except that i was lucky. i know someone will respond with some motivational bullshit about “making your own luck” which is true to the extent that you are more likely to win a jackpot if you play the machine 1000 times versus just once or none at all. it comes with a cost. you don’t force it with skill and hard work. skill and hard work are just the prerequisites to getting lucky at all.

i was lucky in other ways too. i knew i wouldn’t be homeless if it came down to it. my family would have bent over backward for me and my siblings, as they have done before, but it would have destroyed us in the process. i am lucky to have a partner in my life who took care of me, kept me accountable, and in a way shared my absurd lifestyle. i am luckier than most and i still gave up long before i happened to win the lottery. i’d return to shame and poverty if i had to, even though i rather like having a safety net and money to throw around. it would be my first choice. but i don’t think everyone needs to be this way to find their own version of success. you don’t have to quit school. you don’t have to quit your career. you can work on projects on the side. this doesn’t make you less of a game developer, less of an artist. you don’t have to make money doing something to love what you do. making art is not about grand gestures and taking huge risks, it’s about the love of the game and putting in the time that you do have. if you merely made something you are proud of, if you made a game you like to play, or even if you made a complete piece of shit that you hate, there’s success in there. that i got more money and recognition than another artist in the scene is a sick joke. i don’t have any more answers, any more insights. there is a bigger topic to explore about how people (in the US at least) are not allowed the humanity of leisure to do what they love, but i’m not good at talking about that. all i want to discuss in this blog post is my advice to those who keep asking for it. i say only sacrifice when you are sure, and be aware of the sacrifices you are about to make. don’t ask me if you should do what i did. if you have to ask…

public statement to all ice employees

Wed, 28 Jan 2026 00:00:00 +0000

KILL YOURSELF

solo gamedev with lisp

Sun, 14 Dec 2025 00:00:00 +0000

this last month or so i have been using the Fennel programming language, a Lisp dialect that transpiles to Lua. if you want the quick pitch: it’s a fast, imperative-oriented Lisp with macros that i think is perfectly suited to solo indie gamedev. i love it for all the reasons i love Lua and more.

i had been interested in using a Lisp for some time—actually, had i the option, i would have probably picked a hypothetical LuaJIT With Macros first—but it always felt like there were hurdles and gotchas that prevented me from using it productively in game development. first is that the ecosystem is obviously pretty tiny for many Lisps. tooling, build systems and libraries can be a bit DIY, especially if you are not using Emacs (i might give it another go, now). Fennel circumvents much of this by just being Lua. paredit + parinfer with VS Code does the job of removing the parentheses pain well enough. this is the lesser issue. the bigger barrier is that Lisps are generally regarded as being on the functional side of programming languages, which, in the gamedev universe, means unknown, treacherous waters. games are highly stateful, highly imperative systems. it can be onerous trying to squeeze the slippery shape of a game into the result of a pure function. not to say that functional techniques have no place in gamedev, just that i find it difficult to apply them at the structural level. while some people are happy to take on such a challenge, i feel it is more practical for me to work in a perspective i’m familiar with. Fennel just so happens to feel exactly like Lua with a different syntax, because it is. i’m essentially doing the same things i was doing before, with a few trade-offs. this led me to a breakthrough: Lisp doesn’t have to be anything. there are very few limits on what they can be. a Lisp has become in my mind solely defined as a direct representation of an AST made of s-expressions. you’ve probably seen s-expressions before. they’re just hiding in JSONs and XMLs. you can write a Lisp with all the features of another language. it doesn’t even need to have a linked list data structure (Fennel’s lists only exist at compile time—even then, you spend most of your time just interfacing with Lua tables, with lists themselves in fact just being tables with some metadata). any other preconceptions you have about Lisp, you can safely let them go. Lisps don’t even need to have parentheses.

Fennel is not really at all a pure-functional or declarative language. due to the severe restriction of being a zero-overhead Lua transpiler, the Fennel language doesn’t even ship with any of its own functions. what it does have is access to all of Lua’s built-in functions and table operations, many of which are good old imperative, stateful operations. you very well could turn Fennel into a pure, declarative language, or you could do something completely different. that’s because Fennel (and Lisp) isn’t really anything at all but a syntax. it doesn’t have to be anything until you make it something, and you are given carte blanche to do so with macros.

with macros, a Lisp essentially becomes an extension of the programmer’s mental model of the program. it’s amazing how simple it is. you should probably exercise more prudence in teams, but as a solo developer, it’s pretty amazing to be able to freely add my own natural-language constructs to the language with no runtime overhead. for example, one of the most common mathematical operations i tend to do in game dev is dividing things by two. somevar / 2 shows up hundreds or thousands of times in my typical code bases. in Fennel (and most other Lisps), it’s dead simple to introduce a macro (half somevar) that compiles to the same thing, both reducing symbol noise and increasing clarity of intent. there’s no function call overhead, so the only reason not to use it is when semantically it wouldn’t make sense. this i think is an incredible feature for idiosyncratic solo devs like me, because while you might make your code unreadable for anyone but you, it can become highly readable for you, and even more so quickly writeable. again, a Lisp can be anything. this means it can be exactly what you want out of a programming language, with technically no concessions except that you might have to put in the work to get it there (there is a reason most DSLs written in Lisp tend to look a lot like Lisp).

Fennel and LÖVE go very well together. i have found that plugging into my existing codebase was very easy. even getting an in-game REPL going only took a few minutes, and already i can sense the crazy amount of power it gives me to tweak things on the fly. and since it’s just Lua, it might be one of the faster Lisps when JITted with a great incremental garbage collector, very well suited to gamedev. being a solo dev, for me, means writing stuff quickly without spending too much time on tedious bookkeeping and careful structuring one might need to do in a larger team. for the lone gamedev, i think a controlled amount of yolo-coding is how you get shit made. this is a huge strength of Lisp.

one funny problem with the switch from Lua is that now my engine uses three naming conventions; camelCase for the love namespace, snake_case for my own preferred identifier style in Lua, and now kebab-case for all the symbols in Lisp. things can get pretty hairy when writing code that interfaces with all of these. nothing i can’t fix by rewriting my whole engine in Fennel of course.

another small pain point is the notation for arithmetic. it’s just not as intuitive to read a * b + c + d - e - f in the prefix notated form (+ (* a b) c (- d e f)), but i suspect it could eventually end up being just about so, and i’m already developing adequate proficiency anyway. disregarding Lisp for this reason feels about as arbitrary and nitpicky as dismissing Lua for starting array indices at 1. you get used to it.

as of writing i have only one completed project in Fennel. i just released a jam game i made largely with Fennel, plugged in to my Lua LÖVE engine. i suspect my opinion will change in various ways as i continue to use it.

anyway with my main theses out of the way i am excited to just jabber more about the ridiculous utility of macros. the real pervert crap. it’s often the case that you want to repeat the same complicated logic on multiple values across multiple lines, but introducing a lambda (in Lua, at least) may add an unacceptable performance overhead, and putting it somewhere else in the program restricts its utility as a closure. on the contrary, inline macros let you capture the context like a closure and duplicate logic without polluting your code with a bunch of repeated procedures (which could easily break should you forget to update all of them when you need to change it), with none of the overhead of creating and calling an actual function. as a very minimal example, imagine this naive code, in the input handling function for the player somewhere:

(if (input-held? "up")
  (move-player! 0 (* (- speed) delta)))
(if (input-held? "down")
  (move-player! 0 (* speed delta)))
(if (input-held? "left")
  (move-player! (* (- speed) delta) 0))
(if (input-held? "right")
  (move-player! (* speed delta) 0))

in this example, it would be overkill to introduce a local function to simplify the logic, and is currently a lot of noise to repeat the logic for each direction. a macro can combine the best of both options while making the important logic much more clear. plus it keeps all relevant code in the same place without you needing to search for another function that exists somewhere else. it does all this with no runtime overhead, as the following snippet compiles to code roughly equivalent to the previous block:

(macro player-input-move! [...]
`(do ,(unpack
  (fcollect [i 1 (select :# ...) 3]
    (let [(input dirx diry) (select i ...)]
      `(if (input-held? ,input)
          (move-player!
          (* ,dirx speed delta)
          (* ,diry speed delta))))))))

(player-input-move!
  "up" 0 -1
  "down" 0 1
  "left" -1 0
  "right" 1 0)

this compiles to:

(do
  (if (input-held? "up")
    (move-player! (* 0 speed delta) (* -1 speed delta)))
  (if (input-held? "down")
    (move-player! (* 0 speed delta) (* 1 speed delta)))
  (if (input-held? "left")
    (move-player! (* -1 speed delta) (* 0 speed delta)))
  (if (input-held? "right")
    (move-player! (* 1 speed delta) (* 0 speed delta))))

the only meaningful difference being a few extra (cheap) multiplications, which could easily be refactored out as needed. i’d bet money that LuaJIT ignores multiplications by zero literal on hot loops anyway. when performance isn’t a concern, it usually will be cleaner to simply write a function, of course, but game dev performance is often death by a thousand cuts, with lots and lots of little inefficiencies that pile up. macros in Fennel allow you to define behavior anywhere free of risk.

you can get a lot more complicated than this too. i wrote DSLs for defining object classes and state machines. the latter only took an afternoon. I’ll leave you with what i am calling the brohoof operator: a macro that divides two values in the opposite order they are passed:

(macro \ [lhs rhs]
  `(/ ,rhs ,lhs))

(\ 2 1)
>> 0.5

there is no grass to touch anymore

Mon, 15 Sep 2025 00:00:00 +0000

“Disneyland exists in order to hide that it is the ‘real’ country, all of ‘real’ America that is Disneyland.” –some asshole

every day i go on a walk because my gf calls me fat if i don’t and it makes me feel bad so i do it. when i go outside for my daily shame walk i think about how there hasn’t been a time in my life longer than a week or two where I haven’t heard the sound of cars, haven’t seen a billboard, haven’t looked upon all the asphalt and concrete and wondered what the world looked like before we paved it all into stupid shitty roads and sidewalks.

recently a bluesky post reminded me of something said by Shigeru Miyamoto in an interview:

“If it’s really nice outside, you should go play outside. And I tell that to people who want to be game designers as well, you know? If it’s a nice day, you know, go experience outside, because really, I think there’s an important factor that it’s your personal experience.”

and wow I bet that shit is so useful if you grew up in the Kyoto countryside 70 years ago but I think I speak for the rest of us when I say please keep your advice to yourself dumbass! there is no outside anymore. in a physical sense it is true I can drive to the river or the mountain (and truly my neck of the woods is in no way starving for natural features) but there is no longer any way to spend time in these places in good faith. how can I just go outside and play? have you seen the news? have you seen what people are doing to each other? outside is fake now. you go outside to pretend you aren’t still online in your heart.

games are an escape from reality as much as prison is an escape from civilization. game design is about creating the most comfortable cell. maybe the most ethically designed game would offend so thoroughly the sensibilities of its gamer that he or she would wake up and finally, fully understand their physical and spiritual carceration and escape into the dinosaur world

on juice

Tue, 29 Jul 2025 00:00:00 +0000

put screenshake in your game. screenshake is the secret to a game that feels good. if you don’t put it in your game, your game may not feel good. the purpose of a game is to feel good. we have perfected the formula to making a game feel good. if you follow this formula your game will feel good and thus it will be good.

video games are just interfaces for sensation. we have extracted sweet sensation from pesky semantics. there’s no more need for intention. screen shake no longer has to convey impact. it doesn’t need to convey anything. just do whatever you want. we are currently developing a game that is nothing but shaking and squishing and sloshing. baddies flash white when you swat them but also the goodies and everything else even if you don’t swat them. particle effects. stop thinking about it and start feeling about it. we are looking into haptic ecstacy.

making a game is the real game. you need snapping and fizzing and swishing and zapping. i don’t care where you put it. put it anywhere. it’s a fucking video game. did you know that in 2024 the games industry alone pulled in $184 billion dollars? why would you waste your time thinking when there is money to be made? look at all the other games around you: they are squishy and huggy and cozy and every time you do anything the game rewards you with an outpouring of sickeningly sweet juice. your game needs to be sexual, it needs to simulate orgasm, and you need kids to buy it. what the fuck else are you making these for?

on scope creep

Sat, 28 Jun 2025 00:00:00 +0000

two game studios behind two highly anticipated games announced those games’ cancellations within the last couple weeks, those being indie studio Tendershoot’s Dreamsettler, the ambitious sequel to interactive fiction/internet simulator masterpiece Hypnospace Outlaw, and Riot-funded Hypixel’s Hytale, a Minecraftlike that was in development for over seven years. the major problem both of these studios cited was unchecked ambition (a desire to make the best game ever) and thus building these giant, untenable concepts and systems that ultimately demanded too much from the people working on them. the Vision can be so intoxicating it destroys any chance of a person actually making it real.

I want to give an extended answer to this question my friend asked me:

do you get scope creep feelings? how do you process them if so?

to quickly outline the term: scope creep is a process by which the hugeness of a project grows and grows out of control, until it is no longer workable, as the people on the project are repeatedly struck with an insidious brainworm: “the project would be way cooler if we just added this one thing…”. eventually the project becomes a clusterfuck of mostly cool new things that suffocate a now unrecognizable Core Vision, and often it is never finished. this has happened to you.

this blog post makes a lot of assumptions. one is that you are or you know a game developer or some kind of artist or craftsman or architect who works in a medium that requires a lot of time and effort to produce a single finished work, and you do care that these works generally get finished and maybe even shared with the world. if you’re someone who is cool with taking your time, not worried about the finished product, and just making yourself happy adding a bunch of little things to a big thing, keep doing that. ignore any advice you know doesn’t apply to you.

do you get scope creep feelings?

I get scope creep feelings. I deal with them all the time, for every project. I don’t think they are avoidable. obviously we all want to make the best game ever. but the game in your head will never exist, so you have to compromise with reality.

there’s always stuff that gets cut in the idea stage, stuff I’ll rip out of a game fully finished, and, in-between, a whole spectrum of scaling back cool ideas that are unjustified uses of time and effort, time and effort which could be better spent realizing the Core Vision.

how do you process them if so?

most games are about killing dudes. Given the right context, killing dudes is very cathartic. why shouldn’t that be true for killing ideas, assets, code, features, etc?

throwing things out doesn’t have to be a bad thing. it’s a part of life. when I started learning in adulthood how to cook, I threw tons of food away. maybe because i made something inedible, or i bought too much and it went bad. over time I began to develop a positive relationship with throwing food away, because it meant I was cooking.

after a short period of grieving the cool new thing I won’t be using in a game anymore, I find it easy to focus on the positives. there are plenty of advantages to cutting out a feature in a game. the most obvious and practical thing is that you reduce the workload for yourself. lower workload means you can spend more time on the stuff that really matters. consider all the loads of clusterfuck games that did release and still suck because they couldn’t reign it in and focus on the Core Vision.

I have developed this mindset over years and years of fatally overscoping. I started programming in 2015 with the goal of making games. each project was ridiculous. one of my first projects wanted to be similar to Cataclysm DDA. a 2018 project was supposed to be a Smash Bros—like. there are so many examples like this. I didn’t finish my first game until 2021 (six years of nothing!!!) when I began working with PICO-8, a game development environment that intentionally imposes very strict limitations on the developer, and it forced me to keep my scope reasonable. I finished that game in about a month.

some people feel like their time is wasted when they reach a dead end and they have to backtrack, that it is a negative outcome to be avoided. many are led to a scarily prevalent sunk-cost feeling and grow attached to bad ideas just because they fear scaling back so much. I just don’t think this is right. backward progress is still progress. it’s surely not as efficient as realizing your vision of the game perfectly from start to finish, but nobody can actually do that. realizing you’ve scope crept and scaling it back is a natural part of working on a complex system. it is just a thick branch in a tree of mistakes—you don’t keep a wrong algorithm in your code, you take it out and replace it with something else or nothing at all. you don’t leave in typos.

when scope creep happens you just have to focus on what you can get out it. what assets can you reuse? what ideas can you extract? if nothing else, what did you learn? I don’t remember a time when the answer to all these questions was “nothing”, so I posit that it’s never truly a waste. the Hytale developers will move on having if nothing else learned a very important lesson.

It is important to note that I’m not against adding easter eggs and fun stuff just because. that’s what games are made of. I just think a game designer can benefit from weighing the time and effort cost of adding (or keeping) a feature with the amount of substance it adds to the game, how much it helps to complement and complete the Vision.

the process

recently I posted this to bsky:

> I see good indie devs burn themselves out on huge projects and suddenly come out of hiatus with a little game that is way better and more focused than their prison opus and every time I want to scream: just do those games

I followed up with:

> don’t make a big game until for you it’s a small game

and I want to elaborate a little bit.

first off, I think if you know what you want to do, you should do that. if you are willing to do what it takes, and you can afford to do it, then you should make the ambitious game of your dreams. I’m only asking people to consider what they want, if they haven’t already, and if they are willing to really work for it, and if they really know that they truly are willing, and so on. but I know I don’t really need to say that to them, because the people who know what they want don’t need me to tell them what they want. that leaves the rest of you suckers. especially those devs in question burning themselves out on big games—I only want to suggest an alternative that can be just as fun and much lower stakes. I have outlined a 2 step process:

step 1. when you are deciding on a game concept, it can be difficult to know how big of a game you can make. I have a radical solution: look way, WAY smaller than you think you need to. unless you are an absolute newbie, there is definitely something you know you can make without question. maybe that’s pong, or even breakout. something of which you can envision the entire structure before starting any work. 100% confidence only. make that thing. if you are an absolute newbie, or you otherwise don’t have 100% confidence in pong, skip to step 2.

step 2. when you are done making that thing, it’s time to do something completely antithetical to this blog post so far: start up a project with a big vague idea, experiment, add whatever you want without any thought to maintainability or even finishing the game. if you are the aforementioned absolute newbie, this is where you make pong instead. you (probably) will not finish the game, but I think this is the best way to safely push yourself without heartbreak. it will give you an idea of what you are capable of, so when you return to step 1, you will notice that you are able to envision a slightly bigger entire game than you were last time. maybe substantially bigger. that’s it. return to step 1.

this is the process I have come up with accidentally over the last few years. accidentally because step 2 was always supposed to be step 1. it was always a feeling of, “okay, enough with these little projects, I’m going to make my opus, my Real Game. this time I can really do it.” then I noodle around for months and drop the thing because either it’s just too hard to implement the big ideas by myself or I just don’t have a cohesive enough idea to hold together such a big scope. subsequently, when I go back to making small games, I realize that the biggest game I’m 100% confident in making just got a little bigger.

I have been, entirely by mistake, employing what I now believe to be a highly effective strategy for self-learning and improving my skills, and maybe even for eventually getting to making that big game my kid self always wanted to make. I present it, modified to reduce suffering, for anyone to try.

ethics of the opus

something i feel is important and kind of overlooked is that games take a really long time to make, when compared to most other forms of art. the barrier to entry is already really high. a 3 month timeline is on the low end for a finished game, outside of time-constrained game jam challenges which don’t really work as a real development strategy for “full size” games. I estimate most indie devs working on long term (non-gamejam/tutorial) projects are spending about a year or two. imagine if it took that long to write a single song, or paint a single picture. we are at a disadvantage in that way to composers or painters, because we only get so many two-year periods we can make games before we die or otherwise lose the ability. I suggest that it is inhumane to expect each other to meet a standard like that. life is very short for a game developer. we have to be much more picky about how we spend our time than a painter or a songwriter. we have much fewer chances to find our voices. this is, I think, maybe the most important reason for one to consider making smaller games.

bottom line: check out PICO-8

Evil Egg

Tue, 10 Jun 2025 00:00:00 +0000

Evil Egg naked prostrating on the cold tile as the tub spout pours crashing into the open drain like a waterfall.

Evil Egg eating to quell the nausea of overfullness and starving on dandelion green.

Evil Egg knowing comfort under the flat white light of the aisle and checking out. Evil Egg decorating a martyr.

Evil Egg sleeping as the warm rain blankets her in the wide dark.

daydreaming with lua

Tue, 04 Feb 2025 00:00:00 +0000

i think many programmers are conquerors. they want to bend reality to their will. to this end, making a software is an intense power fantasy, one where the programmer is given a problem and full control over a system to solve that problem, leveraging the unimaginable algorithmic power of the machine to obliterate tasks that would have taken human computers lifetimes of effort.

in some capacity this is true also for creatives and really all people—there is an essential equivalence between making art and the process of daydreaming (the latter of which being a universal human experience) as commonly a form of wish-fulfillment. to develop a video game, i entertain both the power fantasy of programming and the wish-fulfillment of creative writing in a single process, to the immense satisfaction of my ego, and video games themselves achieve the highest potential for wish-fulfillment of any artistic medium.

at the beginning of 2024 i made a resolution to ditch Godot. I had used it for 6 years or so, and for much of that time i held so much optimism for it and its future. but years of big and little issues wore me down, and finally i decided it was time to move on. i was done with doing things the Godot Way.

instead i was going to build my own engine in FNA, a fork of XNA similar to Monogame, which uses the C# programming language. i really did try to do this, and i spent several months on the foundation for a 2d engine, but what i found is that C# and FNA became a sort of creative prison for me.

you see the problem is that i can’t honestly describe myself as a software developer but instead as an intuitive game artist, who prefers freedom of expression without regard to the convention or maintenance needed of business software. what i need is rapid iteration, to unconsciously feel the impacts of tiny tweaks to the sensations of a game, not theorizing and calculating large swaths of changes all at once and waiting for the program to be “correct” before continuing.

C# is not made for artists, it is made for businesses. this is true for the majority of general-purpose programming languages. C# is bureaucratic and cold, tough but fair. it’s not supposed to be a fun language because it is supposed to be a tool. it is the reflection of its creators who belong to a culture i reject as inhumane, thus its philosophy. so i have concluded that FNA just doesn’t meet the needs of the sole game artist and could, worse, be actively harmful to artists who don’t know any better. programming languages are not just one-way communication, they necessarily communicate to you how you ought to think about data and procedures, and in the case of the game artist this means your creative output.

the fact is, i wanted to try LÖVE long before i was ever interested in FNA. but something scared me about Lua, the simple, dynamic, interpreted programming language used by LÖVE. to me its simplicity hid intimidating depth. i had used it once before but i never really took the time to understand it. metatables, weird keywords, global magic methods—this was all very alien, 1-indexed arrays the least of my concerns. but i knew, deeply, even before my doomed tryst with C#, LÖVE was what was missing in my heart.

i have learned since i started using it that Lua is more than just pleasant to write. i should have been tipped off by the name and brand of the LÖVE framework: soft colors, rounded edges, a sort of pneumatic, inviting atmosphere to its website, which playfully warns that its community “sometimes gets too friendly”. all the clues are there. even the community-made libraries follow this theme, often explicitly; you will quickly find packages with names like makelove, love bone, quickie, moan, hump, and yes, hardon collider. this kind of thing might throw some people off, but after writing my second Lua-powered game, i have to say:

i understand.

Lua is a deeply erotic programming language. is this absurd to say? it is inviting and warm. there are no rules with Lua. it is not your boss but an equal and a companion. Lua says, “do what you want with me”. it is surprising but fluid. debugging is more feeling than rigor. even the name is feminine and flirtatious. it is everything that C# is not. Lua i come home to.

sex is sort of like plugging in. despite having little in the way of modern package management, Lua allows the programmer to easily incorporate external library code unaltered, even with vast differences in structure, because Lua is highly polymorphic in both a mathematical and biological sense—that is, one API might be completely unrecognizable to the other, but you can still plug in. you could call that chemistry.

i must recognize that the source of my daydream is the subconscious. it is impossible to ignore that my desire to make art is deeply entangled in the immediate, libidinal drive of the id, and barely held enough together by my ego to result in coherent output. is it absurd to model and encourage this with my tools? Lua is as satisfying in this way as you can get in the form of a programming language (see also Lisp) because what it allows you to do maps directly to the innermost desires of the human psyche. Lua was made for pleasure and play. while this may not be a good fit for the anti-human culture of business software, i think the benefit to creatives is by now self-evident.

game artists are in a weird place where expression is steeped in procedure. art techniques are often formulaic, but the foundation of the art of programming is formula. this is where we make little prisons for ourselves. i would think the goal of the game artist is to instead build a bedroom.