VN Ren'Py The Moorcock Incident [Dev Thread] - Big Titty Snobbish Girl Slow Corruption

[Heavenly6]

DynamiteJoe/RenMan3DX
knows what kind of man I am
View attachment 5430054

How could anyone not know what kind of man you are? That dapper top hat, the strong prominent brow, and thick luscious lips say it all imo.

 

[osanaiko]

Wowee, a month has passed and no updates from me. How embarrassment!

In this case, no news is... no news. Nothing much has progressed over the past 4 weeks, which gives me a big old sadface .

In my defense, I was rather busy with a couple of editing projects:

* The first one was the new chapter of Color Of My Sound, which is about to release to 2nd tier Patrons. This release hasn't leaked yet, so you plebs don't know just how good it is, lol. Highly recommended if you like that style of game.

* The other is the script for the first episode of the new season of "A Long Journey", in which the plot thickens as MC's "friends" awaken!

I did squeeze in a couple of fun sessions working on the main minigame for T.M.I., trying a few different card designs and costings to see how it would affect the gameplay. As part of that I replayed some of the inspiration for TMI, "OnEdge", and was reminded of the excellent buildup of erotic tension via the small text injections and character expressions. Definitely as aspect of that game that I will shamelessly imitate.

Anyway, the holiday season approaches and I should have some more effective blocks of time to invest in kicking the game forward. There is so much I still want to put in, to make it a cohesive first release... and then there are all the new ideas, new filthy, dirty scenarios... which I am dutifully recording in a big "future plans and ideas" log.

On that note... farewell for now~ next post I promise to bring some more art!

 

[alohzzz]

nice project

 

[osanaiko]

Super rapid update and shameful admission of failure

While enjoying some time off from $DAYJOB I have returned to active dev on this project, spending quite a bit of time over the past week or so.

I felt like a fair bit of the narrative section is getting close to being usable and decided to go back and re-look at the gloryhole minigame part. Checking the update timestamps, I was dismayed to find that I was last working on it in 2024 (gulp). That is last year.

Revisiting such ancient code was an *unpleasant* experience. I'm amazed that I got it working at all, and now I am astounded at my mortal hubris in thinking I would be able to use such extremely complex code in a working game.

The issue with a complex design is that it's hard to understand, and fragile when making changes. Therefore trying to work from a starting point that is already overly-complex would be a death knell for a game like this because... the minigame is the heart of the "The Moorcock Incident" game - it has to be *good*.

I want (need?) the minigame part to fulfill the following requirements:
- it must be smooth to play (not frustratingly jerky or filled with annoying pauses or UI clunks)
- it should be visually attractive (animations smooth and connected, screen and UI transitions etc smooth)
- it must be "extendable" (so that more types of interactions can be bolted on as content is added)

Smooth and "feels good to play" is actually kinda hard in Renpy (or at least it is difficult for someone with my meager ability) - the framework is simply not designed in a way that would make it easy to do what I imagine in my mind

In a more custom game engine design you would set up an event loop that gets run (i.e.) 60 times a second, where user input is taken in, game logic is executed, and output images that reflect any state changes are drawn. But Renpy does not work that way unless you get right into the guts with "Creator Defined Displayables". Instead, it's all about reacting to user interactions to trigger actions, with no easy way to setup a sequenced programmable animation to play in parallel to other screen updates, main image animation, sound effects and button interactivity.

As I mentioned, I *did* manage to get such a thing somewhat working by using Renpy screens with short interval timer loops that continually trigger an "action queue" runner. Upon each timer event (which sadly trigger no faster than ~20 times a second and can be even slower when there is a lot going on, or on a lower-power CPU platform) the runner would check the top event on a queue and if the event's TTL (time to live) had been reached would run a callback function to do something like update a UI bar, or swap out a displayble, or increment a score counter. By queuing up various actions with different TTLs something that looked like a "many parallel animations" screen could be faked.

So... where does that leave me? I believe I need to rethink the design and stop raging against the machine fighting the renpy framework design.

