Others Going Deeper [Beta 2.1] [NRFB Games]

[Rosen King]

Tweet time again:

You must be registered to see the links

You must be registered to see the links

You must be registered to see the links

I don't have much to comment here because I really don't want anything to do with mods, and I'd rather not get into the reasons why. I just hope this doesn't lead to a deluge of "just mod it" whenever someone tries to discuss the game. It's... Well, again, I don't want to get into the whole discussion of why. (At least not here.)

 

[RandomFapinator]

Tweet time again:





I don't have much to comment here because I really don't want anything to do with mods, and I'd rather not get into the reasons why. I just hope this doesn't lead to a deluge of "just mod it" whenever someone tries to discuss the game. It's... Well, again, I don't want to get into the whole discussion of why. (At least not here.)

Nice didn't pay attention to tweets! Not a lot of people are coders, and a lot of coders will pick up patterns as they try stuff. Just need to tell them where to look at, and they might pick it up automatically: the documentation might not need to be long.

 

[NRFB]

No penises get inserted into any vaginas (yet? I'm not looking forward to that if so)

You certainly shouldn't expect this to NOT happen eventually. As I said I don't really have any mechanics for it to happen figured out/built with regard to gameplay.

You don't. (Yet?) Fortunately, there's nothing in the game yet that takes more than a tiny bit of favor.

On the one hand favor feels like the kind of thing that is weird to just have an easy to see numeric representation of, but then on the other hand since the number is a requirement for some things it probably should be surfaced SOMEWHERE.
I'm just not sure where.

Aaah so Exclusive Skills don't have a scroll. I thought I was going crazy. So there's a mama bear ...
Is there any FAQ posted somewhere? I don't hate you guys but I am not motivated to read the 32 pages of discussion lel

I can give the same answer to this as I can give to someone who was asking me about a wiki:
Not that I am aware of, but if somebody else was going to set something like that up I would happily fact check any information people compiled for it.

I don't have much to comment here because I really don't want anything to do with mods, and I'd rather not get into the reasons why. I just hope this doesn't lead to a deluge of "just mod it" whenever someone tries to discuss the game. It's... Well, again, I don't want to get into the whole discussion of why. (At least not here.)

I have no idea how much people are actually going to use modding in the first place honestly. I'm more setting it up for me, both in the sense that I can use it for small json patches post update release, and in the sense that making the game moddable is interesting and fun and something I wanted to do from the start. Expecting any huge amount of user made content is basically real life rng, so while I'll probably enjoy things that people make, I don't have any particular expectations.

Nice didn't pay attention to tweets! Not a lot of people are coders, and a lot of coders will pick up patterns as they try stuff. Just need to tell them where to look at, and they might pick it up automatically: the documentation might not need to be long.

One guy in my discord has decompiled the exe and regularly looks through the base game json files as well as the code without any comments (since the compiled version removes all my many many comments), and now seems to have a reasonable idea of how things work. You're probably right that other people will be able to pick it up without needing EVERYTHING explained. Looking things over while being forced to write things down like this is a good opportunity to look at what needs refactoring and such though.

 

[Rosen King]

On the one hand favor feels like the kind of thing that is weird to just have an easy to see numeric representation of, but then on the other hand since the number is a requirement for some things it probably should be surfaced SOMEWHERE.
I'm just not sure where.

Perhaps a way to "indirectly" show it by interacting with the knights? Like if you flirt with them and they have five different responses based on their favorability. Or maybe when you call them to your tent, there's a bit of text about how they enter (and/or exit) that gives away their mood. "Raine awkwardly steps inside your tent and looks at you expectantly. 'Um, did you need something, boss?'" "Lucette is all smiles as she enters your tent and immediately plants herself in your study chair. 'Hello, Inquisitor! You wanted to speak to me?'"

I have no idea how much people are actually going to use modding in the first place honestly. I'm more setting it up for me, both in the sense that I can use it for small json patches post update release, and in the sense that making the game moddable is interesting and fun and something I wanted to do from the start. Expecting any huge amount of user made content is basically real life rng, so while I'll probably enjoy things that people make, I don't have any particular expectations.

I wonder if it might also be a good way to work together with someone else on certain elements, rather than just entirely leave it as user-made mods? For example, you said that you didn't properly trust yourself to make egg-laying content and would leave it to someone who has that fetish, but what if instead you just left the parts you don't trust yourself with to someone you do trust with it, with them now having the tools to handle those parts, while still working to make sure it feels like a natural part of the vanilla game instead of something just tacked on by an outsider?

Hmm... Now that I think of it, this could also be a decent way to implement a sort of content filter. What if content associated with certain themes is loaded separately as a "mod" (properly labeled as vanilla content, e.g. "Vanilla - Futanari Content"), and we can simply enable or disable it from there? (Edit: Although this might not work as well for things that fall into multiple categories, like futanari spiders, or clown amputation, or something like that.)

 

[RandomFapinator]

I wonder if it might also be a good way to work together with someone else on certain elements, rather than just entirely leave it as user-made mods? For example, you said that you didn't properly trust yourself to make egg-laying content and would leave it to someone who has that fetish, but what if instead you just left the parts you don't trust yourself with to someone you do trust with it, with them now having the tools to handle those parts, while still working to make sure it feels like a natural part of the vanilla game instead of something just tacked on by an outsider?

Hmm... Now that I think of it, this could also be a decent way to implement a sort of content filter. What if content associated with certain themes is loaded separately as a "mod" (properly labeled as vanilla content, e.g. "Vanilla - Futanari Content"), and we can simply enable or disable it from there? (Edit: Although this might not work as well for things that fall into multiple categories, like futanari spiders, or clown amputation, or something like that.)

I feel like that's a lot of extra work. I am not sure the gain is worth it, more documentation might be necessary to be sure that distinct core developpers (i.e core game content and not modders) agree on the code structure and enforce ground rules to ensure interoperability of the different parts.

I do not know how the architecture is currently made, but for example a content filter probably needs particular tags for everything related and modders will have to be sure they properly tag their content (and consider the case multiple parts of their mods could be disabled at all times, and code accordingly). To enable as many mods as possible and ease interoperability, the core architecture has to be made with potential additions/substractions of various mechanics in mind.

Interoperability between mods can be a nightmare. Mods example:
- on combat: a level up system, with rewards depending on actions (sitting on the camp gives no xp for example)
- on camp: itemization to characters with equipments?
- mods that touch the UI to interact with extra mechanics

What happens with save compability? Is everything broken when you load a mod then remove it later?

If some random person on discord depiled the .exe and understood how everything works it cannot be that complicated for now (in this alpha state at least ). Looking at mainstream games (Skyrim, etc...), it is often common that modders would like their mod to be compatible with popular mods, thus will work it out eventually. All in all, leaving most things to the users is not that bad: if a mod becomes a must (like, a bugfix/rebalance mod), it's up to the developer to make it part of the core game eventually.

 

[Rosen King]

I feel like that's a lot of extra work. I am not sure the gain is worth it, more documentation might be necessary to be sure that distinct core developpers (i.e core game content and not modders) agree on the code structure and enforce ground rules to ensure interoperability of the different parts.

I do not know how the architecture is currently made, but for example a content filter probably needs particular tags for everything related and modders will have to be sure they properly tag their content (and consider the case multiple parts of their mods could be disabled at all times, and code accordingly). To enable as many mods as possible and ease interoperability, the core architecture has to be made with potential additions/substractions of various mechanics in mind.

Interoperability between mods can be a nightmare. Mods example:
- on combat: a level up system, with rewards depending on actions (sitting on the camp gives no xp for example)
- on camp: itemization to characters with equipments?
- mods that touch the UI to interact with extra mechanics

What happens with save compability? Is everything broken when you load a mod then remove it later?

If some random person on discord depiled the .exe and understood how everything works it cannot be that complicated for now (in this alpha state at least ). Looking at mainstream games (Skyrim, etc...), it is often common that modders would like their mod to be compatible with popular mods, thus will work it out eventually. All in all, leaving most things to the users is not that bad: if a mod becomes a must (like, a bugfix/rebalance mod), it's up to the developer to make it part of the core game eventually.

I'm not sure what you're talking about, or whether you read my post correctly at all... Actually, I'm thinking maybe you read the two paragraphs as a single point instead of two separate ideas of what might be done with mods? I have no idea what the combined point sounded like to you, though. The second paragraph was just meant to be, "Oh, by the way, maybe you could separate out parts of the vanilla game to let us enable or disable them as 'mods', and this would work as a makeshift content filter."

As for the first paragraph... Well, I'm just about to go to bed and am in no position to go into detail about it, but I'm not talking about anything weird or complicated like different people coding half a new mechanic or something. I just mean that if the dev wants to add a monster or something and doesn't feel they can write it well due to not having the relevant fetish, they could have someone else write the scene and then send it back to be edited and implemented properly with artwork and balancing consistent with the game's core style. You know, like an actual dev team. It doesn't even require mod support (it's something I meant to suggest a while back anyway), I'm just saying those tools make it easier to write and test the scene instead of just putting it in a .txt file and hoping for the best.

