Others [RELEASED] "Help me, Brave Sir Knight!" - A Godot dev diary (previously just "sharing my great idea")

[papel]

There we go, nearly done. I still need to work somewhat on the iris. There's 3 different eyes and 4 different mouths, not shown below.



There's also a "back" face of the shield. I'll probably work on making the actual godot node tomorrow. Might also add a bell collar to her and some other little accessories.

On a completely unrelated note, drawing with polygons within godot is actually kinda fun. Too bad I can't add bones to a polygon without a texture. Also adding shadows is a fucking pain, each has to be a separate polygon, I can't (or don't know how to) simply cast shadows of a polygon some Z levels above over whatever happens to be below. This was for a game jam that I didn't finish in time, but might work after I'm done with BSK

 

[papel]

Alrighty, back to work. I possibly finally fixed the fucking jump for good, instead of using delta, I'm now using a Timer node on the player. Testing on my phone yielded good results.

A good chunk of the logic of the cow enemy is working properly, like her moving, stopping and raising the shield. She's still moving while the shield is up, instead of standing still, but that's probably gonna take less than 5 minutes to solve. Animating her is taking my sweet, sweet time, tho. Just found out that, when I invert her graphics so she's moving left, the whole animation breaks. Yay

Side note, hopefully nobody will look at these eyes and think that they're out of place. I did the trick with polygons there, I think it's a neat result

 

[osanaiko]

Welcome back, love to see your progress reports.

 

[papel]

Jesus, Godot's collisions sometimes will refuse to disable! The cow's shield has a static collision that the player can jump on top of without getting hurt. There are many situations where this gets disabled. FOR SOME FUCKING REASON, when the enemy faints, the collision would get disabled but would STILL block the player, EVEN THOUGH IT WAS DISABLED!! Even with debug showing the collision shapes gave it a white outline, which meant it was disabled, but behaved as if it wasn't!!!

The cherry on top? I tried using the "set_deferred" function, but it didn't work at all. Coming back to what I did before, simply setting the collision.disabled = true, magically started working as intended. WHAT THE FUCKING FUCK!?

Ugh, Godot really tries my patience sometimes. What's also testing my patience lately is my shit code. For a change, I went ahead and decided to decouple the logic from the animation (the orc and kobold both have lots of logic that relies on specific animations playing, which is a nice feature of godot). As for actual trouble, getting the sex code to work. Right now, the animation is only playing correctly if the cow dies (as a funny side note, said cow will also disappear/die during the sex), that is, she won't faint for the player to fuck as many times as he'd like. If the cow can faint, the wrong animation is being called. As I said, my own shitty code fucking me.

The lesson i'm taking from this is: learn to fucking define states. I change states (such as whether the enemy is idling, walking, hurt, fainted, being fucked) in several different locations, and that makes my guesswork of "why the fuck is this behaving like this" much harder. To make matters worse, I also have loads of flags that I check outside of the state. I should definitely refactor this piece of shit, but this will be the last enemy I'll add to the game, so there's that. The lesson is: write down, draw on a paper all the states the entity can be in, which states can lead to which, and which ones have priority over which; only have ONE piece of code/function to change states

Anyway, I'm also planning on leaving the cow as a non-moving enemy, only ever changing facing direction. I can't quite remember if that was my original plan or not, but I think it makes sense, shieldwall to mess the player a bit, or open up some shortcuts.

Expect some edits on this post later today, if I manage to fix my shit.

Edit1: Ok, the sex is working, the problem now seems to be Godot. See, the eyes are not a texture, they're polygons. If the cow gets hit, the eyes close and the polygons are set to "visible = false", so they don't show up. So far, so good. However, when the animation is the sex one, the polygons don't show up, even when they're VERY FUCKING CLEARLY SET AS VISIBLE in the fucking debug.

Seriously, there's ONE function that toggles the iris visibility. It gets properly called, it sets the visibility to true, YET THE FUCKING POLYGONS DON'T SHOW UP. It's not a Z-index problem either, it's like the damn polygons don't even exist. It's shit like this that really makes me want to give up using Godot.

With visibility fucked, I tried using Color modulation, setting the alpha to 0 when hiding and 1 to show. Even then the fucking iris/polygon disappears. This ONLY happens in the sex animation and I have double checked it, there are NO keyframes for any of the eye polygons, or even the eye sprite for that matter. The fucking thing is literally disappearing for no fucking reason on this specific animation only.

The immediate fix is freezing the cow's eyes in the closed frame, but seriously, what the fuck
Turns out the problem was, in fact, the fucking Z-order. The iris were NOT set to be relative to the parent's Z, so when sex starts and the Z index gets shuffled around, they were getting stuck under 6 or so layers. Remember to check if the shit that's disappearing is using relative Z ordering so you don't bash your head against the keybaord for 30 minutes like an idiot.

Edit2:
Cow cheeks coming in hot! I'll probably finish by tomorrow


Edit3:
I just discovered that I don't need textures/sprite nodes to act as masks, I could have used polygons all this time. This means maybe 500kb of saved space and some 2 or 3mb of VRAM saved when running the big sex scenes. Not a big deal, but something that activates my neurons.

 

[papel]

Speaking of video RAM, I went back and fiddled with one of the big kobold sex scenes, cropping the many 800x800 (2.44MiB each) images down to what they actually have of drawn area. VRAM usage went from ~35MB to ~6MB. Considering these big sex scenes more or less remain in memory at all times (the scene window loads all big sex scenes), and considering that I still need to work on the other kobold scene (currently using ~78MB), we're looking at around 80MB of VRAM being saved just from cropping images. For my game, that should give a performance boost on lower end hardware.

I also experimented with a 256 color PNG instead of a RGBA8, but Godot imports it as RGBA8 anyway, so there's no further performance gains there, unless TGA somehow uses less memory? I don't think so, but I'm not willing to take 10 minutes to find out.

The big animation for the cow is mostly done, still need to adjust some details, like keying the ass and leg movement, adding sound and the cumshots

 

[papel]

Animations are finally done, though I'm wondering whether to add a short tail to the cow or not, as she currently has none.

Next step is making them turn around in place after a given time (3-5s), which should be easy, and adding some cows to the levels.

Fuck me and my terrible level design, btw. I better steal get inspiration from better games. The good part is that, since the player can jump on top of the shield and not get hurt means I can make some better shortcuts

 

[papel]

Wow, nearly a year of inactivity. Anyway, time to get back to work, as I am once again struck with lack of laziness great ideas. This stuff will take at least 2 weeks of work to be done, and that's assuming I sit my ass down to really get it through, so it's possible R7 might show up before october's over, but I make no promises:

• Make the different princess reward animations for completing a level. I might end up completely discarding the existing cowgirl and maybe even the in-game model. The idea is that, if the player fucks more than 3 monster girls during the stage, the princess will refuse to reward you, you sick rapist pig (lol), otherwise it might go from handjob - anal - vaginal with creampie - only a true sir knight is deserving to sire a prince!
• Since I didn't make a milimeter of progress with tilesets as being "reusable" - white original color to change around with Godot's color wheel - I'll look into proper scenarios first, make the parallax background, then think how to tile them. Level design might still suck, I'm afraid.
• Check if using polygons instead of light/shadow masks on top of textures looks "good enough". Something I tested with an unfinished game jam was making characters entirely out of Godot Polygons. Since Godot lacks curves for those, they'll look very angular
• Add flags to enemies' code in order to make sex screens unlockable in the gallery
• Right now, enemies have set flags of whether they'll die or faint to be raped. I might add a bit of randomness to this.
• Check if the big sex scene window thingy is properly destroyed once the player is finished, I suspect it's an "always on, but hidden" thing that might have an impact on performance
• Maybe a boss? The idea I had all the way back in the OP was to have a boss every 2 levels. Right now, having one after finishing level 4 might suffice. The gist of it is: you hit the boss until she gets dizzy, then you use the GRAB command to choke and slap her face until she cums (or just hit her some more while she's down, for those too squeamish about going hard on a masochistic monster girl) - She will recover after some time, so it probably won't be possible to defeat her in a single choking. Still thinking what kind of monster girl to make her
• Make a silly end game portrait based on the most common rank attained by the player

If I manage to pull it all, I'll consider the game finished and move on.

I'm aware that performance is all over the place with android versions, and web version is unlikely to ever run at a steady 60fps even on computers (mine doesn't manage). Trying to figure what are the performance bottlenecks is a hard job and not something I'm really willing to do, although the majority of players are on android, so I really should consider that. I still suspect the main problem is that my images are too big and the more enemies there are on a stage, even if they're being ignored by the main process for being out of the field of view, the slower I suspect the game gets.

Anyway, hope to see you all soon.

 

[papel]

Managed to get some progress done today, before a blue screen of death got me off the computer to do chores and other stuff:
* Created the flags for unlocking each of the 4 monstersex scenes
* Created a cool wavy text that shows on screen when you first unlock a new sex scene - RichTextLabel is a great node type!
* The monster girls will only show in the Gallery once you've unlocked each scene
* Added a button in the Credits to unlock everything
* Figured out that large ColorRect nodes can be used as click blockers - this eliminates the problem of being able to click on a menu that's behind a window that should be your focus (for anyone wondering, if your menu window is a separate scene, make sure it has one ColorRect as the first child node and set its size to cover the entire screen, or at least most of it.)
* Several player stats are now properly tracked and saved to stats.cfg
* Added a new Player Stats window where you can see said stats. You can also reset it.


Answering my own point 3 above, yes, polygons can be used as shadows and highlights on top of normal images, as I was already doing so with some of the cow monster's details, like her horn color and eye irises. Turns out I forgot that.
The big sex scene is indeed an "always on", though I haven't checked how big of a performance impact it causes

As I upgraded to Godot 4.5, one thing that happened is that kobold archers no longer are playing the "gethit" animation, which makes them look weird on death.

God there's so much code in here that makes me question my sanity back then and right now.

 

[papel]

Did what will probably end up being the new pieces of the princess for the sex scene. My hands always end up the wrong size and with weird fingers, good thing i can scale them up in Godot. Still need the breasts, but this should be enough to create a handjob animation and one leaning forward, which will probably be used for anal. Doing both front and back 3/4s should allow me to make a variety of animations by just moving the pieces around.

I'll also need to make the back of some hairs, or zoom in on the body on back-using-poses to always hide the back of the head

 

[papel]

Added the lines to the game and made 2 "preview" animations, handjob and missionary with the front parts

-

Back parts are also in position. All of them are using polygons as the colors, which are properly set via script


Separate from this, I caught a bug (that I must've recently added by accident) that made sex sounds continue even after the sex scene was no longer playing. For the back facing, I'm thinking about both a cowgirl position and a standing anal. Maybe even a standing hotdogging

Of course, besides finishing the animations and adding the cumshots, I still need to make her breasts, pussy and asshole.

 

[papel]

Today was more of an "eureka" moment for me rather than actual progress. I finally figured out how to create polygons that can be deformed with bones, not unlike how bone animation works in 3D (possibly it's the same logic in godot, but removing one dimension).
So, the step by step is the following:
- Create a Polygon2D node;
- On the lower part of the editor, where Output and Debugger are, click Polygon;
- Go to "Polygons" tab of the subwindow;
- Create the polygons that will be edited/deformed. They have to be triangles at least, but you can make any n-gon
- Create the Skeleton2D and bones
- On the upper part of the screen, just below the 2D, 3D, click "Skeleton2D" and "Overwrite rest pose"
- Back to the Polygon2D, on the right side, there's a Skeleton property. Point it to the created skeleton
- On the lower subwindow, click Bones tab, then, on the right part of it, "Sync Bones to Polygon" - this will make the polygon disappear
- Paint the weights of each vertex according to the bones. The default weight is 0.5
- ???
- PROFIT!!!!!!!!

While I won't be using this on BSK, I will use it on my next project, whatever it happens to be - I mean, I still want to ditch game engines altogether and use "bare metal" SDL, but if I want to actually deliver anything with skeleton animations, I'll have to stick with Godot.

Anyway, for actual progress:
- princess' tits have been drawn and animated into the handjob and missionary positions.
- partial shading has been added to the princess' body (polygon2d around the color nodes)
- drew a bunch of mouths + 4 eyes with a closed variant for the princess. I will probably make the iris a polygon2D so I can freely move it around the globes (might need masking to not make it go past the limit)

- large player body has been drawn. Hands and feet look like shit, but hopefully they won't draw too much attention

 

[papel]

Added the eyes to the princess and also made them animated, with blinking and light iris movement, working with all 4 eye variants.
Added mouths to the face + a timer to make it cycle through the appropriate ones - the princess won't use the open wide mouth or the grit teeth when giving a handjob, for instance. Both eye and mouth have functions to easily manipulate their respective colors

* Side note - The amount of "for i in array" I'm using here is kinda worrying to me, but since they aren't called that often and only go through a small amount of objects, it's probably having a negligible effect on performance. I'll have to check how to play around with threads in the future, but I doubt BSK will implement the code for that, especially as the Godot docs mention that "creating threads at runtime is expensive".

At first I thought about reusing the existing princess' hair and nose as is, but given their relatively large resolution, they'd eat up a lot of VRAM. So, I made copies and shrank them down, the noses being 40% of their original sizes and allowing me to use an AnimatedSprite2D node - at ~15kib of vram each frame/unique nose, compared to ~93kib from their originals.

I tried that with hairs, but I came across two problems. One, the shape of the princess' head changed somewhat compared to the small version. Two, I have to make new back versions for the back-facing princess. In any case, hairs that are ~220x220px will work fine and will use ~200kib of VRAM instead of almost 3MiB. So, since I'll have to make new assets for that, I moved on and added the knight's body to the scene. The upside is that the knight will be easy to copy-paste to the back-facing princess' scene/animations

Anyway, I have enough to make the front facing animations, so I'll probably try to focus on that first tomorrow and maybe get at least 2 hairs done. Since I've been just doing the lineart, that shouldn't take long. Maybe I should just fill them white anyway, won't make a difference in VRAM and the storage difference will be insignificant.



* Side note 2 - I originally set up the knight's torso parts in the wrong order for node parenting purposes. Fixing that was annoying, since a lot of code referenced the parts, so they immediately stopped working. I wish there was something for Godot to autoupdate references to nodes.

 

[papel]

More work done on the animations. I managed to fix the eye movement so that it never goes too much up or down, nor that left-right irises end up going in different directions, something that I had to deal with yesterday a number of times.
I also managed to make a kinda shitty looking titfuck animation, but it should suffice for the moment.

Another problem with animating is that I forgot to set up the origin of the textures, as in, the point at which the rotation uses as the center. For legs this is a problem, as the "real rotation" should happen at the top, where it's connected to the hip, not the center of the image.

I also added a small "change" button to the scene for debug purposes, namely to check whether the animations will play nicely once they're added to the gallery, seems to be fine so far. I still need to add editing options to change nose, eyes and eye color

 

[papel]

* Made 4 different speech bubbles that can show up while the player is fucking a monster girl. Since they'll be shared, I made it as a Global function, which creates a new node within the one that calls it. The bubble destroys itself after 5 seconds, so there's no risk of it stacking or eating up extra resources.
- I did try to make a single bubble that would expand horizontally according to the text, but it wasn't working out too well, so I had to settle with 4 static bubbles and their respective texts.
* Sketched the ending screens. Gonna make them brown-on-yellow parchment like, just so I can get away with doing lineart only. Not gonna say what is what, but I think they'll look kinda funny in the end. Still need to come up with 2.

- I will need to update the last level's "endstage" code so that it goes to a proper end game screen. Probably just a new scene that fades in from black, shows the image according to rank, show up the stats of the run, slide up some text and call it a day. This shouldn't be too hard to do, just "a lot" of stuff to put in place.

EDIT: Got the gallery working with the new princess animations, buttons correctly change the animation and if the player gets far from the thingy, the node is destroyed, freeing memory and resources. Since i'm using a copy of the "endstage" node (in case i ended up FUBAR, which didn't happen), I'll soon work it into the existing stages as well to be sure it's working with the ranks.
Speaking of ranks, the buttons in the gallery will only show if they're unlocked (or if you unlock everything in the credits)
Doing this kind of progress is addicting, I'll be off to sleep now but fuck me, I want to keep on coding!

 

[papel]

Added princess customization buttons to the gallery. These also scale up for players on android, since the screen might otherwise make the buttons too small

Kinda funny how the small details sometimes give the biggest satisfaction, even though they are the things that are most likely to be ignored by players.

Probably won't do much tomorrow either, the above was more or less 2h of work, all in all.

 

[papel]

Alright, fixed the endstage to show different animations depending on the rank you got. Right now, only 3 animations are available - handjob, titfuck and missionary, with a player that rapes too many monster girls getting none of them. Gonna make some fun lineart for these "bad" and "evil" ranks

So, 9 endings + 3 evil "no-rewards" + 2 "no-rewards" linearts to be done. This is gonna take a while, even if I just do shitty scrawls.
EDIT: Left it at 3 different no-reward scenes, already properly implemented.

 

[papel]

Started work on the end game screen, the code is more or less ready, as is the text. Neat looking fade-in with text appearing on the right, which varies according to which rank the player got the most - in case of a draw, like 1-1-1 of each rank, the lower rank will win out.

So far, drew the end scene for the 3 lowest ranks, the brute is easily my favorite with how silly it looks

 

[papel]

Drew the 3 best ends, I love how they came out. Silly but nice looking. Now to draw the 3 mid ends, I'll probably manage that before friday rolls around. With that, the game should be ready for Release 7.

* Added a working case in the gallery for when the player hasn't unlocked anything with the princess yet. For some reason, the graphic was offset by 110px to the right. This didn't happen anywhere else, so I'm really confused.
* Added the speech bubble (talkbox in my scenes/nodes) to the kobold and cowgirl, forgot that! Also made it work on a timer and have a random chance not to spawn,
* Changed the old "endstage" nodes in the 4 stages, so the new princess reward should work now.
* Fixed my logic for calculating which rank the player had the most of. I wasn't actually doing the proper substitution of the "highest" variable, it took me a humiliating 10 minutes to figure something so fucking basic (no, seriously, this kind of mistake is "learn to program the first time" level).
* Added buttons in the gallery to see the different ending screens, also made them unlockable (still haven't made the code to make them work, will do that tomorrow)

As a side note, I've made a txt changelog that'll be zipped with the game, might also add a button to read it in-game. Kinda funny that the changelog I've written thus far for R7 is kinda tiny despite the work I've done in the new additions.

 

[papel]

Well, I hit a metaphorical wall with the Ending screen. For some reason, loading it from a previous scene makes it run slow as fuck, like, "holy shit what the fuck is going on" slow - taking 20 seconds to do something that, when the scene is loaded straight from the editor, it takes only 5

I tried to replicate a similar, but smaller situation in a new project, but the problem didn't happen there. Well, fuck me. From a glance, it seems that my many "if"s are taking a LOT of time to process, even if the debugger profilers don't show significant difference. After closer inspection on why the node was running so well by itself, I found it: running it alone put it at 500FPS. When called from anywhere else, it was locked at 60, the game's set FPS limit. So, yeah, shitty code on my part and a reminder that I should stop doing animations on the _process function if I can't guarantee a stable FPS.

I gave a look at tweens, but it ended up being better to use good ol' animation player instead. With this, the gallery can now be used to see any unlocked endings - managing a superior rank automatically unlocks lower ranks of the same good/neutral/evil side

Did a couple more fixes in the code, where stage4 would immediately crash on loading, also where it would crash instead of loading the ending screen.

Now I only need to add the end game images, plus finish drawing the 3 mid-rank ones.

EDIT: Only 1 end screen left to do.

 

[pitinar277]

I tried to replicate a similar, but smaller situation in a new project, but the problem didn't happen there. Well, fuck me. From a glance, it seems that my many "if"s are taking a LOT of time to process, even if the debugger profilers don't show significant difference. After closer inspection on why the node was running so well by itself, I found it: running it alone put it at 500FPS. When called from anywhere else, it was locked at 60, the game's set FPS limit. So, yeah, shitty code on my part and a reminder that I should stop doing animations on the _process function if I can't guarantee a stable FPS.

Hmm, have you tried creating a timer that randomizes itself every time it ends, so the "if" checks won't be called at the same frame every time? I did that for a "fire damage" timer in my godot game, and it helped not only the performance, but also made competing sounds not play at the same time. Not sure, but maybe it could help you


Like this: timer node's timeout signal randomizes its time, you can make it as random as you want that way, works for any timer that won't need to be 100% precise.