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

[papel]

Edit October 6 - First release now available at

You must be registered to see the links

Also the thread here on F95 - https://f95zone.to/threads/help-me-brave-sir-knight-r1-papel.177314/
-----
So, here's my current ORIGINAL IDEA DONUT STAEL (not really, feel free to steal the idea and work on it if you think you can pull it off)

SAVE ME, BRAVE SIR KNIGHT!

A platformer game where you'll control Brave Sir Knight. Movement will be standard platformer with simple melee combat. Run, jump, one attack. No dashing, sliding or double jumps.
Stage based, no backtracking.

The "magic" differences:
1- You recover health by rescuing (or not) bound ladies and fucking them. Doing this will open a window showing the fucking scene in higher quality
2- You have to either escort or carry the stage princess around. Enemies will attempt to grab her back
3- You get to fuck the princess after saving her (stage end)

Non essential features (ideas that I found fun, but might not end up programming into the game):
- Stages as 2 parts: getting in, fighting a boss, getting out with the princess
- Minigame where you spank, choke and slap the bosses (all will be girls)
- Have a different end stage fuck, depending on how many other girls you rescued (good knight or bad knight)
- Customize your Brave Sir Knight (helmet, armor, skin color, the latter to alter sex scenes)
- "Family friendly" mode (if the game actually feels fun to play and people feel like showing it off YT or Twitch or whatever, this would be useful. Of course, this'd be the last thing to be done)

Undefined (things that are much more likely to change)
- Male enemies who'll attempt to rape the princess? Or female enemies that will try to get BSK horny, thus making sense of fucking girls recovering health? Or futanari enemies who do both things? - I personally dislike sex being a reward for losing. Still, using the princess as bait for the enemies could be an interesting feature.
- Have a horny meter for the princess? Would fit with the above and it'd be up to BSK to cool her down (masturbation or rape)
- Art style (flash-like vectors and bones, big images or pixel art). Chibi vector art might work, think Paper Mario
- boss minigame as the means to defeat them? or reward after defeating them?
- Give a buff if BSK fucks/rescues a girl while at full health?
- Make it easy to speedrun?
- Procedural stages, or hand crafted?

Controls
Run sideways, jump,
Melee attack (can't use while carrying a princess)
Block (shield) (can't use while carrying a princess)
Carry/release princess


Gonna work with Godot to try and make this piece. Might leave the source code open, minus assets, depending on how good I feel about it.
What I would consider a bare minimum before releasing a demo would be: Controls fully working; carry/drop princess working; have her attempt to follow you up to a certain point; 2 enemies, one that goes straight for the player, another that goes for the princess

 

[papel]

Surprisingly, I've managed to get somewhere already! At least regarding gameplay, I have the barebones working. Here's a list of current "features":
- One enemy type (swooping bat), an attack hitbox; short invul time after being hit, player dies and forces the pause menu to open, can grab and carry the princess, changes in speed and jump height while carrying the princess, can "throw" the princess with your own momentum, an exit point which only works if you touch it while carrying the princess; pause menu and graphics options; a "game over" screen that lets you retry the stage or go back to the main menu

Stuff that is still blatantly missing:
- Animations beyond walking; any semblance of hentai

Regarding art, doing actual Flash like stuff, using vectors, is not really possible with Godot. Apparently, redrawing bezier lines every frame is super intensive on the CPU or GPU. However, using bone animation with polygons should result in a similar effect, though without the "perfect" zoomed in quality. It doesn't matter what kind of art I go for, it will be one of the more time consuming parts of the project.

I've also experimented exporting the project as is, the executable is around 65MB (current graphics + script resources total 230kb outside the executable) and uses ~75MB of RAM, a fair amount of CPU and GPU (16% on both my Intel i7 7th gen and nvidia 1070). A note on the GPU usage, that percentage is 3D processing, not RAM. Actual GRAM usage seems to hover around 200MB, so I would guess that on computers without a dedicated GPU, the total RAM usage could spike to around 350MB. Not ideal, but leagues better than what Unity or Unreal would build, I suppose.

Exporting as web generates a smaller, 28MB .wasm webassembly code. I couldn't be bothered to start a local server or something, so I dunno about its resource usage. Linux generated a similar 65MB executable, so I expect it to run just like the windows version.

I also have an older laptop (2012 asus s46c) around which I'll use as a benchmark once in a while, I expect the game to run just fine on it. It did annoy me that there was no option to export the game without packing the resources in a .pck file, as it won't open by default with 7zip. There's no default option to leave resources "exposed", but at least I can opt to not encrypt it.

So, my next steps, more or less by order of importance:

• Add a knockback on being hit Done shortly after posting (edit2).
• Drop the princess if hit while carrying her Done shortly after posting (edit2).
• Princess having her own health and being hit by enemies Done shortly after posting. Causes game over screen if she dies
• New enemy type - something that shoots a projectile if the player is within range
• Add a UI to show player health
• Zoom in-out Done shortly after posting
• Option to rebind controls
• Fix a slight delay that happens on the princess' position when you're carrying her (apparently fixed, second edit)

I might come back to my other project sometime. Here's to hoping I do so after finishing this one. As this one is considerably simpler (not needing a save/reload makes it waaaaaay easier already), I hope to get something out this year yet.

 

[papel]

A bit more progress. Managed to make an archer enemy, the projectile hits the player or the princess and disappears. Also disappears if it hits a wall or any blocking terrain. Shouldn't be too hard to come up with a new enemy that throws rocks or bombs instead
Also managed to come up with a simple, reusable enemy spawner, which I can set up to spawn any future type of enemy. Still nothing on UI or key rebind thus far
Enemy processing stops if they're outside view. This also affects them if you zoom in. Kinda silly, but hey, gonna leave it there, because why not?

As far as MVP (minimum viable product) goes, I have "everything" needed to finish a game, minus art assets, music and sounds. Systems that need to work are working.I could take what I have, create something like 3 stages and call it a demo, or game jam-sized game. For an eroge, it has nothing yet.

Short video showing stuff working -

You must be registered to see the links

(~10MB)​

So, these are my next steps (we'll see if I can keep a nice track and finish 4 today yet):
- Create the whole node-thing to open windows to show H-scenes - Sorta done? I have a rectangle that occupies the right half of the screen, just gotta show something there.
- Create a few traps (floor and ceiling spikes, wall spears) ED2 - Done
- Moving platforms
- Make the player attack hit the princess (option that can be disabled) ED1 - Done. Can toggle at the main menu options, or pause menu option.
- Add a situation where using the Grab button while behind an enemy will instakill (rape) them ED1 - Most of the logic is working. Player and enemy stop moving while scening. Player won't be hit while in this state. What's really left is the animation, which depends on item 1
- For some enemies, when they're defeated, don't remove it from the game yet. Allow the player to approach from one of 3 positions to rape it (oral, vaginal, anal) - this will recover 1 health ED2 - Partially done. Can beat some enemies to make them go down, you can still interact as if catching from behind.

Some explanation on why I've came up with the player raping the unaware or defeated enemies: my desired art style and stages are more or less well defined in my head. A good portion of the enemies being monstergirls will work perfectly with the rest of the game's offer. It'll also allow me to put a silly "Your resistance only makes my penis harder!" speech bubble on the knight once in a while if I ever feel like it.
That (raping monstergirl enemies) does come with a problem, however. And that is content to be drawn. Obviously, I'd much rather have it animated, but placeholders will have to do for now. Besides, as I wrote above, that'd be at least 3 poses for each general enemy type, which I only plan on changing with level style. For instance, one stage with kobold gals and either a cave or mayan temple aesthetic, another with catgirls in an egyptian temple stage. I can probably work the animation with bones and change the texture loaded, which will allow me to make better reuse of art assets. Probably.

TLDR - Everything involving art and animation, even of actual game, will require a lot of time.

EDIT 1 - Did two things, but am slowly worrying that I might need to do a LOT of refactoring in the form of state machines. Currently, I use a dozen different flags (boolean). No idea how it would compare performance wise. Hopefully, there aren't many new states I'll end up adding from here on out. Then again, I'm really fucking aware of feature creep...

 

[hu lover]

Good thread. Looking forward to seeing this develop further.

 

[papel]

Spent a good portion of today doing something pretty much useless, fiddling with allowing the player to change color of certain UI elements. Well, something good came out of it, at least, the player is now able to change the border and general color of the options window and the h-scene window.

I did also work some more on the matter of raping enemies, spawners can now spawn enemies that can be raped, and spawned-raped enemies will despawn if they get out of the screen, so new enemies will spawn. I've also spent some time thinking about how "easy" it is to get behind an enemy and instakill or instarape them. And you know what? That's fucking fine, I'm not making Dark Souls, I can add challenge as level design itself, enemies don't need to be a separate challenge themselves.

Speaking of h-scene, I've begun working on some art assets. Default sir knight without helmet and a kobold gal. Nearly everything is a separate layer: head shape, hair, eyes, nose, mouth, torso, left-right arms (both)// tail, upper leg, lower leg (kobold) -- For the leg, I suppose repeating the same leg with some offset will work fine. Hopefully.

Anyway, I still need to add color, was thinking about making it white, which would allow me to use Godot's modulation/self modulation parameters to change the actual colors. Should work well with the kobold, at least, and future monster girls that I end up making. The images are quite big, too, roughly 3x of the attached .png, which should give some reason for a player to zoom in while playing

Not only do I have to make the assets, I also have to watch some tutorials into how to import it and create skeletons and animations, stuff that will take considerable time, which I vaguely recall looking into on my other project, but much like everything else, I've completely forgot how to even begin. I might take a while to write about any new updates.

EDIT1 - Made the princess, too, with one variant for the nose and the mouth and my hand drawing skills are just a pinch above AI, at least I don't get the number of fingers wrong. Also, brave sir knight can be the dashing young hero of the first thumb, or manly knight from the second! Also made a beard on a different layer. Making a digitigrade leg (for the kobold) ain't working too well, but eh, fuck it, gotta have something.

EDIT2 - Exporting layers as separate pngs with Krita 5.1 is easy, which is great. I also found it super easy to make Godot change between files for the skeleton, which is also great. A fully white background can also be modulated and used as a freely customizable color, which will be great for skin and some other pieces. Even better, gray colors also work and make great color shading when!

What isn't so great is that if the pieces have different areas (width * height, in pixels), they will get a bit off. I'll probably have to standardize the height for most things, at least, so there goes a lot of time and work.

Maybe I should work on naked versions of these 3 and use this small size for all sex? Something to think about for the future, as I still want scenes with "proper proportions".

 

[papel]

Some player animations are done. Setting up all the bones was quite a bit of work, and they're not really good, but they're good enough for things to work.

Video of current player animation --

You must be registered to see the links

-- As a side note, I've come across a bug in the current version of Godot 4.1,

You must be registered to see the links

. It doesn't cause any crashes, you can still work as if nothing happened. The fix is to simply go to the TwoBoneIK details and change the element's "Joint Bone" indexes One and Two to 0 or any other positive value. The CPP error happens because it's trying to look up at position -1 of an array. If you don't know programming, any array will have, at the very least, 1 thing, stored in position [0]. Trying any negative number will throw an error.

My current step right now is figuring how to bind it properly to player inputs. I know Godot also has some sort of node/tree work that lets you connect animations, which one can lead to which and what to return to after ending the playback.

-- A funny thing is that my drawn assets are huge (in terms of pixel size) and even zooming in a lot won't even come close to their true size. Since I also keep an eye on byte size, 21 player assets (including 2 heads and 2 torso options) come to a whopping 556KB. If I exported them all as having the same working area, which would "help" somewhat with positioning the textures around the bones, the total HD size would become something closer to 950KB. That I can essentially make "infinite" animations with so little in terms of HD size is amazing. The tradeoff of requiring more CPU/GPU power to execute the transformations is probably worth it, as I suppose it doesn't use that many resources.

Current order of things to do:
* See tutorials and stuff to understand how to work with AnimationTree
* Fix the player script to work with the Animations set up
* Add a weapon to the player hand - been thinking of using a leather whip or flail, to keep it kinky
* Resize hitboxes to better accommodate the player size - seriously, the "full sprite" is around 800 x 1600 in width/height, while everything I made so far is for it to be around 60px tall. The sprite is currently scaled to ~0.06

With the above done, repeat the whole process with the current kobold enemy, who is partially boned (HA!). As a mental note, I should probably start with the "start" and "end" steps of each part. For instance, with a leg, key the backmost step, then key the frontmost step, THEN key the middle, which is where there's usually a knee bend in the going forward

-- Working with bones like this also made me think about deformations when I begin working on sex animations - which, if I can keep up this pace, should happen by next week. Using loose parts, as I'm doing with the actual game characters, is much like a paperdoll, you can only change position and 2D rotation (and scale). The problem is that most movement can end up lacking "impact". It looks right at the same time that it looks off. Here's an example: if you slap a breast, the best way to visually convey that impact is to have one or two frames where the side being hit is "flat" and pressed against the hand.

Another GREAT NEW IDEA (tm) I had is adding some torches and candles around, like Castlevania, or some sort of pickups, for the player to get, which is what will power the instakill/instarape bar. This may or may not be implemented in the future

EDIT1 - Ugh, so, the animations work, but, I can't flip them without breaking them in hilarious ways. AnimationTree uses its own state machine of sorts, and the best way to actually make use of the AnimationPlayer is to have the whole node structure of the player together with the skeleton node. Considering my skeleton is a separate scene, I'll probably have to migrate the whole thing to a new scene, changing the structure around. And bring in the code that I can reuse. Fucking hell.

So, my actual worklist at the moment:
- Remake the main player node, with one group of nodes for the skeleon and animation, another for the hitboxes
- ensure the fucking skeleton is at position 0,0 before adding anything to it
- make a single animation with Inverse Kinematics and see if flipping it works
- Proceed to redo other animations (jump, walk, idle, hurt, die, attack)

 

[Aeskus]

This is a cool idea for a project. I don't have much playtime in platformers so I would have to study a few of the classics to get a grasp of the finer points. Even so, this project gives me a few ideas.

- Powerups can affect the in-stage H-scenes. Maybe one powerup makes you bigger and gives you bonus health and weapon reach. When you target a princess you basically get a giant-on-damsel scene. Another powerup might make you hit harder or move faster and those could affect the damsel as well.
- Different types of damsels could give different effects. You could have a royal princess, desert princess, ocean princess, etc. They could give points, extra lives, gold coins, or a temporary bonus when you're done with them.
- Princesses could also be used as part of a puzzle. Maybe they follow you automatically when you save them. Maybe they give you a support bonus or maybe they are just a nuisance. Maybe different princesses give different benefits/detriments and maybe it depends on your status as a good or bad knight. The player could hit the princess or throw her to stun her for several seconds. She will not follow you if you get some distance from her before she is no longer stunned. This allows the player to use her to stand on a pressure plate or platform. Maybe the princess must be made to attract several enemies for the pressure plate to be heavy enough and the good knight ending would require going around another way.

These ideas are easier said than done and they probably won't even fit well with what you're doing, but I thought I'd mention the first ideas which came to my mind. On a side note, I tried out Godot and it didn't take well with me at first. The license is the main thing that attracts me to the engine, but I didn't like that most of the documentation seems to prioritize their GDScript language. I am already familiar with C# and Python, but I haven't been convinced that GDScript is worth learning. However, my mind is open. I will give it a try next time I work on a game with some real-time action.

Thanks for this thread and good luck with your game.

 

[papel]

Thanks for taking the time to read through, Aeskus . One thing I can tell you right away, the syntax of GDScript is very close to Python. If you know Python, you'll get GDScript in no time. Godot also has a version where you can use C#, it's their .NET version on

You must be registered to see the links

. I can't really tell how it fares compared to Unity, which is the "main competitor" when it comes to engine with C# support, as I've never really used it in any capacity other than downloading and checking it out.

As for the ideas, like you said, it's easier said than done. As I stated on my first post, I want to have a MVP first. In terms of game logic, I have a working minimum, which is good, and that's why I'm focusing on animation/art right now, and suffering for "learning on the fly". Kinda my fault for doing it "wrong", but better that it happened in this prototyping stage rather than later on.

-- Two things that I thought during the day that I could hopefully use to fix the situation unfortunately didn't work. One was fixing the origin point of the skeleton (it's not at 0,0 on the scene), then offsetting the IK targets. Nope, didn't work, opposite direction still made it all funky. Thing two, do the scale.x trick on the main target node (a negative scale on any node essentially mirrors it on that axis, a position of 10 at scale 1 becomes -10 at scale -1), without changing anything's positions. No dice, even after fiddling with some positioning. I can still salvage all the animations by keying the bones instead of the IK targets, but then I'll also have to disable IK after finishing the animations. Frankly, at this point, I'm ok with just starting over on the animation part, doing it the right way this time around so I don't make the same mistake with future characters.

>> For anyone wondering, the "wrong way" is making a godot scene that is just the Skeleton2D (and its parts: bones, textures) + AnimationPlayer (and AnimationTree) nodes to be imported into the "proper" entity scene. Ideally, you want to see and access the whole animation stuff and have it interact directly with the code that it will interface with, which is not easy with the scene being imported.

My current idea for different princesses comes from the different levels you'll find them on. Human princess in a temple/castle/dungeon manned by monstergirls, so I could work with level specific gimmicks. As of right now, the princess is this thing that only moves when the player carries her around, so I can make Companion Cube style puzzles with her (minus portals). She also keeps some momentum from player movement, so making places where you have to throw her and then travel around to continue are doable. A powerup that makes you faster while carrying the princess sounds ideal, too.

EDIT -
Man, fuck AnimationTree. Seriously. I can't make that shit work for the life of me. I did manage to make it change between idling and jumping states, but I can't make it go back-forth between idling and running, despite doing a copy-paste of video tutorials. Not only that, if I want an animation to play faster, I have to jump through several hoops. This lack of speed manipulation fucks me up because I'm relying on it a lot to make the animation play decently. Fuck AnimationTree.

So, I'm manually coding which animation should play at what point, and having to do several checks. A bit of a chore, but less so than keying the animations. I'll also have to look into how to export animations for similar but different skeletons, as I'll have to do lots of the same work with the enemies and the princess.

 

[papel]

Alright, coding in the animations is going along now. The spaghetti's not pretty, but it works

Some very useful things to keep in mind if you decide to go with AnimationPlayer to control your animations in Godot:
* Create the animations as placeholders, even if without any "proper" animation. Key them with Modulation to easily distinguish them. You have to have animations set up in order to change between them
* You can change variables' values during the animation timeline. Add Track -> Property Track. Choose the root node if you want to interact with a parameter within your script, or the node itself you intend to handle
** Example: if you want to enable/disable a collision shape, you can add a track
* Use node signals with the AnimationPlayer to ensure that some properties are properly set or reset. One thing I do is to set several flags to false if the animation that just begun is not "Attack", in order to properly "disable" it
* Fuck AnimationTree and its refusal to work properly with me.

I'm also seeing that Bone2D is full of small bugs within the editor, but nothing that's going to crash the game once it's running (hopefully). One thing that is worrying me a bit more is that, when I close the game, the output gives 3 errors:
ERROR: 2 RID allocations of type 'P11GodotBody2D' were leaked at exit.
ERROR: 8 RID allocations of type 'P11GodotArea2D' were leaked at exit.
ERROR: 5 RID allocations of type 'P12GodotShape2D' were leaked at exit.

If that comes back to bite me in the future, I'll be sad and pissed off. I can't find a way to figure which object they're actually referencing, but I strongly suspect it's either the player or the princess.

Anyway, a few things I've managed thus far
* Carrying the princess is fully functioning, might still tweak speeds, especially of "throwing" her around
* The princess is currently really simple, animation wise: idle, being carried, being hurt, dying, and will probably remain at that for the time being
* On the princess' death, there's a 2 second timeout until the gameover screen shows up (called at the end of her Death animation)
* The window-thing to show the sex scenes will show on the left if the player over ~60% of the screen to the right
* All player animations are changing correctly (still haven't added a weapon to him, tho. The hitbox for attacking does work)
* Made a function to easily change the enemy kobold's color. Created a small variety of arrays to keep the parts that will be colored, so you can have same skin + different boot color and vice versa.
These last 2 days didn't feel like much of progress was made, but that's the price of fixing stuff.

Now, off to code the stuff on kobold enemies, make the animations work with the code/states and everything.

EDIT - Whew, what a day! But now the melee kobold enemy is behaving properly. Mostly. There are some situations where I see its state flickering, if its been knocked down (faint) which still allows the player to interact (rape) them. So, I'd say putting the code + animation working together is some 80% done, some 12% being the archer kobold and the rest 8 fixing whatever bugs I haven't found yet.
Tomorrow, I'll probably work on the kobold art and animation and maybe check out a way to put the two skeletons (player + enemy) to look like they're fucking, giving extra reason for the zoom in-out to exist

 

[papel]

Quick update, my game now has infinite% more implied sex than previous versions! The gif speed is slow compared to the actual game, but eh, ShareX isn't helping me out here.

I still plan on making use of the big side window for a more appropriate and bigger sex scene, probably showing from a "camera aligned with the hole" angle

EDIT - +1 in-game animation, missionary sex. It doesn't feel as impactful as the standing thrust, but it's something.
On a side note, I did some cleanup on the project, removing some unused stuff, but there's still a long way to go in this regard. I'm probably one or 2 lines of code away of getting a random sex animation whenever the player interacts with an enemy that can be sexed, as I've set up the proper offset position and speed scale to align the two bodies and make the animation look as synched and "believable" as possible.

Animating is a chore mainly because I only end using IKs to get good positions, then having to key the bones around. Speaking of animation, I did spend over an hour trying to figure why, at one point, my player animation was running way faster than the enemy's, despite both's AnimationPlayer's speed_scale being at the same value. Turns out I left a play() call within the player code that added a custom multiplier to the speed_scale., it looked like this: animation.play("sex_scene",1,1.5,false) - That 1.5 was the culprit. I ditched that kind of call altogether and everything went back to normal.

Animating Positioning the missionary pose was a small challenge, as the enemy lays down to the left, and the player lays down to the right. That means the offset has to be inverted, and either the enemy or the player has to flip horizontally to make it work. Thankfully, the flags I've set up to determine whether they're flipped were already in place, due to the whole walking animations and changing hitboxes and detection areas around also needing that kind of info.

Edit2 - After lurking a bit and checking the most recent topics in Games, I feel like a master level game maker. I'm not making a VN, I'm not using RPG Maker, I'm not using AI and I'm not making something with minimal content to release as a 0.0.0.0.0.0.1 pre-alpha demo to get the ball going. I could do some clean up on the current graphics and make a bare minimum first stage to showcase what's already there, but I'm in no hurry to get anyone's hopes up (lucky me my job pays well enough to cover all my expenses, I guess?)

-

 

[papel]

Right, drew some extra weapons: axe, blowpipe, saber. I also redrew the kobold enemy's muzzle, so that the two variants now also have an open mouth, which should work for blowjob animations. Also did quick but decent looking "hurt" eyes, that should show up in the player and enemy's faces when they're hurt.

After that bit of art work, I took a look at the code and started feeling kinda lost. Some fucking around doing much nothing later, I've figured I might as well write up what I have done so far and compare with what/where I intend to get. Below is a table of stuff that I've done, the stuff marked with ♦ needs further polishing and an explanation of why

Done	TBD
♦ Movement ♦ - Initial work was with small sprites, roughly 50px tall, now the characters are all roughly 4x that size. Gotta rework speed and gravity values.​	Stage art assets - tiles and props​
♦ Player art ♦ - The isolated pieces are done, but nothing to write home about​	Level design - There's literally zero actually playable levels thus far​
♦ Enemy art ♦ - Same as player art, only one type of enemy so far​	Big sex animations - Will probably need a side view (profile) and frontal view for best results, I plan to have them animated much like the game characters​
♦ Animation ♦ - Running, jumping and landing are all fine for the player. Player attack animation is very janky. Sex animations are kinda ok atm, but could be better.​	Princess art and animation - I have a drawn version of her, but I'll have to redraw her body in order to make the carrying animation work properly​
Princess carrying logic​	Sounds and music. There's currently zero of either​
♦ Level complete logic ♦ - Enter the area while carrying the princess and the level ends with success. As I don't have a second level yet, you're just sent back to the main menu​	Option for player to rebind controls​
Game over logic - In case the player dies or the princess dies​	Option for player to change skin and armor color - Should be very easy at the moment, all things considered.​
♦ Combat logic ♦ - The tweaks are mostly about animation speed and reach​	Save and load options from a file​
♦ Traps and projectiles ♦ - I have barebones, but working versions of both. They can hit both the player and the princess​	Clothes to go on top of the enemy characters​
♦ Rape logic ♦ - Grab from behind = instarape. If the enemy doesn't despawn, you can keep raping. Other than beating the enemy, it does nothing. Most of the planned polish is a smoother transition to the rape animation​	Player character's nude parts - Sir knight is currently cockless​
	Better menu interface (art)​
	Gallery mode - Place where all enemies are there, but don't attack.​
	Get rewarded by the princess (sex cutscene) once you finish a level. The reward will vary depending on how many enemies you've raped in that level​

Of my polish list, 2 are straight art stuff and 1 is art adjacent (animation). Of my TBD list, 6 items are all about art.

The code is rather well self contained, but since the majority of the logic resides within the player's script, the thing is becoming very messy, though hopefully it won't get much messier than it already is. I mean, there are some points where I have to use global variables in order to ensure the game doesn't crash by trying to reference a null object. They're extremely useful, but better when used sparingly.

I guess I should, at the very least, have the scenes set up for stages 1, 2 and 3, even if there's nothing there other than just the princess and the end goal, just so there's actual progression in game. With that done, make some art for either an Egyptian temple style stage, or european dungeon one. I think that

So, current task list:
* Create dummy levels 1, 2 and 3, to make the whole level clear logic work -- EDIT1 - Done. Also did a fade out when the player clicks the button to start the next stage. I also managed to get the EnemySpawner entity to spawn the player, so the sir knight can make a "grand entrance" while the screen transition finishes. Gotta add some text around to properly indicate the level is over and whatnot. Moving on to making the assets below.
* Create assets for 1 type of level
* Add checks for which "reward" the princess will give the player at the level's end

 

[Glorified_ignorance]

Well you clearly are making a progress.

Drawing skills will improve in time if you put effort into it.
And wont give into AI...

Interesting choice in mechanics.

Thank you for sharing your thoughts !

Also when are we be able to see sneak peak or at least demo of it (approximately)?

 

[papel]

Another day without much done in the asset department. I fooled around a bit with Krita and the WrapAround mode, which is perfect for making stuff that could fit into tilesets, and I did a number of them. Really fucking huge tiles, check them below. I had fun actually making them, "understanding" that I didn't need to go crazy on details, that just a few strategically positioned lines could imply that it's a bunch of rock or bricks. Then I went ahead and added some shading, because why not?

When it came to actually positioning them as tiles around the map is when I realized that I fucked up. The giant floor slabs were too slanted to fit in, the rocks are decent for a background or something. Only the smaller brickwork can actually keep going for a while, though it won't repeat going downwards, so I'd need to make something to fit with it.
-- One thing I realized I can use is layers, so "fixing" things shouldn't be too hard if all I do is just put something else on top

On an unrelated note, I figured a small bug with the kobold attack, where she always seemed to attack a second time too fast if you got out of her range. Turns out the function state change in her function call happened way sooner than most other stuff. Shifted it later into the animation and presto, bug fixed! Calling functions at specific points of the animation is great stuff, wish I knew about it sooner.
-- Since it was as easy as I thought, I've added the buttons to edit the player colors within the game. The gif below only shows the skin, but it works with the hair and armor, too, persisting through death. I just need to create/save/load a config file where these values can be read from. The fun thing about doing the coding part is that things start making more sense the more I use Godot around, which is great because it's proof that I'm actually learning it! Me smart, gibe cookie!

Give me a few more weeks and I might start making video tutorials


I've also decided on using

You must be registered to see the links

for all the menu text, which I think fits in well with the general fantasy aesthetic i've planned.

On another note, I drew the cock that will be used on the bigger animations. Over 1000 pixels of rock hard love, baby! As to why I make everything in grayscale, it's the same reason for everything else: customization. I might make the cockhead a separate layer, so the player can freely fool around with normal, fantasy or neon colors, because why not.

The female pieces that I have to draw for that cock to make use: ass and legs from behind, torso from the front. And the pussy, obviously.

Also when are we be able to see sneak peak or at least demo of it (approximately)?

Hard to say. Could be sometime this week, could be next month.

 

[papel]

Worked mainly on the keybinding screen today. I dreaded this shit because it really, REALLY sucks trying to make it work on Godot if you want to have more than 1 key doing the same action. Been on this shit for literally 4 hours straight now, the first 2 was getting the bare minimum working, the 3rd was ensuring it didn't cause any crashes and the 4th thus far has been trying to figure a way to reset keys to their defaults. Took quite a while, but I finally managed to make it work. Fucking hell, I know Unreal makes it dumb easy to remap controls, what about Unity? Because it sure feels like Godot is the worst in this regard among the 3.

Oh yeah, the default keybinds allow for 1 handed play, either with the right hand (arrow keys + ctrl) or the left (WASD+E). That's all you'll need by default to beat the game, as the other hand will be free to beat yo meat

Anyway, I think I can still spend an hour or so drawing today, might finally make some placeholder/kobold legs for the big sex scene. Might also make a smaller sideview cock to be shown in the gameplay sprite, as the giant one loses all the linework being scaled down so much.
Been also thinking about the whole layering, adding a "ripple effect" layer for the crotch on ass impact would certainly look lovely.

 

[papel]

Did nothing yesterday, fun came first.
Today, so far, I've finished a number of weapons. Aside from the whip, which I plan to give the player and will require boning it as a texture for a proper whipping animation, and the bow, which will also need some bones, but should be simpler, they just need to be set to a hand bone to work (i've also just realized I haven't shown all the current animations of the kobold enemy)



Gonna work on tilesets again, now I have a proper idea on how to make them work with layering: make a 300x300 set to be divided in 9 tiles of 100x100, seamlessly repeating among themselves. Once that's done, remove some 20-30px from the borders, save it as a copy. I'll probably create the first one-way platforms (platforms that you can jump into from below) after that, too.

So, current todo list:
* Finish first level tilesets - EDIT1: Still WIP. The ones I did atm are kinda odd looking, see attachment below
* Add a working, animated whip to the player - Edit3 - Boning the whip isn't working too well. I'll probably ditch this idea and leave the player with a normal weapon like a sword or hammer
* Create logic for one way platforms - EDIT1: Was easier than I thought, Godot has a ready-made flag to turn that on/off. Done
** Draw them
* Add bow-shooting logic to the currently boned kobold enemy - EDIT1: Done
** Animate said bow shooting on the kobold - EDIT1: Done. Animation is still a bit wonky, I still have to key the legs so it doesn't "freeze" into the previous animation (visible in the attachment below), but the kobold can fire at any speed; can have a permanent firing mode; will return to patrol after firing. Just need to spawn the arrow again - Edit2 - Everything working as expected
* Draw wooden and metal spikes for spike traps


The kobold looks too fucking cute, in my opinion. Almost makes me feel bad for the rape and the pained expressions I have drawn already. Almost


EDIT2 - As I was messing with the kobold, I came across some bugs in Godot due to bones' IK (it's been reported over and over on their github). Somehow, somewhere, I did something that altered the animations' property settings and function calls, which completely fucked up the enemy AI/State logic. Luckily, fixing it wasn't hard, I just had to create new keys and point them to the proper node, but it took me some time to figure the problem was there

A more technical possible explanation: you can set up keys in Godot's animation to change variables or call functions, something I'm using mainly to change states, but also to spawn the shot arrow. At one point, I've added a number of kobolds to the first stage, naming one of them "melee1". After some fiddling with animations and the Skeleton modification stack (the thing that enables/disables IK), I deleted the melee1 and other enemies from the level, saving everything. That's probably where things broke, because all the broken references in the animations were pointing to "../../melee1" node, for whatever reason. Since that change happened without any sort of warning, it would be impossible for me to have guessed it

On another note, I've added a bit of code to finally set up colors for the enemies, see below. Gonna add a bit to allow it to be randomized Done



Shitty whip


FINAL EDIT of the day

Made the player's cock, so now it can look like he's actually fucking the enemy. One thing that was happening was that the cock was going past the ass in the from-behind animation, so I had to figure a way to hide/mask it. That took WAY longer than it should, because most tutorials and stuff point out how to do it in version 3.x, using Light2D and Occlusions. I tried that, couldn't get it to work.
Then, plenty of posts talking about shaders, and plenty of complaints that Godot made it stupid to apply masks to sprites (true). Alright, experiment with shaders... Nope, nothing. Fucking fuck.
Finally, after roughly 2 hours of googling, I found out how to actually use texture masking in Godot 4:
* Have the mask as a PNG file, white is where it'll apply
* Create a sprite node, load the mask PNG as a texture
* Under Material, create a new CanvasItem
* On the CanvasItem, select the option SUBTRACT for the Blend Mode
THERE! FUCKING DONE!! Jesus, I feel real sorry for everyone who had to suffer through Light+Shadow or, worse, Shaders, to achieve this kind of result.

Anyway, below you can see why I need to mask the cock texture

 

[papel]

First, and addendum to my previous final edit, which I didn't edit further because, well, it was supposed to be final
- The sprite nodes all have to be under the same CanvasGroup node for the mask to actually work.

Now, back to our programming!
Ever wanted to rape a cute, adorable kobold gal and have their facial expression show that they are, indeed, being raped and hating it? NOW SOON YOU CAN!

Video 1, blueish, beaky muzzle -

You must be registered to see the links

-

You must be registered to see the links

Video 2, light pink, big reptilian eyes -

You must be registered to see the links

-

You must be registered to see the links

The gemoo links are in case the catbox.moe ones fail to load. The gemoo videos will expire by September 15, 2023

These extra eyes and muzzles were created on and off during the past week or so. Making the beaky mouth showing the teeth needed a LOT of trial and error, several previous versions looked weird or off for one reason or another. I'm not 100% satisfied, but what I put there is good enough. Also added those scaly bits to the 'bold, make them look more lively. Just need to add a pussy to show during the missionary position. I'm also thinking whether to make the eyes and muzzle change at different times, one taking ~4 seconds and the other ~6. Right now, the timer calls for a random choice of both at the same time.

You may also notice some text at the top. It's tooltips telling you what the buttons do while you're sexing. Left and Right (or A and D) change the sex speed. JUMP (up arrow or W) resets it back to normal. GRAB ends the scene. There are also 3 clickable buttons (not shown) that you can click to speed up/down or reset the speed. I didn't set up any limits, as the reset button works if you ever "break" the speed, either by going too fast or going into negative and playing it backwards.

Overall, my work today focused more on cleaning up a bit on some of the existing animations, adding details to the kobold body parts and fixing some oversights of mine, including one that let an archerbold fire after being hit, which interrupts their attack. The problem was that I set up the bow animation on a separate AnimationPlayer node, so there's one animation for the kobold's movement and a parallel one where the bow's string is pulled, which is also the one that spawns the arrow.
- Known bug 1-> Being hit with the arrow always sends the player to the right, even if the arrow hit from the right
- KB2 -> Sometimes, hitting a fainted* enemy will make it slide along the floor until it hits a wall.
- KB3 -> Right after finishing a sex scene, if you're fast, hitting the enemy will trigger the "HURT" animation/state. She'll fall back into the fainted* loop, so it doesn't really affect anything
* fainted -> enemy status where she doesn't immediately despawns and remains on screen, with the player able to rape her.

Say, Papel, wasn't this game about saving a princess or something? Where is she?
- Yes! And great question! Er, uh, see, she's over there, needing to be rescued!
What about those big animations you promised forever ago? Did you do anything yet?
- Well, uh, um, well, uuhh, see... Actually, I did something! I

You must be registered to see the links

to use as reference! From the looks of it, I can make both a mating press and a full nelson with a woman on that kind of pose. I can probably reuse that leg position, draw the arched back and make a from behind and a cowgirl (or would it be a reverse?) fuck scene, too.

On another note, I might probably work a naked body for the player character. At the very least, I'll make 2 pointy ear variations and an orcish mug and nose. The player still has plenty of things that need to be cleaned up and fixed, mainly regarding the attack animation, which sometimes repeats if you time it just before landing from a jump. Still haven't added a weapon to the player after the whip fiasco, despite that being literally a drag'n drop thing. Go figure. I also spent a lot more time than i'm willing to admit adjusting the player's cock to make it look as veiny and virile as I could, something no man could find fault in, even if you can barely see it at maximum zoom. I'll probably end up reworking on the bigger versions I've already finished

EDIT - Made 3 helmets for the player, 4 extra ears (one furry, one robot/joke), 2 new hair styles (had some made previously, the total is 6 hairs now). I'll see if I reposition them later, make them all use the same resolution for easier changing while in game. Gotta add some buttons to change those around. I'll also look into how RemoteTransform works, something that'll make my life easier when it comes to defining which image goes on top of which

 

[papel]

Took my time working on fixing the positions of most of the player's customizable parts, so changing the textures puts them all in the right place already.

After that, I worked on creating a new screen in the options menu to allow the player to change around the available options. It works, but it doesn't show the current position. Also, just for simplicity and getting -something- working ASAP, I just put a cap at 10 pieces, defaulting to loading the texture 1 if nothing is found. On this regard, my work to make this piece work properly means doing the following:
- Count the number of files for each part (mouth, eyes, nose, etc), store them into a Global array and use that as the actual limit to loop back into one

And here's some video evidence of it working, ~2.3MB mp4 video -

You must be registered to see the links

(decided to go with MF because catbox.moe keeps having problems)

So, me being me, I set out to do that as soon as I finished typing the above. After fiddling with the two arrays (current loaded piece, maximum number), I figured I might as well use a Dictionary (

You must be registered to see the links

) instead. The good is that it actually worked really well, since using the keys instead of a number for an array's index makes things much simpler for my code: texture[hair_current] = 2, if next_tex > texture[hair_max] -- go back to 1. Since the keys are strings, I can concatenate the specific part + "current" or "max" and immediately know which thing I'm dealing with. Too bad I made a whole code with two arrays prior to using the Dict, but hey, learning experience?

At one point, I had a dumb bug that kept the Ear and Nose loops "wrong". As usual, I was writing that I had the bug and couldn't figure it out, then decided to actually see and fix it. Turns out I wasn't resetting the file count when populating the Dictionary above. Small wonder that it somehow still worked! The good news is that now I can simply keep pumping more customization options and no longer have to code their numbers around. MAGIC!!!

One thing that -is- making me sigh in defeat is the amount of .PNG and .png files. Yes, some are allcaps, others are not, and that's just a problem begging to happen when the game is exported. So, I'll probably fix that tomorrow, as it's very likely that Godot will complain about one file or another "not existing" and breaking something.

Another bug that I found and that I'll have to look into: start the game, pause (ESC), click the "Continue" button. Pressing ESC again one time won't bring the menu, but a second press will. This is a side effect of some code I made to allow the player to press ESC within the menu to close it. I'll see if I can figure something out another day.

 

[papel]

Also posted here -

You must be registered to see the links

What's been done today:
* Added a "cunt mask" to the kobold, so there's a more apparent penetration while on missionary position
* Added a bit of belly shadow while the kobold is in missionary to better imply the position, so it doesn't look like her pussy is in the middle of the belly
* Current total of customizable parts: eyes = 10, hairs = 10, ears = 5, noses = 8 (including a cat nose and a dog nose), mouths = 9, head shape = 2. Since making more requires zero further code effort to make the game load them, I'm considering leaving the Krita file for anyone that feels like making some extra
* Did some cleanup on the player attack animation, added a saber to his hand and sped it up a bit (takes a bit less than a second to finish)
* Fixed what I considered a bug: if the player landed from a jump while attacking, the animation would be partially intercepted and you could immediately attack again, jump or move. Now, the attack animation has priority and has to finish first before the player can move/attack/jump again (think old castlevania games)
* The above had another bug, if a jump/fall took longer than the full attack animation, it would repeat. For some reason, even when the animation called a function that set the "is_attacking" flag to false, it remained true. What -really- got me confused is that there was only one line in my entire code that ever made the flag "true". After over an hour trying to figure it, the problem was on an animation call, because I set up a variable for "play_next". While the attack happened, said variable never changed, so it always called "attack" again. Adding a key to change it at the end of the attack animation worked.
* Fixed a bug that caused a fainted enemy to keep moving if hit (KB2 listed back in Sept-8)

At this point, I will turn my attention back to the princess, probably redraw some pieces, put them in place in her skeleton and animate her. Should be only 2 animations: being carried and idle, maybe a 3rd one for vertical movement (falling). With her done, I'll finally shift my attention to level design, get 3 levels done and hopefully release the first publicly available version of the game.

 

[papel]

Also posted here -

You must be registered to see the links

Did some work on the princess, I removed her old skeleton node, as it was a copy of the player's, and made a brand new one with the new naked parts I drew for her. The good is that I can probably draw all kinds of skimpy and slutty clothing to put on top. I've also used RemoteTransform2D nodes within the bones, they're basically pointers to actual textures. This is useful to set up the draw order of each texture. Since I've put them all in a CanvasGroup, if need be, I can also apply masks, or "cutouts" to any of them easily. I really should do the same to the Player and Kobold textures, but I'll also have to retarget some code to point to the new places. Gonna leave that for another time, as I want to get a v1 release now.

Anyway, the first thing that happened that got me scratching my head once the new skeleton was set up was figuring why the fucking fuck the bones were all fucked up when I applied the InverseKinematic modification. See, the IK works as a "target" for bones to "reach for". For some reason, the target was actually acting more like a same-pole magnet, making the bones "look away" from the target.

After an unsuccessful google search and a frowny face at the bone nodes, I decided to uncheck two bones' "auto calculate length and angle" and set it manually myself. It wasn't precise, but it was something. Lo and behold, the IK targeting was now working! So I had to manually set some lengths and angles for 8 bones: upper/lower arm/leg for right and left sides. All good now!

Next thing was making some animation for idling and being carried. The idle won't be final, but it's a "start". The carried animation looks ok, but the transition is very obviously "amateurish" to and from it. I'll also have to figure a way to make the player's arms, or at least the hands, show on top of the princess, to better give the impression that he's carrying her (and get her right arm behind the player, too, so it looks like she's hugging his neck)

You must be registered to see the links

So far, so good. Then, as usual, I've started to get some problems in the code. For whatever reason, when the player was carrying the princess and got hit, while her collision box would be enabled, she'd fall through the floor! WHY? WHYYYYYYYYY??? No, seriously, this was the most "what the fucking fuck" moment in my journey thus far. The collision box is ENABLED, the debug shows that it SHOULD collide with the floor, NOTHING on the code ever changes what things it collides with, if the player drops her normally, the collision works as expected, but not when the player is hit while carrying her. And it wasn't like I called a different function when the player was hit compared to when he simply dropped her, in both cases it was the same function being called.

I did manage to fix it, but I'm not too happy with the solution. I've added a property set on every animation other than carried, where it enables the collision box again. At first, I used a Signal function, which did that, but straight on the code. Yet it failed. Doing it straight on the animation tracks, somehow, works. Maybe it has something to do with a bunch of errors the debug throws, "can't change this state while flushing queries" - excuse me? My code was literally this:

func _on_animation_player_animation_started(anim_name):
if anim_name != "carried":
$collision.disabled = false

If it starts playing any animation BESIDES carried, turn on the collision box (make it false that it's disabled). I have no fucking clue why that didn't work, nor why it led to flush queries debug errors.

Anyway, tomorrow I'll probably work on adding details to the princess, add a bit of random variety in her generation and maybe make some clothes. Also work on breasts.

 

[papel]

Despite what I've said in my previous post, I've actually began transferring the player textures to the Transform nodes. As a safeguard, I haven't deleted anything that is currently present and already working. Thus far, changing the textures of the player's facial features and bodypart colors is working perfectly. Also, instead of normal Arrays pointing to the textures, I've made new Dictionary variables. This means I no longer have to use a "match" functionality, which reduces written code a bit.
Further work is aligning them with the bones, checking if all animations are working fine, then finally remove old texture nodes and references to them in the code.

Should've spent time drawing parts for the princess, but did nothing. Blergh.

Today was also interesting because I've caught wind of Unity's extremely asshole announcement, where they want to charge 20 cents PER INSTALLATION from every developer that manages to break a threshold of 200k lifetime installs and 200k dollars revenue in 12 months. Oh, that'll apply to already released titles, if they broke the minimum requirement, they'll be charged starting Jan 1st 2024. I sure feel glad I've never got around learning it, the bloat was unbearable. I've spent a significant amount time today discussing the matter around Lemmy. If I had a boss, he'd be yelling at me for being unproductive. As I'm my own boss in this project, I say "count that as R&D time"
- Unity's blog detailing the idea -

You must be registered to see the links

- Some of the backlash -

You must be registered to see the links

- One of the threads here in F95 - https://f95zone.to/threads/unity-tax-engine-alternatives.174418/
- Another thread here - https://f95zone.to/threads/so-long-unity.174385/post-11714934

With what I have right now, I could probably work on another game idea I've had for a while, that involves lot of sex, a more straightforward "catch and rape" type of game. Future idea, not gonna work on it anytime soon, gotta finish the current one first.

On a smaller note, I had shit sleep last night and need to buy some anti allergics. Hopefully I'll have a better night tonight