Author: Jake Brunton

Hello! It has been a solid two months since I posted my last dev diary on this project. A lot of that is mostly to do with me taking some time off before immediately getting caught up in a week-long work trip, followed by a brief illness. However, while the work on the project has been at highs and lows in this period, I have been striking the iron!

There has been a bunch of minor changes including bug fixes and tweaks, alongside some more major systems additions that will help me get to a first technical prototype for the itch.io page.

Handling Spawns and Room Transitions and Persistence

The first system implementation is the handling of a SpawnManager. At this point, GM2 runs as my graphics engine and compiler as I have found myself essentially wiring up systems one-by-one to craft the project in the way I want to handle it. Because object instances destroy when you leave a Room and re-create in another, the first few updates in May involved tackling this problem. The Character class originally provided logic for collision, but it now maintains the persistent data and relationships for all NPCs (alongside collision logic). Alongside that, it connects each character to the Actions system (explained later here).

So now, characters register on instance create to the Character registry. Essentially, anytime you enter a new room or an instance of an NPC needs to show up, it can grab all of its relevant information that persists from the registry and its control from the Character and AI classes – we have data persistence without the bottleneck of GM2’s object instances.

This also applies back to Spawning – by default, object instances load to the point in the map editor you drag them, and we must have an instance dragged in for each character. To ensure the Player and NPCs always obey the logical spawn points for maps, I set up a brief SpawnManager that reads from a script of set spawn points to override their placement.

Farming and Actions

This is the first major update to note from the last two months! The basis for the Farming system has begun and we can till soil, plant seeds, water, and have the crops grow day by day and eventually harvest the crop into our inventory. The basic functions all exist:

For my testing, I can give myself two rusted hoes, a rusted can, and a HOE OF PASSION (the colorful one). This showcases the charge-up of tools like the Hoes and the progress of crop to be harvested. It’s all expected for this type of game, but I am stoked to have this system wired up to this extent!

This surprisingly took the most time in figuring out how to fire animations and information via an input. I wrote out an ActionsManager to handle different action inputs for all the tool types. My inspiration comes from most Farm Sims, where a cursor highlights the interactable objects for the tool you have. The tricky part was the field. I am essentially working with 16×16, 16×32 and 32×32 assets – so there was a lot of fluff to figure out, but essentially the main GM2 grid runs on 16×16, and thus the cursor system uses built-in functions to draw itself in zones I preset in the map editor for the fields.

It was a bit weird to position, but I decided to have the character snap to the adjacent center position of the cursor (which you can see in the video). This provides a better visual and I feel also helps make the process of till -> plant -> water feel much easier to control.

Fields are going to be preset areas on your Farm only. Given the scope of the game, I felt it not necessary to have complete reign on placing field plots as needed, mostly because I need to ensure consistency when wiring the Scenes up for quests and tutorials, but I also want to leave real estate on the farm for future mechanics…

Mapping out the Furukawa Residence

This was surprisingly a pain-staking task as well. To reach my goal of a technical prototype and then playable alpha prototype by next year, I wanted to start level design for some of the other places that would be available. Essentially, the Furukawa’s residence, which includes the large outside map, the inside of their house, (both of which I completed this cycle), the interior shop and Mei’s room (above the shop).

This map took a few hours and is based on the concept art I drew out by hand:

I have decided to patron the Kokoro Reflections tilesets. They were really kind in answering my questions and I am happy with their products so far. Importing their tilesets lead me down a path of learning about Gamemaker 2’s texture atlas and auto-scaling. I now understand the use of the texture page sizing as I spent some time trying to figure out why their tilesets specifically (the ground tiles specifically) were being stretched and ruined in run-time. It was because the source they provide for their non-RPGMaker files are massive in dimensions, and the base texture page of GM2 wasn’t able to handle that appropriately.

So, I had to do some changes to the memory config and I decided to load up all the NPC sprites and animations into their own group as well to help ease some load times during game play.

The inside of the house so far. The lines you see are the IDE showing the paths I have in the map. This leads into my next subject.

NPC Schedule Persistence

I had talked about the Scheduler system in an older post, but it was time to update it. Similar to the problem with Object Instances and data, I needed to make some tweaks to have the Schedule system seem persistent. In many of these games, all NPCs run on schedules: these are paths to follow, places to be at at X time, and so on all dependent on the day of the week, the season, the event, or other conditions.

I am an extreme visual learner and thinker, with logic coming in second place. So with some back and forth, the current solution I found is to piece together the schedules on a room load and then send that information to the instance of an NPC so they can find out where they roughly should be for the current game time. This works great if you have static placements for characters, but I currently have functions for them to follow paths, leave rooms, and wander around.

The SpawnManager helps with the “leaving rooms.” Instances remain with collision even if you hide them, which means I had to add a helper function that essentially moves NPCs that are “gone” from the map to a -9999 y point, and then draw them back to where they belong when needed.

Paths are the interesting dilemma I had here. By default they work, but the problem is continuity. I found that if I entered the house, Miyuki would start her path, but if I exited and re-entered, she would re-start the path from the beginning. This makes sense, because the function Scheduler sends to the AIController was to simply follow the path asset. To fix this for now, I added some logic to these systems that reads the number of nodes on the path asset, and based on the time start of the path task and the start of the next task, we approximate which node they should be starting from on room create.

For a path with many nodes like in the house, this works relatively well, but for a simpler path, it’s not quite there. I am thinking on if there may be a way to mathematically get the total number of in-game seconds each travel will take and more accurately start the points that way…

Sound!

What’s an H-game (or any game) without sounds? The big piece of the last two weeks was implementing SoundManager and getting audio assets imported in for BGMs and SFX. I have these load into memory similar to all Sprites in which we load their asset groups on GameInstance create so they’re ready to play. I wanted to future proof for the Options system – hence the need of audio groups to control gain on each one – and level design, so me (and maybe future team members?) can easily override based on certain maps to play specific tracks.

There is an “overworld”, “custom”, and “silent” mode setting that you can use per map. I am designing an audio group to manage all background music tracks, all sound effects, one specifically for H-content sounds, and a placeholder for voice acting (if that ever happens).

Current state of the prototype (VIDEO):

There were a lot of small tweaks as well, and I still have dialogue writing and item wiring to go through. I’d like to release a technical prototype build on the new itch.io page by August for some initial interest building and bug reporting to help me make a more polished, playable prototype by next year!

See y’all later and peace~

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 on

The 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

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 ~