Edit: And again, all of this is referring to the idea of core vanilla content and NOT any actual external user-made mods. As I said before, I want absolutely nothing to do with any of that. I'm just talking about ways this mod framework could be used to aid normal, vanilla game development, as opposed to it only being a thing for modders.

 

[RandomFapinator]

I'm not sure what you're talking about, or whether you read my post correctly at all... Actually, I'm thinking maybe you read the two paragraphs as a single point instead of two separate ideas of what might be done with mods? I have no idea what the combined point sounded like to you, though. The second paragraph was just meant to be, "Oh, by the way, maybe you could separate out parts of the vanilla game to let us enable or disable them as 'mods', and this would work as a makeshift content filter."

As for the first paragraph... Well, I'm just about to go to bed and am in no position to go into detail about it, but I'm not talking about anything weird or complicated like different people coding half a new mechanic or something. I just mean that if the dev wants to add a monster or something and doesn't feel they can write it well due to not having the relevant fetish, they could have someone else write the scene and then send it back to be edited and implemented properly with artwork and balancing consistent with the game's core style. You know, like an actual dev team. It doesn't even require mod support (it's something I meant to suggest a while back anyway), I'm just saying those tools make it easier to write and test the scene instead of just putting it in a .txt file and hoping for the best.

Edit: And again, all of this is referring to the idea of core vanilla content and NOT any actual external user-made mods. As I said before, I want absolutely nothing to do with any of that. I'm just talking about ways this mod framework could be used to aid normal, vanilla game development, as opposed to it only being a thing for modders.

