Protobound Day 3

So I am working on the NPC wandering AI. There are a lot of ways I can do this and it's proven overwhelming. You'd think it would be simple. Tell the npc to walk to a destination within range. The problem is some of the ways would be a bastard to the CPU. I don't want to be running checks every physics loop if I can avoid it.

One idea is to have the npc object spawn an object in world space, reparent it to it's parent and walk to it, upon hitting it stopping and having the object queue_free, then start a timer, wait a few seconds and do it again. I would have to construct the object with it's positional data in rand_range +/- 100 or whatever pixels of npc spawn point.

Another idea is to wrap the NPC in an area 2D and have the area 2D signal whenever the NPC has left it. Then based on the heading, spin the NPC around and walk it back to it's spawn point.

I think I prefer the former to the later as it has less edge cases(that I can think of, still waiting on the tea to kick in) and is probably easier to execute. Well, let's see if that's true.

Now she wont get lost in the void. I just need to make sure NPCs do not collide with eachother, they can't hit eachother's destinations as I had tought that might be an issue.

There is a potential bug where the npc could generate a destination out of reach or inside of a collision. I figure a timer should work. If the npc does not reach the destination in X time have the destination destroy itself and emit a signal that the npc could be listening for. Of course, since the destination already tracks the creator's name it could emit the signal with that name as an arguement so that other npcs wont suddenly stop and bug out.

Instead of signals I used get_tree().call_group() and passed the name of the NPC that created the destination node. Seemed a better solution at the time. Not sure yet.

Seems to be working, as far as I can tell. I left her to wander for a while, she did end up stuck on a wall a couple times but she did correct after the timer ran out on the destination. I could improve it with a raycast in front of the NPC that checks collision and resets to a new destination not in that direction, but I don't see the point for such a simple game prototype and I got other crap to do.

Issue closed.

On to Conversations(Dialogue). Initially I considered using a JSON based system, though this seemed quite a bit much. There wont be many NPCs per map, for one. These NPCs for the most part wont have much to say, for two and the ones that do will use a cutscene. Cutscenes will be loaded on demand and be more complicated than dialogue as a rule.

Well, not hard-coded, per-se. I will have the script for the npc's conversation be loaded whenever the player interacts with the NPC. I do not know how garbage collection works for Godot but I believe it should clear once out of scope, right? So when the conversation ends the script would be unloaded, yeah? I hope.

First step was to get the ray to sync to the current direction of the player. Since I have a state machine that knows the player direction and emits a signal on every state change all I had to do was have that signal emit to the ray itself as well, then match on the direction and set the cast_to based on it.

Now we need to be able to see what that ray is hitting. I think this will do the trick.

Always remember to enable your rays. I think I could save some resources by only enabling it for a second when the player presses the interact button but let's just make it work first.

The npc's enter_conversation is called and passed the player's data(so that it can read the player's flags, address them by name, join the party, etc. I think this is passed by reference but am unsure.).

I do need to increase the collider size for the npc and probably make it a rectangle.

Now I have to figure out the next problem, our friend Mr. UI. He's a right bastard, him. I'll need a hammer.

So the way I have done dialogue in the past is having buttons that correspond to functions and those functions manipulate the state of the window. Of course I have only done dialogue for the MMO project which involved the server sending over the dialogue as state and the client reacting to it, then based on the button pressed sinding a RPC to the server and then getting an update from the server.

I will be trying to keep this as simple as I can. Two buttons and a text display. The npc will set the text display and one button will change state, the other button will be "Goodbye" which will set the game state back to exploring and close the UI (queue_free(), maybe?).

So the flow would be:

Player interacts with NPC -> Npc loads dialogue UI, sends over it's conversation script to the UI -> UI parses conversation script and populates the text and buttons. -> User selects option(button) -> UI runs appropriate function for option and either ends conversation or changes state of the UI itself.

I actually don't need to worry about the conversation script. If it becomes a problem I will rewrite it later. For now I will just have a direct communication between the NPC and the UI. Why make this more complex than it needs to be? I really have a problem. I really end up overengineering systems a lot. That's why I have a tight schedule on this project, to prevent this behaviour and perhaps correct it.

Alright, simplifying the conversation system knowing I only have today to finish it has lead to a rather spartan system but that's why we have the cutscene system planned.

The first button checks if the text inside it ends with certain key words like "Bye." or "Bye then." and calls the goodbye() function and sets state back to exploring and hides the UI.

I think I will add another label at the top for the NPC name.

Slight redesign happened, using a dict to allow up to five pages now. I can see ways to further improve it but I would rather just make it work and close the issue so I can pull ahead of schedule and perhaps allow myself some time to work on my 3D printer.

Huh, I expected that to break somehow. Welp, that's conversations. It could use some prettying up, but hey, that's not in the scope of this prototype.

I also added a hook to the conversations for recruiting party members, also can read player flags and alter the conversation dialogue. I believe that's all I had for required features all nice and ticked.

Issue closed.

All that's left for the week is the party system. I have already set up some scaffolding for it as I built the other systems so it should be pretty simple. I think the hardest part will be deciding what makes up a party member. Of course Stats and Equipment will be something I have to sort out next week.

Next week will be mostly revolving around the combat system, which will look kinda like a mix between Earthbound and Dragon Quest. With a window appearing over the gameplay world showing a dialogue box that describes what is going on, probably a shader-based background and some UI elements to show party status and available actions. Turn order probably being decided by a speed stat. As for the Earthbound damage system... I do want to implement it and have the health tick down so you can take fatal damage and heal out of it if you are quick, though that depends on how much trouble I have implementing the basic systems first.

Well, I think I will make my commit and go try to get my 3D printer to behave. It's 4:12pm now and I will be having to cook some dinner shortly so better take what time I got, here.

Cheers.