Godot Gamedev Diaries

It's been a while since I've posted here. Guess I really like to abandon online places more often than I'd like, but whatever.

So, if you've read any of my previous posts, you might be aware that, for some graphical parts in my game, Brave Sir Knight, I've used polygons instead of saved images like a PNG, which got many ideas brewing in my head. Now, I'm finally giving them proper shape.

I'll be using Godot again, but this time, all the graphics will be done with Polygon2D nodes, meaning that graphics can be "hidden" as code or text files (actually, it'll be CSV for easier reading). That's not the point, the real bangers are:

* A lot less disk space is needed
* Less RAM usage overall
* Easy to create a variety of shapes that fit
* Lossless zoom in/out

Of course, applying math to god knows how many different points and lines can be taxing on a CPU, so I ran a few tests, creating a bunch of polygons with 70 points, then moving 25 points of each of them per frame. The results, on my i7-7700 were satisfactory: moving roughly 260 points per frame resulted in roughly 10% increased CPU usage, from ~11% to 19%, without any effect on delta (how long the CPU was taking to finish a cycle, which was at ~8.3ms, which translates to ~120FPS). To be sure, I exported the project for web target and made a prototype page on my itch.io - currently accessible only to me - and there, too, CPU usage remained decent without any impact in delta/FPS while the points moved across the screen.

One thing that might not be clear is this point movement, so let me explain: every 2D polygon has a number of points that are connected by lines. By moving a point, every line connecting it to other points immediately updates to show the new result, think of it like having a yarn string over some sticks, if you move only one stick, the overall shape changes. So, by being able to move each single point separately, I can define positions that I would otherwise have to draw by hand and keep as separate image files: instead of having 1 image for front facing and 1 image for 3/4, by moving the points to new positions, the same polygon can act as both directions. This also eliminates load times, as these values will likely be within memory or calculated during runtime. Setting up all the correct positions will be a lot of work, but I expect it to be worth it.

The basic functions I've made can either set the points to certain positions, or move them by a provided delta. What really annoys me in this case is how Godot does not allow direct manipulation of values, instead forcing people to create a duplicate of the polygon, changing that, then applying it back to the original one. It's essentially the following:

Very annoying, but they claim that this kind of PackagedArray is more performant than normal Arrays. I guess I'll find out during this development.

I uploaded Release7 today to great self fanfarre, only to realize 2 minutes afterward that the game was buggy. Worse, the bugs only showed up in the release/exported game. I spent the next hour or so endlessly cursing the engine for causing shit out of fucking nowhere and trying to understand what the fuck was going on. There was only one case that it was my fault, as the "Next stage" button was indeed improperly set up, and thus finishing a stage would just crash the game. Everything else wasn't me.

As I explained on my post on itch:

I am currently unable to replicate this problem with a dummy project, so I have no idea what the hell actually happened. One of the biggest headscratchers for me is that it wasn't every signal-connected function that got fucked.

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:

1.  Create a Polygon2D node;
2.  On the lower part of the editor, where Output and Debugger are, click Polygon;
3.  Go to "Polygons" tab of the subwindow;
4.  Create the polygons that will be edited/deformed. They have to be triangles at least, but you can make any n-gon
5.  Create the Skeleton2D and bones
6.  On the upper part of the screen, just below the 2D, 3D, click "Skeleton2D" and "Overwrite rest pose"
7.  Back to the Polygon2D, on the right side, there's a Skeleton property. Point it to the created skeleton
8.  On the lower subwindow, click Bones tab, then, on the right part of it, "Sync Bones to Polygon" - this will make the polygon disappear
9.  Paint the weights of each vertex according to the bones. The default weight is 0.5
10.  ???
11.  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 done today:

• 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

https://parallelpapel.itch.io/bravesirknight/devlog/764274/release-5-is-out-stage-redesigns-no-new-adult-content

Some much needed level redesign was done for R5. I was initially torn between releasing it or holding it back until I could add more adult content. In the end, I opted to release it, as getting feedback on the level design would be useful.