Yeah sometimes I have brainfarts, and what you say does make sense. I agree, interactions between modders and core developers is always good! Have a good night.

 

[NRFB]

Perhaps a way to "indirectly" show it by interacting with the knights? Like if you flirt with them and they have five different responses based on their favorability. Or maybe when you call them to your tent, there's a bit of text about how they enter (and/or exit) that gives away their mood. "Raine awkwardly steps inside your tent and looks at you expectantly. 'Um, did you need something, boss?'" "Lucette is all smiles as she enters your tent and immediately plants herself in your study chair. 'Hello, Inquisitor! You wanted to speak to me?'"

There are a couple of chats that depend on favorability and control but not too many and it's not like they're granular or anything. I also doubt that many people have ever even seen low favor chats. Your idea here isn't too bad anyway.

I wonder if it might also be a good way to work together with someone else on certain elements, rather than just entirely leave it as user-made mods? For example, you said that you didn't properly trust yourself to make egg-laying content and would leave it to someone who has that fetish, but what if instead you just left the parts you don't trust yourself with to someone you do trust with it, with them now having the tools to handle those parts, while still working to make sure it feels like a natural part of the vanilla game instead of something just tacked on by an outsider?

To some degree this seems like "modding with extra steps" but I guess thinking about it there is some sense to it. I don't think the NRFB Seal of Approval™️ means a huge amount at least in terms of balance. Not like the game is a shining example of balance anyway. There are a number of things that will be hard to reproduce in the same way as the game though. Like the art process for something like a portrait cut in itself isn't that difficult and I could make a guide for it pretty easily. The issue would more be reproducing the look of the knights themselves I suppose.