Renpy does have some ways to do effective "update this UI element x seconds later" via the ATL system. The most basic/visible use of this is the renpy.notify function which shows a background animated ui element that then auto fades away some time later - and does not interfere with the normal actions of the player at all.
I think that with prudent use of that sort of technique, along with changing the user interactions of the minigame play design into something that is a more direct "choose action" -> "watch result" loop, will let me build a core game element that is sustainable.

I've partly come to this conclusion from the knowledge gained via digging into source code for various other games over the past year.
A Very Full House is one, and Decked in Love by my long vanished man-crush MrSilverLust is another.

I even spent some time trying to understand what the fuck is happening in the code of the game that inspired me to make this one, "On Edge", but that is double cursed because a) it's fucking RPGM which mostly does not use actual source code but instead is all made in a Windows editor, and b) the javascript code modules that the dev did create custom for the game are a hellscape of unused code paths, cryptic names, and commented-out functions. I truly beleive that one of the reasons that the original dev abandoned the game is because he had written something so complex that when he came back to it after a break he could no longer understand it. I will take that lesson to heart - complexity is the enemy.

And finally, after vomiting nearly a sophomore-level essay of words into this text box, I will reveal the shameful confession...

I do not have any new art to show you. It has all been code this past week.

Sorry!

 

[Sepheyer]

Super rapid update and shameful admission of failure

While enjoying some time off from $DAYJOB I have returned to active dev on this project, spending quite a bit of time over the past week or so.

I felt like the a fair bit of the narrative section is getting close to being usable and decided to go back and re-look at the gloryhole minigame part. Checking the update timestamps, I was dismayed to find that I was last working on it (gulp) last year.

Revisiting such ancient code was an *unpleasant* experience. I'm amazed that I got it working at all, and now I am astounded at my mortal hubris in thinking I would be able to use such extremely complex code in working game.

The issue with a complex design is that it's hard to understand, and fragile when making changes. Therefore trying to work from a starting point that is already overly-complex would be a death knell for a game like this because... the minigame is the heart of the "The Moorcock Incident" game - it has to be *good*.

I want (need?) the minigame part to fulfill the following requirements:
- it must be smooth to play (not frustratingly jerky or filled with annoying pauses or UI clunks)
- it should be visually attractive (animations smooth and connected, screen and UI transitions etc smooth)
- it must be "extendable" (so that more types of interactions can be bolted on as content is added)

Smooth and "feels good to play" is actually kinda hard in Renpy (or at least it is difficult for someone with my meagre ability) - the framework is simply not designed in a way that would make it easy to do what I imagine in my mind

In a more custom game engine design you would set up an event loop that gets run (i.e.) 60 times a second, where user input is taken in, game logic is executed, and output images that reflect any state changes are drawn. But Renpy does not work that way unless you get right into the guts with "Creator Defined Displayables". Instead, it's all about reacting to user interactions to trigger actions, with no easy way to setup a sequenced programmable animation to play in parallel to other screen updates, main image animation, sound effects and button interactivity.

As I mentioned, I *did* manage to get such a thing somewhat working by using Renpy screens with short interval timer loops that continually trigger an "action queue" runner. Upon each timer event (which sadly trigger no faster than ~20 times a second and can be even slower when there is a lot going on, or on a lower-power CPU platform) the runner would check the top event on a queue and if the event's TTL (time to live) had been reached would run a callback function to do something like update a UI bar, or swap out a displayble, or increment a score counter. By queuing up various actions with different TTLs something that looked like a "many parallel animations" screen could be acheived.

So... where does that leave me? I beleive I need to rethink the design and stop raging against the machine fighting the system design.

Renpy does have some ways to do effective "update this UI element x seconds later" via the ATL system. This most basic use of this is the renpy.notify function which shows in the background an animated ui element that then auto fades away some time later - and does not interfere with the normal actions of the player at all.
I think that with prudent use of that sort of technique, along with changing the user interactions of the minigame play design into something that is a more direct "choose action" -> "watch result" loop, will let me build a core game element that is sustainable.

