Untitled Game Devlog

[beagleshark]

Hiya.

Just wanted somewhere to post progress and other bits and pieces for the game I'm working on. I have a vague idea of where I want to take the game so at the moment a lot of the work is on mechanics and features.

At the same time I'm using this project as a way to learn Godot. I've played with other engines in the past and whilst I don't have a game dev background I am a full time software engineer.

Initially I worked to get a grid based movement system in place as well as a way to transition between exterior scenes so I could build out a world of smaller scenes.



I put a fair bit of time fleshing out a good state machine so I could manage all the different states that both players and NPCs would have. I'm still working on a way to "control" characters so I can script out cutscenes or small events, but am also playing around with some other ideas on how I could achieve that.

Most recently I made use of Godot's built in A* Grid2D class to flesh out a "patrolling" (or wandering) state for some NPCs. This allows me to configure some patrol locations and have them navigate between them whilst avoiding blocked tiles from the map, the player, or possibly other NPCs who are also patrolling.



I then expanded upon this state by having them transition to a "looking around" state for a period of time before continuing to patrol.



This will hopefully help to make the world feel more alive rather than have a large amount of stationary NPCs or even trainers.

I've begun working on the "detection" mechanic so NPCs are able to detect players. Currently I am using a raycast to do the detection, however, I want to play around with a wider cone, so even if you were a tile away from their direct line of sight you could still be "seen". I think with the patrolling NPCs that could make for some interesting route navigation if attempting to avoid a battle.

My goal is to continue to update this thread with further screenshots and/or videos as well as some insight into what I've been working on. If you have any questions please feel free to ask.

(You may notice I've messed around with the tiles and sprites a bit. I've been tinkering with the autotiling and tilemaps in Godot so it's changed a little as I play with things.)

 

[beagleshark]

Today I have been experimenting with player detection.

I'm interested in expanding upon the way NPCs can detect the player by not having it rely on the player crossing directly in front of the trainer. Instead I want NPCs to be able to have at least some sort of peripheral vision.

After getting something working I discovered I'd need a way for characters to have broken line of sight if, for example, the player were to be behind an obstruction like a rock or tree.



The videos above show some of the ways it can work as well as how the size of the detection area can be adjusted. Due to the way the detections occur even as the player leaves the detection area they are visible to the NPC until they reach their target tile. I'm still fine tuning some of it but I'm relatively happy with how it's behaving as a way of detecting a player.

I'm also toying around with some other ideas on how a player may further evade detection.

 

[beagleshark]

The last few days I've not had a whole lot of time but I have made some more progress on player detection and fleshing out a battle initiation flow where the trainer can compute the cost of each tile surrounding the player and determine the best one to navigate to. This should hopefully always result in the trainer taking the shortest path to the player.

It also works while the trainer is on patrol where if they detect you they'll stop you and engage you in battle. I haven't begun working on anything related to battles as yet as there's a few other easier wins I'd like to tackle before I look into battling. I'd also like to implement some of the foundations for tracking Pokemon related data.

I'm mostly happy with where this system has landed so I'll likely leave it where it is for now and move on to other things.

The next thing I want to look at is transitioning to interior scenes before looking at some UI.

 

[beagleshark]

Well I said I was going to move on to other things but I had an idea on how to make the detection a bit more interesting.

Rather than trainers detecting the player as soon as they enter their detection area I've implemented a "curiosity" indicator which provides a grace period to player. When enter into the trainers peripheral area a grace period timer will start and an indicator will show that the trainer is curious but not ready to battle.

This gives the player a bit of time to either move away from the trainer or hide behind something so the trainer can no longer "see" them.

If the player walks (or runs, I also added running) directly through the trainers line of sight they will immediately be alerted.

This also works when the trainer is on patrol.

There's a couple small kinks I need to iron out but I much prefer this rather than the immediate detection that I had perviously even when you weren't in direct line of sight.

Maybe now I can move on to some other things!

Spoiler: I also had a few bugs!

 

[beagleshark]

Hello it's been a few days since my last update.

The time I've had in the past few days to work on the game has been spent working on exterior to interior transitions, as well as a nice way to set them up. Because I already had some scene transition logic I was able to re-use the scene change areas, however, I needed to come up with a way to trigger the action of entering a door.

Pokemon games typically handle this by walking at a door and automatically entering. I decided to take a different approach and instead prompt the character that they can "interact" with the door.

I already had a basic component to handle interactions so I expanded upon it and added some door interactables.

I also added the ability to take in game screenshots.

Upon interacting with the door the player can enter the building. Here's a video showing the transition from the exterior scene to the interior scene (no screen transitions as yet, but that should be trivial to add later on).

My goal with doors was to try to make it as easy as possible to add the transition logic as well as the door animations. I am using some slightly tweaked versions of the doors from this resource pack which I've then made a tool in Godot to handle changing the door style and state.

I only have two doors at the moment so I could test it out. Being able to set it's state as opened or closed is used by the scene transitioning logic when exiting a house.

Finally, I had been planning to build out a system that would allow me to queue up a bunch of actions for my character (or literally any NPC really) to act out, such as "walk 5 tiles to the right, wait for 3 seconds, then turn to the left". The end result (so far) is something I call my sequence director. It takes a sequence of predefined actions, each with their own options, and plays them out, sequentially.

Here's an example of how I can set up some actions and pass them to my sequence director to handle.

In this clip you can see the sequence to be played out is a bunch of turns followed by walking. When the game runs I simply press "space" to watch the sequence play out.

The nice thing about this system is I also have a sequence action for navigating which makes use of the A* grid for computing the lowest cost path to a given position or tile. For many scripted events it will be easier to simply use this to tell my characters where they need to be and let them find the best path, especially if there's other NPCs in the area that may be walking around themselves as the navigating logic will correct itself if they become obstructed while navigating to their target tile.

All in all a fairly productive couple of days. I'm hoping during the next week I'll be able to start looking at some UI before hopefully tackling some of the battling systems.