I feel like that's a lot of extra work. I am not sure the gain is worth it, more documentation might be necessary to be sure that distinct core developpers (i.e core game content and not modders) agree on the code structure and enforce ground rules to ensure interoperability of the different parts.

With how it is now, modding wouldn't result in code changes to the actual game, only changes in the content loaded in the game, which is a more broad category than you might think.
Basically if you look at that tweet where it shows a list of things that can support mods, those work because the base game already loads them all from json files internally. A mod would be just adding on to (or potentially overwriting parts of) the list of things the game loads and can use when it generates/shows things of that type, not changing how it handles them.

Interoperability between mods can be a nightmare. Mods example:
- on combat: a level up system, with rewards depending on actions (sitting on the camp gives no xp for example)
- on camp: itemization to characters with equipments?
- mods that touch the UI to interact with extra mechanics

These things wouldn't be supported or very doable just through json, for example. (Actually you could probably hack something of a level up and/or equipment system together using status effects but that's beside the point)

IWhat happens with save compability? Is everything broken when you load a mod then remove it later?

With the json... It depends. I wouldn't recommend changing mods mid-run but depending on what is in the mods it might not actually break the game.
Changing mods between runs is fine though. Should have little to no issues.

 

[Rosen King]

Changing mods between runs is fine though. Should have little to no issues.

I do wonder how it would affect things like KP progression, though... Like if you unload a mod with a new monster that you researched and got KP from, does that KP and research go away? And if you load it back up again, does the research come back or do you have to redo it? Does the research reset but the KP doesn't, allowing you to get infinite KP by unloading and reloading the mod?

 

[NRFB]

I do wonder how it would affect things like KP progression, though... Like if you unload a mod with a new monster that you researched and got KP from, does that KP and research go away? And if you load it back up again, does the research come back or do you have to redo it? Does the research reset but the KP doesn't, allowing you to get infinite KP by unloading and reloading the mod?

KP is calculated at the time you open the NG+ menu based on comparing what you have in your meta save file against what dungeon/camp events are loaded by the game. It wouldn't remove any things that aren't loaded from your meta save, just not care that they were there.
This does mean that it would be pretty trivial to make and load a mod with an event that gives you nine-gorillion KP after seeing it, but I'm accepting that as an option if you want to break progression for yourself like that I guess.
This does remind me that I need to possibly rebalance KP numbers. Also figure out more New Game+ options. You still can't buy EVERYTHING in the NG+ window with all of the KP in the game, but it isn't too far off.

 

[NRFB]

I can at least say that across the last several versions (assuming nothing has changed to cause/prevent them), I've had times where deaths both did and didn't cause crashes. So if nothing else, we can probably say it's based on circumstance and not just hardware/OS.

I think I might have this figured out? It may be a memory related issue. It turns out the way that the "shattering" animation was set up was pretty inefficient and causing a lot of orphaned nodes that weren't added to the game's scene tree, and therefore don't get cleaned up when switching between scenes (so dungeon, camp, and main menu). The crashes may have been related to that. I still haven't had a crash happen on my end, but it's possible that's just because I never ended up playing for enough time for enough stuff to pile up in memory for it to be a problem.

Regardless, I have some optimizations figured out to drastically reduce the number of orphaned nodes in memory. I've also gotten rid of the shattering animation and replaced it with a less technical animation that doesn't generate new nodes with physics, so even if that isn't the cause of such crashes, the game should be less prone to bloating memory usage during long play sessions in the next update.

 

[Rosen King]

It turns out the way that the "shattering" animation was set up was pretty inefficient and causing a lot of orphaned nodes that weren't added to the game's scene tree, and therefore don't get cleaned up when switching between scenes (so dungeon, camp, and main menu).

Is that something that only happens on death, or does it get repeatedly pre-loaded? Because I'm pretty sure I can at least confirm that this has happened in my first death of a given session, since I almost never do two full runs in a session, and few of my runs result in death. (At least before the most recent update. I've only done one run attempting to get to floor 15, and I died in that one, albeit it was a "get hit to see all the scenes" run.)

 

[RandomFapinator]

