lexyeevee

troublesome fox girl

hello i like to make video games and stuff and also have a good time on the computer. look @ my pinned for some of the video games and things. sometimes i am horny on @squishfox



lexyeevee
@lexyeevee

the agonizing part about trying to do anything off the beaten path in an especially novice-friendly engine is that no matter how you try to phrase your task, the search results are going to be ten thousand copies of people asking extremely basic questions like "how do you hide the textbox"

and then if you try to ask in support channels you have to fight against a current where they assume you're really just asking how to hide the textbox, and if they're not an engine dev then chances are they actually don't know how to do more than hide the textbox

anyway i had some adventures today


lexyeevee
@lexyeevee

there is so much stuff in that engine, including several of its own DSLs, multiple animation systems, a parser library, and compatibility going back fucking forever. it's got a lot of documentation but it's also impossible to document fully. i don't know what "fully" would even mean.

the upshot is that unless you extremely know what you're doing at all times (or extremely don't know what you're doing and just do really basic stuff), it is really easy to make really weird fiddly annoying little fuckin things happen. little gremlins in your game

today i had a thing where a single small part of the dialogue box would flicker on every new passage. just for like one frame, like it was rendering slightly wrong but then worked itself out one frame later. and that is the kind of thing that irritates the piss out of me in my own work. it's jarring and ugly and feels like it makes me look like i do not know what i am doing

and after exploring multiple possible causes, including "this might be a bug in renpy"¹, i discovered that this was a result of my own attempt to use some shorthand in an ATL block.

i'm not going to dive entirely into this but the gist is that you can animate display properties by doing stuff like this:

transform hover_fade:
    alpha 0.25
    on hover:
        linear 0.1 alpha 1
    on idle:
        linear 0.1 alpha 0.25

where the linear bit is an easing function to make the change happen over time. but i didn't want an animation in this instance, so i figured i would avoid repeating myself with the initial line:

transform hover_peek_up:
    on hover:
        yoffset 12
    on idle:
        yoffset 16

because it starts out idle, and this sets the properties instantly, so it should just do the on idle stuff right away and everything should be fine.

reader it was not fine. turns out everything starts out in a start state for, i guess, one frame, and the states are exclusive, so the yoffset would remain at its default of zero for that first frame.

and i didn't notice this at first because i didn't run through the script while i was putting the UI together; i just let renpy reload on the same line. so the flicker seemed like a new thing that started later on!

and this is just the kind of thicket i bumble into all the time. it's not like there's a State Examiner. these things are even called "events" in the documentation, which implies various properties, only most of which are correct. you can't even reliably debug print in a lot of places, because renpy peeks into the future to start loading images before they actually need to appear.

so no one with only a surface-level understanding of renpy could possibly diagnose this entirely self-inflicted problem. if you just copy/pasted and modified examples you would never even think to write something like i did. but someone who's been programming for a while might have DRY brain and try something like this. and now it'll rattle around in my head forever as a new particular pothole to steer around.

also the solution is on idle, start so it fires for both. don't know of a way to avoid repeating yourself with the alpha one though


¹ young programmers, heed my words: it is never a bug in the platform.

well ok. when you're starting out, there can be a tendency to think that "my code isn't doing what i think it should" means "there's a bug in the computer". and usually it isn't, especially if you haven't yet learned how to accurately transcribe your desires as code. however, if you do this long enough, you will run into genuine bugs in the platform, and you'll get a sense for what they feel like: rare (relative to the popularity of the platform), often bizarre, maybe a result of specific unusual circumstances that explain why no one else has seen it before. anyway i'm telling you this to stress that i would not reach for "this might be a bug in renpy" unless some "boy this is real fuckin weird" alarms were going off


You must log in to comment.

in reply to @lexyeevee's post:

I feel this so hard any time I've tried to start a project that wasn't a platformer, shooter, or puzzle game in any of the various game dev suites out there