I've partly come to this conclusion from the knowledge gained via digging into source code for various other games over the past year. A Very Full House is one, and Decked in Love by my long vanished man-crush MrSilverLust is another. I even spent some time trying to understand what the fuck is happening in the code of the game that inspired me to make this one, "On Edge", but that is double cursed because a) it's fucking RPGM which mostly does not use source code but instead is all made in a Windows editor, and b) the javascript code module that the dev did create custom for the game are a hellscape of unused code paths, cryptic names, and commented-out functions. I truly beleive that one of the reasons that the dev abandonded the game is because he had written something so complex that when he came back to it after a break he could no longer understand it. I will take that lesson to heart - complexity it the enemy.

And finally, after vomitting nearly a sophomore level essay of words into this text box, I will reveal the shameful confession...

I do not have any new art to show you. It has all been code this past week.

Sorry!

Do give Godot a chance. My own productivity went up x50 after switching from RenPy to Godot. Say "fuck it", download the Godot, tinker with it a week, then go to making your minigame in Godot - you'll be pleasantly surprised.

 

[mibc9394]

Do give Godot a chance. My own productivity went up x50 after switching from RenPy to Godot. Say "fuck it", download the Godot, tinker with it a week, then go to making your minigame in Godot - you'll be pleasantly surprised.

Hey sir your words interested me. I am very bothered by the limitation on the camera and the visual effects I can achieve in Renpy. How easy is that to make a visual novel in Godot with some custom day/time and flag systems for multi-branch story, compared to Renpy?

 

[Sepheyer]

Hey sir your words interested me. I am very bothered by the limitation on the camera and the visual effects I can achieve in Renpy. How easy is that to make a visual novel in Godot with some custom day/time and flag systems for multi-branch story, compared to Renpy?

Welp, RenPy is the champion for how easy it is to make a Visual Novel. Probably Godot won't be an improvement in that particular aspect.

Godot has a bunch of modules for VNs - you can either pick those, mix and match them, or make your own.

After trying a few, I decided to make my own VN module - this way all pics are right there, I dont have to strain my brain what's where and I can easily drug/drop duplicate/hide each slide. Kinda a glorified PowerPoint, right?

This is about 2-3 weeks of work, including making icons and re-writing everything from scratch a few times.

As a benchmark - in RenPy I could never get past 20-30 slides. Then my brain starts hurting and I say "f* this". When I switched to Godot making stories became much easier, my own energy wasn't being depleted as fast as it was when I was doing RenPy, and the only true limitation became the available time.

Spoiler: More

You don't have permission to view the spoiler content. Log in or register now.

 

[osanaiko]

I appreciate the suggestion Sepheyer, and I do hope that a Godot powered "all in one" competitor for Renpy emerges sometime (let a thousand flowers bloom, etc.). It would shake up the scene and hopefully allow new types of games to appear - more flexible and performant UIs for semi-action games.

But last time I looked at Godot, the situation for VNs was similar to what you described: lots of modules of varying quality by various devs, some abandoned and some actively changing. And it was up to the game dev to somehow pull together a working set of these to merge them into single cohesive VN game engine.

Personally, I think I'd rather work towards my goal within the framework I know best, than become the sole-developer of both an e..x..treeeme...ly slowly progressing game as well as a custom game framework.

There is a lot to be said for the RenpyTom effect - a single "benevolent dictator for life" who holds the primary control over what renpy is, and keeps the developer experience consistent with his opinionated take on things.

 

[Quintillian]

Happy Holidays Everyone!

My two cents. Give CDDs a try. At the end of the day that's just you and the pygame layer below the RenPy stuff. That should be a good trial by fire test to see what's possible or what needs compromise.

 

[Sentinel Sparrow]

" I'm making a game (2 year anniversary approaching! ): " ts okay, please feel better; i spent a year and havent figured out what im making been romanticizing about starting a new project too. you're not alone. i hope things work out for you, you got this