Greetings! Senpai here. It has approached nearly a full month since I last wrote about the project. Now that I have stepped away from the grindstone and am taking time to look at changes thus far, I can say there has been an laudable amount done in the last 25 days!
NSFW warning: content not suitable for minors ahead (obviously).
Psst: this is a lengthy and technical one. If you just want to see images and video, jump to the bottom!
Relationship System has begun
One of my internal to-do’s for April was to begin the Relationship System, and that is what I have done. For a while, I had formulated the base idea and then refined the process with some research and back and forth to understand what might be the best mathematical representation for relationship progress.
Project FH under the hood calculates relationships and their interactions in a layered formula. First, the success of interactions is gated by each NPC’s “interest” stat. These are:
- sexInt – How interested they are sexually, gates sexual interactions.
- romanticInt – How interested they are romantically, gates romantic interactions.
- friendInt – How interested they are in being friends – you get the picture.
These three variables act as stats like Charisma or others would in a game of DnD – you roll based on the formula baselines of success (factored by other things) and these act as your “+3” to the roll essentially. The idea with these stats are to allow for playing with interactions in different ways to get to an outcome in some other way.
So we will use aunt Miyuki as our beloved example.
If her starting stats are set to relatively tame ones, such as:
- Trust = 100 / 500
- friendInt = 100 / 500
- Lust = 90 / 500
- Perversion = 90 / 500
- Relation Level = 3 / 10
- SOC_STATUS = Normal
- RELATION_TYPE = Neighbors
BUT, we set her sexInt stat to 450 out of 500, we are likely to succeed in SEXUAL interactions, as seen in the screenshots resulting from these variables:
With those stats, even though we’re not Friends, Lovers, FWB or whatever, her sexual interest in the player is almost maxed out, so using Perv skills like “Show Bra” -> “Show Boobs” even up to “Paizuri” all worked.
When we had the variables down to normal levels again, including setting sexInt to around 40 out of 500, we get an expected rejection when asking her to show her bra off:
Senpai, why allow this possibility?
Because it is a fun idea! My goal for the core design of Project FH is to have the personal interactions mimic real life a bit – people are not two-dimensional like most farm sim games make you think. You don’t just compliment a bunch and give them what they like. Sometimes, they may be sad or upset and even a gift they love might not help much. Sometimes, if you flirt enough or give them a “special item,” they may be willing to mess around even if you’re just Friends or even acquaintances.
Some may even be willing to hate-fuck if they’re angry with you. The possibilities are limited realistically, but the feeling to the player is that of control on the experience. This is the type of formula that makes interactions in games like Baldur’s Gate so fun – there are obvious points of entry, but so many other ways to achieve a result!
Other considerations for Relationships
The overall flow, anytime you interact with a character using either a Social Skill or Perv Skill/H-Action, the system calculates in a few steps:
Layer 1: interest stat checks.
This uses a lerp(minChance, maxChance, stat / 500) to calculate the success or failure. This is why if sexInt is nearly maxed out, you will almost always succeed.
Layer 2: SOC_STATUS adjustment.
SOC_STATUS is a list of the social statuses an NPC has. These are essentially how “mood” acts in a game like The Sims. Essentially, each status adds a pre-set amount of additional chance. For example, if Miyuki is currently “Horny” but her sexInt is only 120 out of 500, you add an additional nude anywhere between 20 – 30%, making it likely to succeed.
Layer 3: pass to updateRelation.
The interest check determines fail or pass of the skill. Either outcome requires that the updateRelation() function increases or decreases your overall relationProgress value with the character.
In this screenshot of the debug overlay, we see the stats and the current progression. You will notice diminishing returns with each interaction, where positive interactions stop increasing it overall after the third time – but be careful, negative ones will continue to degrade your relationship!
Concluding the Relationship System
Overall, I am happy that the foundations are here. I have a GML script that runs test cases to check the math, and currently had them hit all positives so far (but it funnily destroys the framerate when ran). This system will grow in scope surely as I proceed and things are removed and added from the master design. It’s really cool to see math gate the interactions and make this once dead NPC that was spinning out on a path act like a human!
A Better DialogueManager (for content creation)
Though DialogueManager had existed, I immediately noticed its deficiency when trying to write further JSON content to power Miyuki’s dialogue. Basically, before this dev diary, the data structure was like so:
miyuki.json
"conversations":
{
"miyuki_greet_default",
"conditions",
"priority" : 0,
"lines": [
lines
]
},
{
"miyuki_horny_initiate",
"conditions",
"priority": 0,
so onThe old version was making assertions on context strictly by the NPC KEY [“miyuki”] and the skill id [“paizuri”] and using a special function to handle openings always as greetings.
The problem with this is it was technically possible for the completely wrong dialogue to play out in any context. I realized this as I was writing the dialogue where, if Miyuki is horny and has the right entry conditions, we would offer to perform a service for you – no skill dispatch needed. However, the DialogueManager couldn’t really know about context at all here – it only knew the combination of NPC Key with Skill ID: things like greetings or special dialogue were all up in the air with little control outside of the writers having to plan each dialogue condition specifically around this design flaw.
So a refactor of DialogueManager was done which touched other systems. However, control and content creation will be MUCH easier. The new version allowed me to remove the middle-man document that mapped all dialogues for things and let all that data – along with its context – in its respective owner’s JSON file.
This includes nesting all dialogue under their actions/skills with variants:
"npc_key": "miyuki",
"display_name": "Miyuki",
"greetings": [
{
"variant_id": "horny_paizuri",
"priority": 10,
"conditions": {},
"lines": [ ]
}
so on..The new data structure starts everything with the action, such as the “greetings” you see. This means we now truly have an organized list of dialogues per pool for each NPC, supporting different variants and making it much easier to understand the context.
Here we can see the result of an alternative greeting. One in which Miyuki’s SOC_STATUS = Horny, matching the conditions of her horny_paizuri greeting:
Some other changes had to be made, as these special greetings essentially fire off an entry into the same skill-chain as if you picked “Perv -> Show Bra -> Show Boobs -> Paizuri,” but now context is passed so it can skip to where you need or control as needed. In this case, Miyuki skips the formalities and gets straight to it.
So that took a good amount of time to refactor and get working. But I am now in a place where I feel like a blocker has been removed – I can easily write in the JSON data and make dialogue for all NPCs way easier without having to juggle the conditions vs priority for all of them.
Let there be (day)light and menus!
I do this weird thing where I am working on a feature in a git branch, and once I am done with it I decide to start something else in the branch. So the alphaRelationship branch merge also includes a daylight system and the beginnings of the Menus!
Screenshots only here as I have bored you long enough with the technical talk:
Early morning
Daytime through afternoon
Evening/sun is setting
Night – late night.
This all syncs via the current hour in the obj_clockController. GUIManager draws over the screenspace with tint and hues to mimic daylight. This will expand for weather once that gets implemented later in the year.
Menus
I purchased a cute UI asset from itch.io to test out some graphical menus. It’s clunky and using junk/placeholder data, but we have something to utilize when pressing the escape key now:
Conclusion
It has been a productive month for Project FH! I am going to finish up more tweaks and small changes before taking a decent break from it in May. I am also continuing to work with the legend Neme on art assets for Miyuki right now – including a first animation for one of the H-Actions! I will be sharing that demo video on my Bluesky Account when the time comes, so you can see the true final vision of how it will “feel” interacting with the ladies in Project FH.
After the break, I plan to tackle getting the data for all items ready and implemented so we can expand the Menu system and begin the actual Farming part of the game. Once those pieces are done, I anticipate by late 2026 and early 2027 to have content made for more NPCs.
My plan is to have a very very early-alpha playable version released via some means (likely to be Patreon). This is my personal goal for the build so I can start funding this project (by that, really just funding wonderful people to contribute to it).
Like with the first dev diary, I am providing a non-committal but idealistic timeline for you to expect on this project:
June-August:
- Item and Inventory system v1 implemented
- Final tweaks to Dialogue and social systems
- Finish all dialogues for Miyuki NPC
- Finish all dialogues for Hiroshi NPC
September-October:
- Official artwork for Hiroshi (just default spring outfit with a few expressions)
- Official artwork for Mei (Hiroshi and Miyuki’s daughter, spring outfit portrait, expressions, some H-action art)
- Content: full schedule built for all of year 1 Spring for Miyuki, Hiroshi, Mei
- Farm system v1 implemented (for spring crops only)
November-December:
- Alpha main menu and settings implemented
- Finish the early-alpha playable prototype maps (includes: Farm map, Furukawa House Map, Player House Interior, Mori Shop Interior, Furukawa House Interior)
- Finish the Tutorial Quests and implement QuestManager
January-February of 2027:
- Release the first ever playable prototype. This will include:
- Year 1 Spring ONLY
- Only three NPCs: Hiroshi, Miyuki, and Mei Furukawa
- Only the exterior and interior maps for the Farm Land and the Furukawa House map
- The first iteration of the final game’s tutorial and opening scene (SceneManager put to work!)
- Expected interactions you can do:
- Miyuki:
- All social interaction variants
- Show Bra -> Show Boobs -> Paizuri
- Show Panties -> Show Ass -> Buttjob* (if funding allows)
- Mei:
- All social interaction variants
- Show Bra -> Show Boobs
- Show Panties -> Show Ass
- Hiroshi:
- All normal social interactions
- Special interaction if he is nearby when performing a Perv skill with Miyuki
- Miyuki:
This prototype build is the current end-goal to serve as a proof of concept and get people interested/hyped about the game! I need to establish it in a way where I can fundraise somehow, as the art assets needed for the final full game (which would take a couple of years to reach) is non-negotiable for me.
Media
That’s all for now!
Peace peace ~