God I feel this so often with Ren'py. I'm actually glad now it has a native text history feature because I dislike rollback for feeling immersion breaking to literally rewind the game state, but a few years back it felt like a lot of the Ren'py forums were insistent on "no you don't want to disable rollback that's rude".

And yeah never mind the help section being full of basic level questions. I actually got sick of one problem never being resolved that I reported it as an issue on github and it was finally fixed. x -x

Ironically enough, this is a large issue I had with unity.
For all people talk about being able to google how to do anything in that engine, 90% of the results are just stuff like "oh you want to make the enemy move towards the player? ez"
and then it's just
if player.x < enemy.x
{
​ ​ ​ enemy.x--;
}
else
{
​ ​ ​ enemy.x++;
}

Just really simple solutions that won't actually work unless your game is dead simple

oh yeah i'm familiar. stuff that's """not wrong""", but also so wrong that i don't know where to even begin explaining why

i briefly worked on someone else's unity game and i was like "just throwing physics at a body sucks, how can i improve this" and this is an unanswerable question apparently. ended up making it sick as hell imo but it did involve ferreting out APIs that no one on the entire internet ever talks about

it's vastly worse with godot unfortunately, especially since the engine has been through several major revisions now which tend to obsolete everything that has existed so far

For some reason I don't have as bad an issue with Godot. Not sure if that's from the fact that I'm fairly experienced with it by now, or bc I'm usually just reading the documention since there's not really a Godot beginner tutorial hell yet for me to get sucked into yet.

in reply to @lexyeevee's post:

mostly unrelated but this is the first time i've learned that renpy allows 'on evt1, evt2' syntax and that's REALLY funny because i independently added that syntax for my own uses in my mutant renpy-compatible script compiler

Renpy is one of those engines I appreciate the existence of from a distance. I’m not sure that the ways I’ve made VNs is any better by any means but at least I mostly understood what was happening.

i do value it for having a whole slew of stuff built in, like saving anywhere during conversation, going backwards, built-in conversation history, tts, extremely easy cross-platform deploy... all this stuff i would never want to get around to doing

oh absolutely, what it gives you out of the box is amazing and I'm glad so many people find it to be a tool they can vibe with (and sometimes even do incredibly ridiculous things with)

but so much of it just feels like Spooky Action at a Distance wrapped up in an overly-friendly DSL that makes my brain itch

oh also I wish it had a bit more control over its audio system (as someone who keeps on ending up writing soundtracks for VNs for whatever reason). I tried writing a better music engine for it and just got stymied by a lot of weirdness on the Python side of things, although to be fair I was also very new to Python at the time and didn't really know what I was doing.

Yeah this is basically my experience - I don't want to have to deal with building the basic parts of the engine (or a friend offering to, as one has in the past) just because I've complained about everything else Renpy does wigging me out sometimes.

... on audio though, wonder if it supports OGGs with loopstart metadata yet. (or how one'd implement that)

The main audio engine issues are both lack of looping, and lack of crossfading between tracks. It'd also be nice if it were possible to have multiple synchronized "mix" layers which is what I was trying to build myself.

"young programmers, heed my words: it is never a bug in the platform."

Weirdly this reminds me of why I absolutely, 100%, refuse to touch 'natural language' programming stuff.

Not because of elitist nonsense, they're less intimidating for people getting into programming and that's good. But they're entirely Not For Me because while my brain sometimes refuses to see which line lacks a semi-colon, or the difference between && and & when looking for why the compiler is yelling at me, when it finds it I can understand what the difference between the two are. Usually.

My brain is actually incapable of seeing the difference between grammatical construction in similar but different sentences. And this isn't a bug in the platform, at least as far as I can tell, this is always my brain not being able to distinguish between the grammar of the sentence I wrote that does what I want, and the sentence I wrote that doesn't when that grammar is similar enough to english to count as 'natural language programming' but not actually english because... Computers...

(I'm mostly thinking of Inform 7 here but when I was a student there was another natural language I needed for exactly one class that was absolutely miserable. Meanwhile, the language for that class I actually got on with - a language without any looping outside of recursion - no one else in the class could use.)