I think I might have this figured out? It may be a memory related issue. It turns out the way that the "shattering" animation was set up was pretty inefficient and causing a lot of orphaned nodes that weren't added to the game's scene tree, and therefore don't get cleaned up when switching between scenes (so dungeon, camp, and main menu). The crashes may have been related to that. I still haven't had a crash happen on my end, but it's possible that's just because I never ended up playing for enough time for enough stuff to pile up in memory for it to be a problem.

Regardless, I have some optimizations figured out to drastically reduce the number of orphaned nodes in memory. I've also gotten rid of the shattering animation and replaced it with a less technical animation that doesn't generate new nodes with physics, so even if that isn't the cause of such crashes, the game should be less prone to bloating memory usage during long play sessions in the next update.

Now that I think about it, new idea: different game over animations depending on the last corruption break. That way you might as well replace old animations by animations that consume way less (lazy ass fixing 101)
EDIT: oh wait that's exactly what you did lol I should read more carefully

 

[NRFB]

Is that something that only happens on death, or does it get repeatedly pre-loaded? Because I'm pretty sure I can at least confirm that this has happened in my first death of a given session, since I almost never do two full runs in a session, and few of my runs result in death. (At least before the most recent update. I've only done one run attempting to get to floor 15, and I died in that one, albeit it was a "get hit to see all the scenes" run.)

It gets uh... VERY repeatedly pre-loaded.
A bit technical, but basically the shards are created during the initialization of a shard emitter node, which is attached to the ally token object (the token being the little circle with the portrait that you see in the dungeon). The shard emitter creates a bunch of triangles at random which dictate how the shards break and scatter during the animation, but doesn't add those triangles to the scene tree until the animation starts. This is both better and worse than it sounds.
On the one hand, they're just 2D polygons. Not large and not computationally heavy since they're not added to the scene tree so they're dormant and not having their physics calculated every frame or anything.
BUUUUUUT
On the other hand, I've been copying the ally token node in order to create a "snapshot" of the ally's current state every time there is a dungeon event. This is in case the event's dialogue might need to know the state of the ally at the time the event took place, rather than the current state of the ally at the time you click to view the event. Duplicating the token node was also stupidly duplicating all of its child nodes, which means duplicating (among other extra stuff that doesn't need to be duplicated) the shard emitter, which means generating a new set of 2D polygon shards that sit around in memory forever FOR EVERY DUNGEON EVENT THAT HAPPENS.
I'm actually kind of surprised the game runs as well as it does considering this, but like I said the shards aren't heavy, there can just end up being A LOT of them. I don't know for sure that they're the thing causing crashes on game over, but with them being so messily implemented and only brought into the scene tree when a game over happens, it makes sense to me that they would be causing more problems than they're worth.
Obviously, I've cleaned all of this up internally.

 

[WellIGuess]

You certainly shouldn't expect this to NOT happen eventually. As I said I don't really have any mechanics for it to happen figured out/built with regard to gameplay.


On the one hand favor feels like the kind of thing that is weird to just have an easy to see numeric representation of, but then on the other hand since the number is a requirement for some things it probably should be surfaced SOMEWHERE.
I'm just not sure where.


I can give the same answer to this as I can give to someone who was asking me about a wiki:
Not that I am aware of, but if somebody else was going to set something like that up I would happily fact check any information people compiled for it.


I have no idea how much people are actually going to use modding in the first place honestly. I'm more setting it up for me, both in the sense that I can use it for small json patches post update release, and in the sense that making the game moddable is interesting and fun and something I wanted to do from the start. Expecting any huge amount of user made content is basically real life rng, so while I'll probably enjoy things that people make, I don't have any particular expectations.


One guy in my discord has decompiled the exe and regularly looks through the base game json files as well as the code without any comments (since the compiled version removes all my many many comments), and now seems to have a reasonable idea of how things work. You're probably right that other people will be able to pick it up without needing EVERYTHING explained. Looking things over while being forced to write things down like this is a good opportunity to look at what needs refactoring and such though.

Oh good, I was going to ask about how you feel about people decompiling the .exe to check 'under the hood' as it were, but I was afraid that might cause you to just encrypt everything better (at all, really)

 

[WellIGuess]

