Rogue-Like Update 03/05/2019 (Patreon)

Hey guys, coming into the home stretch here. I've got almost all the art done for the next build, and almost all the coding I intend to do, all that's left is the handjob and blowjob animations, which hopefully won't take forever to work out. That leads into the topic of today's post, Renpy's ATL animation system.

I kind of hate this system. It's a real pain in the ass to work with. You can't really see the results of what you're doing without reloading the game, so a lot of the process is trial and error of "did this number change alter the animation how I wanted? Reload, wait ten seconds or so, see. . . no, ok, how about this change? . . over and over. :D

I'll start with the easy stuff though. "anchor (x,y)" defines where the "hook" for the image is. This defaults to the top left corner of an image, and all movement of the image is relative to this point. This means that by default, if you just drop an object into the world, its top left corner will be at the top left of the stage. You can move this anchor point, either by using pixel numbers, "anchor (120,160)", or decimals to place it relative to the image, so "anchor (.5,.3)" will place the  anchor halfway across and 1/3 of the way down the image. One good use for moving the anchor is that you can set the anchor on an image slightly above the bottom of it, and then whenever you place the image along the bottom of the stage, it will automatically leave that margin off the bottom.

"pos (x,y), xpos #, and ypos #" are used to move the image around, relative to that anchor point. Like with anchor, you can use pixel placement, or relative placement, depending on the result you're trying to achieve. I almost always use pixel values for animations. One thing to keep in mind is that if you're using pos to define where an image is on the stage, then the pos values will be relative to the top left of the stage, so pos (300,500) will be 300 right and 500 down from the top. This can get a little confusing in that raising the y value makes the object move down the screen.

It's also important to consider that when you layer images, like I often do in my animations, the pos values you use may instead be relative to their position within the new image, rather than relative to the stage. For example, if the main image you're laying down is at location (500,500) relative to the stage, and then an image contained inside that larger image (which we'll get into later) has a pos value of (100,100), then that value will be relative to the anchor point of the larger image, not relative to the stage. That means that it will end up at the position  (100,100) pixels away from the anchor of the image, or (600,600) relative to the stage.

"align" can be useful for simple things, like UI, but is a bad fit for actual animation. What it does is combine both anchor and pos, which is good for centering things, for, say, locking a UI element to a particular place on the stage, but I find that any time you aren't centering something, the results are too unpredictable. Better to just fix an anchor and then use pos to move around it.

"offset (x,y), xoffset #, and yoffset #" can be a bit tricky as well. Like pos, they move the image around, but they actually move the image relative to its own anchor point. basically if you do xoffset 50, and its anchor point is (.5,.5), then it will move the image 50 pixels to the right. Functionally, this doesn't mean much more than pos, but in practice you can do some tricks with it. For example, this allows you to choose to establish either pos or offset as a fixed state, and then use the other one to move around that point. In some image layering techniques, the pos or offset values might end up "locked" to a higher layer of the image, so that even if you try to change the smaller part's pos values, it refuses to move. In these cases, adjusting the offset instead can allow it to move. It's basically like having two different options to achieve similar results, so it's important to keep them both in mind.

Those are just some basic elements, and I'll get into some more stuff in the next update. The actual game release should also come relatively soon, maybe next week, or even late in this one if testing runs smoothly.

Oh, and if you were wondering about that post last week, it was just a preview of some of the art from the next build, I wanted to get a little feedback on it and also send a little extra reward toward the $3+ patrons, which I really don't do as much as I should. If you haven't seen it, don't worry, you'll get it in the game soon enough.