My to-do list right now:
* New shield enemy, that is invincible from the front - possibly bear or cow
* New ranged enemy that throws a chakram or something that flies in a C curve - possibly feline
* Make a decent main menu screen
* Make proper graphics for the control scheme on the main menu
* Make better looking tilesets (note to self, tiles have to be 50x50 in size)
* Make better looking level backgrounds
* Find one new music to use for stage 3

Forgot to post here that Release 4 is available for download and browser play from itch.io. There's also an APK for Android devices!

The first upload had a visual bug that I completely missed, so I fixed that and reuploaded as R4a. Thus far, no other bugs have been pointed out, which makes me happy! On the other hand, a number of QoL have been asked for, mainly on F95, which is very understandable, though I may not put the effort into all of them, as I want to finish the game, not keep it around as a forever project. There's a lot I learned with it, so, once I move on, I can do something better.

Copying from my F95 post. Right now, imgbb isn't loading for me, nor is postimage.cc or even postimage.org, so no image uploads.
------------
So, having some trouble with my orc animation right now because of my own code working against me.

The problem: checking which sex scene to play happens both in the player AND the enemy's scripts. This is terrible because instead of having only one place to look at in order to fix, I have to keep checking two. How is this biting me in the ass? In the form of me not creating a "sex_on4s" for the orc gal. Since that part is written in the player script, I either work on a fix there, or create a proper "sex_on4s" animation for the orc, or create a dummy to stop some of the errors.

As if that wasn't enough, I also have to contend with this shit:


Yes, the face, hair and breasts are on the wrong side. Why? Because fuck if I know, Godot apparently hates working with bones. Keep in mind, this kind of error happens all the time with the orc gal in the editor, though a simple advance on any animation fixes everything's positions.


That's from the editor. Why in the fucking fuck that happens? Turns out it's because I'm being "lazy": the textures for the hair, chin, ear and face are all separate nodes, child nodes of the head shape. This means that, in theory, dealing with the parent node alone should replicate every position and rotation to its children.

This, however, becomes a problem because I'm not doing that straight on the textures, I'm doing that through a "RemoteTransform" node.
I'm not using these RemoteTransforms on the kobold enemy, but I'm using on the player and the princess, and the player's head textures can very easily "glitch" [URL='https://f95zone.to/threads/released-help-me-brave-sir-knight-a-godot-dev-diary-previously-just-sharing-my-great-idea.171385/post-11784188']if you move left-right fast[/URL], the head takes 1 extra frame to get in place with the rest of the body.
- Now that I actually know the fucking cause, I also understand why this is happening: Godot draws stuff on screen going from the bottom of each scene upwards. Child nodes are always drawn before the parent nodes. Due to the RemoteTransform, ONLY the parent node will be affected, a change that won't travel down until the next frame. Why, however, it's not properly updating while fucking the orc gal as shown way above, I still don't know.
- See, remote transforms were supposed to help in order to properly align the draw order of textures: you put the remote as a child of the bone, then just point to the actual texture, which will ideally be ordered elsewhere, so that it's easier to rearrange what piece goes on top of what, like breasts show on top of the torso, boots show on top of the shins, etc. But Godot's entire draw order is one of the most infuriating aspects of the engine. As I said above, it draws in a reverse vertical order, whatever's at the bottom of the scene's node list is drawn first and on top of other stuff.

Another annoying bug that popped up is that after fucking the orc, she'll remain stuck to the player.

On the bright side, she's properly attacking, being hit and disappearing if she dies instead of fainting.

As posted on the game's itch.io page:

Due to my actual full time job, I haven't had time to do much, especially after the hard drive failure some weeks ago (which erased my drawing progress on the new enemy, orc gal).

So, when will the next update drop? Fuck if I know. Right now, I have to finish revising and correcting a contract before the end of the year, so the real limit is december 15, give or take. That, by itself, wouldn't really bother me, deadlines are part of the drill. What isn't part of the drill is regulators asking my boss (and me, indirectly) "why are you delaying this process?" - To be fair, my boss is doing what he can to get us extra time.

Fun times...

Anyway, here's to hoping this shit moves forward ASAP, as I'd like to get home from work and just feel light and carefree.