It gets uh... VERY repeatedly pre-loaded.
A bit technical, but basically the shards are created during the initialization of a shard emitter node, which is attached to the ally token object (the token being the little circle with the portrait that you see in the dungeon). The shard emitter creates a bunch of triangles at random which dictate how the shards break and scatter during the animation, but doesn't add those triangles to the scene tree until the animation starts. This is both better and worse than it sounds.
On the one hand, they're just 2D polygons. Not large and not computationally heavy since they're not added to the scene tree so they're dormant and not having their physics calculated every frame or anything.
BUUUUUUT
On the other hand, I've been copying the ally token node in order to create a "snapshot" of the ally's current state every time there is a dungeon event. This is in case the event's dialogue might need to know the state of the ally at the time the event took place, rather than the current state of the ally at the time you click to view the event. Duplicating the token node was also stupidly duplicating all of its child nodes, which means duplicating (among other extra stuff that doesn't need to be duplicated) the shard emitter, which means generating a new set of 2D polygon shards that sit around in memory forever FOR EVERY DUNGEON EVENT THAT HAPPENS.
I'm actually kind of surprised the game runs as well as it does considering this, but like I said the shards aren't heavy, there can just end up being A LOT of them. I don't know for sure that they're the thing causing crashes on game over, but with them being so messily implemented and only brought into the scene tree when a game over happens, it makes sense to me that they would be causing more problems than they're worth.
Obviously, I've cleaned all of this up internally.

Oof, that's an annoying memory leak right there, for sure.

 

[NRFB]

 

[Rosen King]

I should probably do the Tweet report before it becomes outdated, then. I've been kinda distracted, so there's a bit of a backlog.

Thiiiiiink I'm mostly done with the data/formatting changes now, though I'm pretty concerned about what kind of bugs might have been introduced while doing it. Need to do something else for a bit now before I go crazy, in any case.

So does the female version say "Mommy, mommy, and other mommy" or just "mommies"? (Also, we still need an option to view alternate gendered versions of scenes without starting a new run that discards our current specs, especially since there's no way to check what my exact portrait color numbers were to get it back to the way it was.)

You must be registered to see the links

Now what could this be? A skill scroll icon in the menu itself... My first guess is that it's for "holding" a skill somehow, but that doesn't really make sense when skills can be fully learned without much difficulty. Maybe it's a sort of class archetype thing? A special type of skill that you can only have one of at a time, and has a more significant effect.

You must be registered to see the links

...That empty space is to make room for some other upcoming feature, right? Because it's really bugging me, otherwise. Something about the meter on the left is bugging me as well... I think it's because it's on the wrong side of that line separating the UI from the picture. Though I liked it where it was on the top.

You must be registered to see the links

Slightly improved pink. "Why do that right now?" you may ask. Gosh, I sure do wonder why.

"We've captured the traitor! What do you want to do, Inquisitor?"

"Inquisit 'er? I barely know 'er! Oh wait, that's what the inquisiting is for, isn't it?"

It's probably too much too hope defeating her results in a hybrid interrogation/brainwashing/dating sim segment, but I definitely hope there's at least something. That face is begging to be turned into your pet.

You must be registered to see the links

Oof, that would probably be hella imbalanced with Exhibitionist. Especially with a build that relies on being scried a lot.

 

[NRFB]

So does the female version say "Mommy, mommy, and other mommy" or just "mommies"?

...That empty space is to make room for some other upcoming feature, right? Because it's really bugging me, otherwise. Something about the meter on the left is bugging me as well... I think it's because it's on the wrong side of that line separating the UI from the picture. Though I liked it where it was on the top.

That's where the curse box goes, but I forgot to add a curse to Raine before taking the screenshot for the tweet.
View attachment 76bb0af00c3a750d0f4864ec426cabd7.mp4

 

[Rosen King]

Quick bug report: The "perform action" button in the new trance menu can be used after waking the knight up from trance.

I'm also really not a fan of anything about the redesigned trance menu, but I'm way too tired to get into details about that now.


Speaking of which... Where exactly is the new scene? Since it's kind of the only new bit of content this update, I'd like to rush to it and then get to bed, but I don't know exactly where I should be rushing. Is it just reaching floor X or what?