Hello everyone~! I have a new dev diary update to share on my hmSpirit project.

I have been pounding away at prototyping on this and am finally back with a new post to share the progress made so far! I have a decent bit of tech-facing things to discuss in this dev diary so strap in.

While it definitely doesn’t look like much, I have made several big implementations since the last time. In dev diary #1, the footage and progress thus far only included a lot of beginner troubleshooting and getting collision rigged up. The next step for the programming front included wiring basic AI movement, which was a lot of trial and error (and to be honest, it’s still kinda buggy).

Following the AI Controller was the introduction of the Scheduler constructor – a struct that will allow NPCs to register their instance and a pre-defined key-value pair (dictionary style) array to tell the NPC what to do. Right now, it is straight forward and hard-coded into each NPC object, and essentially tells the NPC “at this time, either follow this path or wander around.”

Actually, I am getting a head of myself – I added a pretty simple clock system too. This may get more robust, but for now it’s a persistent object called in by my GameInstance object to have a sort of time system for the game.

_accumulator += delta_time / 100000;

if (_accumulator >= seconds_per_min / time_scale) {
    
    _accumulator = 0;
    minute++;
    
    if (minute >= 60) {
        minute = 0;
        hour++;
    }
    
    if (hour >= 24) {
        hour = 0;
        day++;
    }
    
    if (day > 28) {
        day = 1;
        
        //We count seasons from 0 to 3, cannot go over 3
        if (season == 3) {
            season = 0;
        }
        else {
            season++;
        }
    }
}

This is the only calculation running per step for the clock – here we simply accumulate time based on Gamemaker’s delta time into milliseconds.

Simple, right?

Anyways, we’re back to the Scheduler. The struct utilizes these variables:

    entry_builder = _entry_builder;
    entries = [];          
    current_index = -1;
    active_task = noone;
    next_index = 0;
    last_day = -1;    

Every NPC builds out a schedule that is currently hard-coded in their Create code:

schedule = new Scheduler(function(season) {
    return [
    { hour: 6, minute: 50, type: "path", value: path_npc_1 },
    { hour: 9, minute: 0, type: "path", value: test_2 },
    { hour: 10, minute: 0, type: "wander"}
    ];
});

The current implementation allows to pass in a path string to tell the AI Controller’s poll_schedule function if we are following a path or simple wandering around. My brain is drained right now, but I am sure we will expand on the capabilities later.

Today’s work achieved laying out the foundations for the InteractionManager and DialogueManager structures. Having not been exposed to other farming sim game’s codebases, I was making a guess that the best approach to separate concerns here was that we needed a manager to poll and register things that could be interacted with. Basically, a system that checks each Step for things the Player can press “E” on. That’s pretty much it – this will then callback to the appropriate manager to handle further processing. In this case, the DialogueManager’s functionality gets called from the NPC’s interaction object:

interaction = new Interactable(id, INTERACTION_TYPE.NPC, "Miyuki", function(_player) {
    global.DIALOGUE.start("miyuki", _player, interaction);
    return "dialogue: miyuki";
});
global.INTERACTION.register(interaction);

This implementation session was rather educational, because it helped me discover the use of Included Files in Gamemaker. This is important because I want to be proactive and have the dialogue of the game ready for localization and prevent hard-coding text.

As such, my current approach is a three-tiered approach of using JSON in the /datafiles folder of the project.

Basically, the system is nothing special and typical of a localization-supported language in a program:

• One file with all the strings matching by key for each language (string_en.json)
• One file for each dialogue per NPC, that references the language’s matching key, no actual text inside
• A JSON file to match the condition sets. In this case, dialogue_index.json is what puts it all together.

These are loaded in at the start of the program and persist in memory to prevent re-opening these files and ingesting the data. I think this would be the approach for memory-management, but I am sure there will be some roadblocks once we have a bunch of dialogue in there. Oh well~~

That’s the grossly simplified over and under of the programming work done so far on the project that leads you to the video posted at the start of this dev diary. I am very happy with the foundations I have laid out, and they’re stubbed for more features but there’s definitely a lot more work to do to make them less buggy and feel more like a professional release. All’s that to say: even though it appears like the standards, this is a good bit of work and the workspace of the project is showing that growth:

I am of course keeping a running documentation library in my drafft-2 instance, as adding any new character or interactable requires understanding some of the code base that exist. Once I get these current features ironed out nicely, I will tackle prototyping the actual farming system. I wanted to focus on interactions and the dialogue first because this game will heavily rely on these parts to progress.

Anything on the Creative front?

YES!

I have made more progress on the master GDD, finally tackling the list of characters to be made. Of course, as the game goes into true pre-production and a team is assembled, these things may change, but making a list of characters and their basic personality and appearance has been something I have been stuck on since December.

Much like anything in life, I just had to man-up and sit down and start writing anything to get this done – and I did. I am currently happy with the list of characters I have come up with, and some of them even inspired some possible side quests and features to think about!

Not counting the Player, there are 18 planned NPC’s – 10 of which are currently planned to get at least intimate with 😉

I realize writing this out it seems lofty, but again – this is subject to change. Once I get in the actual flow of a production, this can drastically get slimmed down or maybe even go up! Only time will tell…

Thanks for checking this post out. If you’re interested, you can bookmark this blog for more updates or follow me on itch.io:

https://zero-senpai98.itch.io

I am cross-posting these updates there as well.

I think in the next coming months, I will considering looking at some communities to see if there are any individuals looking to collaborate on a project like this.

Peace peace~