Relee Squirrel

1:56am - Well it's late and I have work tomorrow but I'm not sleepy in the slightest so I might as well squeeze in a bit more work.

Last time, I made the PlayerAICore. I could make a BasicMonsterAICore now, but I think I'll skip that for now. I have a lot of other modifications on the TODO list for my GreenEnemy already, and I shouldn't need monsters in the world to test the basic movement of the player I'm implementing.

So! Let's remove the monsters for now...

There's been a longstanding error warning since I took the actor_list out of Level and put it into GameMap, so I should fix that. It's in the restart algorithm, and it should be moved to GameMap, for when the GameMap is restarted.

2:19am - I just eliminated more than half the code in the Level.gd class. The _input() function is gone, the input moved to the player actors for now. Later I'll have to include some for handling the GUI, but it's good for now.

GameMap is fricking huge now though. LOL I moved so much of the code from Level to GameMap and ended up with a longer GameMap class. Well, it works. The Level class just holds the Turn pump and restart method now, and I'm planning to add the Action pump next while refactoring the old Turn pump.

I think once I get the turn pump and action pump working, I should be able to test the game again. I wonder if it'll work after this overhaul?

2:26am - I've run into a snag. The Turn Pump was using the on_turn() method of the Actor to reduce the action_points directly. Now I want it to do a think() first, and reduce action_points based on doing Actions. Is there anything for on_turn() to do anymore?

Well, it'll be where the think() comes in, since an Actor begins its turn by thinking, but then what? It's not going to return action_points spent anymore, now it's just passing the Action Array from the AICore down to the Level. Why not go straight to the source? Hmm... I get the feeling this extra level of seperation will be important later, but I can't put my finger on why. So I'll leave it for now.



3:22am - I've finished it up and corrected lots of little errors and changed lots and lots of things and it should work now but there's a very strange problem. It's unable to load one of my scripts, and I can't figure out why...

It's very puzzling. The error says that I should make sure resources have been imported by opening the project in the editor at least once, and I have done that a few times. Sometimes reloading the editor fixes bugs like that. But it's persisting...

I'll try asking on the Godot Discord.

3:30am - Ahh, while I was typing it into the Godot Discord to ask, I realized that it was searching for it in the wrong place, and so I started opening every class to see what looked for it there, and I solved that problem.

Now there's no errors, but it doesn't work. Seems to be stuck in an infinite loop...

4:20am - Had to do a bunch of remodeling of the Turn and Action pumps. It looks like I really do need to seperate out the player controlled characters, since otherwise they'd be blocking, and if they weren't, then only one actor would run per frame.

4:55am - I've stayed up way way way too late but I did it. I can move around the player on the map again. There's some unexpected behavior where the player can move diagonally without holding a modifier key, but I should be able to fix that next time.

Then I'll overhaul the enemies, and add them back in, and I'll be back to where I started, but with a better foundation. <3

1:54am - So my TTRPG game was postponed this week since one of my friends and players had family problems. That led to the night ending relatively early, but I'm still up and active. It's hot and my computer's having troubles dealing with the heat and playing video games without locking up, I still don't know if that's really the problem but it seems like a lot of coincidences so far. ^.^;;

Anyways I was saying earlier that the next thing I want to do is the AI scripting.

The idea is to have plug-in scripts for the AIs. That way, I can put in a PlayerAICore that takes its commands from the input and puts them in command stacks, and a BasicMonsterAICore that generates command stacks and returns them... And I can make more as needed. There'll be AIs for all the actor types. But I still need to figure out how they'll work logically. I've got a pretty general idea and I don't think it'll be a problem, but I want to make sure I do it right.

So! In order to be a pluginable AI script, there needs to be a base class for each of the AI scripts to inherit from, thus making them interchangable. The most basic thing the base class needs is a method that all the kids will overload, which returns an Array of commands.

Should it be called think() or get_commands() or what? I'm not sure.

The other thing I'm thinking about, should it directly access the Actor it's connected to's properties, or should it be passed a bundle of info? I know I was thinking of having the AI take a sort of SenseMap from the GameMap that showed what it could see. But I don't have something like that implemented yet. Well, maybe I could make a basic one pretty quick by just giving it a rectangle or square mini map version... Anyways I'm not entirely sure there.

The point is that the AI needs to analyze things outside of it.

I think that means I should pass it the Map that the AI haver is on, at the very least. And maybe a reference to itself as well. That way it'd have access to all the properties of the AI haver...

So it might be like, aicore.think(self, map) and that returns an array of Actions.

I think that's all it would need. Now let's go inside and see how it works...

In the case of the BasicMonsterAICore I think it would start by analyzing the Map to choose its action.

If an enemy is in sense range, attack or move towards them. If an enemy is not in sense range, random wander or idle.

In the first case, it returns a melee_attack or move action in an array.
In the second case, it returns a random move action or an idle action.


And now it occurs to me that these actions are going to have to have an action point cost as well, since that was how the energy system works. I'll have to figure that out as well.

Hmm... I suppose when the Actor runs its action methods, they'll have to include action point decreases.


Alright, that all makes sense. Now what about the PlayerAICore? It's not too hard to change where the input source is for the Monster AI, but the Player's input comes from a whole other system.

Hmm... Part of the reason I'm doing this is to open the game up for the potential of controlling more than one character in the game, so I should reconsider how input is handled.

I'm not really fond of the way the input works right now so I'll probably end up changing it too. It was kind of a kludge.

So let's see. There's a few ways I could make it work, but what's best? I want it to be reactive, but not do the wrong thing. Ideally the player should be able to hold down a movement key to move on subsequent turns. They can do that in the working version I had before, but I don't think that will work with the new Action system, and the AICore system.

Basically when the PlayerAICore gets its think() function run, it should wait for input, unless there's one already waiting, and there should be a delay on how fast it can take a new input. I've already got a Timer for the input like that, it shouldn't be hard to connect. Basically the tricky bit will be looping without locking the program while waiting for input.

I think this part I really need to look at the code for, but it's getting really late and my friends are chatting again, so I might stop here for the night.

3:03am - I think I've got some good ideas in here so far. I should be able to implement something next time.

12:43pm - Well, I've got an hour and 15 minutes before work, I've had a nice breakfast and prepared a salad for lunch for later, I could either get back into bed and nap for an hour or work on my game.

I'm in a good mood so I'm going to work on my game.

Previouciously on Work Post, I figured out that I needed to make a series of methods in my Actor base class to line up with a series of Action classes I'll make later. They're kinda tied together, coupled we say, but I don't know a way to uncouple them any further and still get the functionality I want, so there we go.

In my Actor class I have a few 'action' functions already from the previous version. attack_actor, attack_for, and move_actor, which I'll have to change or remove. They were direct call methods instead of the command-called method type I'm aiming for.

I think I'll keep the _actor suffix though because all these methods are about actor interactions, and it'll help differentiate a move_actor from things like moving the object.

1:26pm - Okay I've put the stub functions into Actor.

Next I need to make the Action class and its children, one for each action function. Then I make the action function overrides on the Actor subclasses, and then after that, well, let's not get ahead of ourselves.

For now I've set two alarms and I'm going to lay down for about 20 minutes before work. Wish me luck!

2:02am - Well I spent most of the day in bed napping or just beating the heat, and now it's night and I have to do _something_ right? So I'm going to work on my programming projects, specifically the Roguelike Project.

2:29am - I went to the online book Game Programming Patterns to refresh myself on the Command Pattern and I noticed something was off; the thing I'm doing is subtly different.

The command pattern is somewhat tied to the type of actor it's acting on. That is to say, all the actors that can recieve commands must contain the execution code for every command.

I was hoping to seperate the actors from the execution code, but it occurs to me now that it doesn't make sense. Even the way I was going to do it, it would only work on Actors that had the right properties.

I was thinking I'd make Commands that modified the state of Actors directly, but the Command pattern described in Game Programming Patterns runs a method of the Actor class.

Implementing every possible action an actor can take in a single Actor class, and possibly overriding some of those in subclasses, would make for a very lengthy Actor class!

On the other hand, decoupling the things an actor can do from that actor would make it confusing, what could the actor do? You'd have to go down all the commands and figure it out.

2:34am - Let's put this on hold for a bit and try something else. How many things do Actors need to do?

Well for starts there's the steering behaviors. They work a little different in turn based games but they're still relevant.

Seek, Flee, Arrive, Wander, Pursue, and Evade. I know what those mean, so I won't go into detail, but if you're curious do a search for ai steering behaviors.

Those will do movement, and they're pretty generic. Speaking of Generic, what about "Use"? The Use function on Actor could be blank, and overridden on any 'item' Actors that can be used. Then I can program unique behaviors in the class for each item. Could I then import those unique behaviors from a text file along with the stats for Actors? Hmm...

Maybe, if I load in a list of submethods to call when "Use" is run?

Like in the textfile it would be something like

OnUse: "Heal" "Self" "5"

And that would be a healing potion that heals five hp? But what about something more obtuse, like a wand of fireballs maybe?

OnUse: "Shoot" "Target" "AoE" "3" "Fire" "5"

That would run a shoot function that lets you choose a target, and then at that target it makes an AoE of radius 3 that does 5 Fire damage?

I think I could do that for the player's use okay, but what about a Monster or NPC? It would be hard for them to understand what that was in AI. Maybe if the info in the file also included type, it would work. Like, Food and Potion would be different, but similar, and Wand might be another type.

It does seem pretty overcomplicated for this stage of development, though.

Maybe I will stick to hard coding the Actors for now, instead of putting them in a file.

3:00am - Time is fleeting, but I'm not done yet.

So, I've got the steering behaviors and a generic Use method, what else... Probably some kind of Attack, right? Unarmed Actors can attack, armed Actors can attack, weapon Actors can be attacked with... But what about Ranged attacks? Maybe when an Actor is commanded to Attack, it checks if it's holding something, and compares their stats, then uses the best attack available. If that's the item, it runs the attack command of that item instead of its own? Or do item and weapon Actors never get the Attack command used on them?

I think it should be something like, ranged_attack and melee_attack since they operate differently, and it'll be up to the AI which attack to use. Ahh, I thought of something. What if an Actor is holding a non-item, non-weapon actor? It should still get its turn and be able to attack independantly. So yeah, the attack methods of items and weapons will likely be blank.

Steering Behaviors, Use, Melee Attack, Ranged Attack.

Idle. That's a pretty important behavior too. Use time but do nothing.

Move. Yeah the steering behaviors are more for AI, telling you where to move to, so there should be a generic Move action.

3:20am - That can't be all of them but I'm having trouble thinking of more. o.o;;

Use is a real heavy lifter, especially since I don't intend anything in the game to have more than one functional purpose.

There are a couple other Actor types besides Player, NPC, Monster, Item and Weapon though. I wonder if Weapon is an Item? Anyways the others are Effect, Door and Container.

Effects are things like a wall of blazing fire or a teleporter or a magical spell in the course of operation. That sort of thing. They have a location and behaviors just like the other Actors.

Doors are artificial terrain. They switch between open and shut when used. But I'm not sure that's a "Use" case because they aren't in your inventory.

Containers are things like chests that contain items and are open or shut like a door, but that you can't put in your inventory.

Some items are 'containers' in that other actors can be put inside them. Probably all Actors will have a 'contains' or 'inventory' array that has all of the actors inside of it, but not all of them will be able to contain other Actors. You might find a Bone-in Ham in a Chest but you wouldn't put a sword in your Bone-in Ham. Well, not in game anyways.

So, there's also of course things you can't put into a container because it's too big or it just violates the game rules. Like, you can't pick up a chest and you can't put it in your inventory and you can't carry it with you and keep stuff in it. You can pick up a monster but you can't put it in your inventory. I think the player will have a seperate 'hold' inventory for things in their hands that they can pick up but not put in their pocket or whatever. So will other Actors. Or maybe Hold and Wield are synonymous? Anyways that's for later. Right now I'm trying to come up with generic actions.

Maybe you CAN use items that aren't in your inventory, that would work for doors and chests. But what about locks? I could easily make it so that if you have the key, you unlock the door, but what about closing and relocking it? Maybe that's not allowed in gameplay but it doesn't make a lot of sense. :P

At least you can close it again. Maybe it WILL automatically lock if you close it while holding the key? Hmm. I digress again.

So Use saves the day again, but this talk has revealed other things.

Move, Idle, Use, Melee Attack, Ranged Attack

Pick Up, Drop, Wield, Contain, Remove

We've suddenly doubled our actions.

3:40am - I can scarcely believe I've gone another Work Post doing nothing but research and planning, but here we are. I think I need to go to bed now, I have work tomorrow. I'll keep trying to think of other Actions that Actors can take while I rest.

Feel free to suggest some!

2:47am - Well, it's past my bedtime, and I'm in bed, but I'm thinking, and I want to think here in my journal where it'll be recorded for later.

I know that in my Roguelike project I'm using Actors for the Player character/s, NPCs, Enemies, and even Items and Special Effects. I want them to have different abilities that interact with the environment and other actors, and I want them to know how and when to use those abilities.

Up until now, I had hard coded this in the Actor subclasses Player and GreenEnemy. But when I pivoted the Map system so hard, it collided with the Actor system in a way that the whole thing needs to be redone, and why not redo it right, you know?

Ideally the stats, abilities and AI of the Actors should all be in a seperate file. Something I can easily edit to add or remove or modify abilities. Probably some sort of text file, or json or xml maybe.

These would be loaded into the game at runtime. I'm not sure exactly how to do it though, and that's what I've been thinking about.

The most basic abilities that the actors in the game currently have/need are move and attack. How do I make it work without direct coding?

I'm thinking if I directly code a collection of 'commands' that the text file can reference, I can build features outside of the game.

It's sort of like building a mini language.

3:00am - Anyways it's really late and I need to sleep. I'll have to build on this more next time.

6:11pm - I should be at work today, but I couldn't do it again. My roomie said I should work on my programming projects instead, if I was going to miss work, and he's right, but I was in a funk for a while first.

Now that I'm out of that funk I'm going to take his advice and do some work of my own.

6:16pm - Phew, nobody said this was going to be easy... Just hit my first wave of flee response. It occurs to me that the flee response I get from this work isn't NEARLY as powerful as doing my job. Alas.

6:29pm - I still keep thinking 'Maybe this would be easier if I started from scratch with what I know now' and I'm pretty sure that's wrong, but the thought occurs to me over and over. ^.^;;

7:57pm - It's hard to believe I've been working almost two hours.

8:05pm - Break time!

9:36pm - Well that was a longish break, but I've had longer before and I'm back now.

I'm currently working on implementing the GameMap method stubs I put in before, so that when I overhaul everything else they have a working map to use.

9:51pm - I've been analyzing the code I've got so far and I'm starting to think that the actor_list should be in the map too, since it's a list of the actors on that map. Meanwhile the actor_timing_list would stay on the Level which manages the sequence of events in the game.

...

Yeah I'm gonna do that.

10:17pm - On closer analysis, this might be the best time to implement the Spatial List for the actors, since they are being contained by the map now.

*looks it up* Oh yeah that's how it's done. It's just a pair of dictionaries.

10:39pm - Okay that should do for the add_actor method. It adds an actor to the map by adding it to each of the actor_map and position_map, and sets up the Actor properties to match it's location and connection to the map, and move it to its position graphically.


11:13pm - Alright time to stop for the night, but I managed to get into The Zone and complete all the method stubs in the GameMap class. Next time, I have to migrate the movement code to the map, and integrate it.

5:23pm - My new job is pretty easy but I'm still having trouble with stress. I'm going to keep with it for now, and do my best, but the parts that are hard are all inside me.

Anyways it might help to do some work on my Roguelike Game to remind myself that I do other things.



5:39pm - I'm moving some of the code from my Level script to the GameMap script. Specifically the map code.

I think Level will still be responsible for the Actors in the level, while GameMap will handle tracking map details and updating the visual elements.

6:01pm - I moved the Map code from the Level Script to the GameMap script, but I haven't reintegrated things yet, so that'll come next.

I've put some TODO notes in where I need to redo some things, and it looks like I'll need to modify the ActorFactory to not directly apply actors to the map, but rather return them and let the Level script pass them to the GameMap script.

I'll also have a lot of functionality to implement in the new format in general, but that'll have to wait until later. My Roomie is done his stream so we want to go run a few errands and eat out, now that we can. I'm also almost done my drink.

So, I'll save this and leave it for later, hopefully later tonight. I'd just leave it open, but I'm probably going to have to turn off my computer between now and then.

3:47pm - Well I'm up, fed, and got some errands done. It's time to work on my projects. But which one?

I've got my Roguelike Project, my Story Trade, and my Farflung Campaign that I could be working on. I feel like I want to do the first more, but the other two feel more important? I'm not sure. They're all good projects, Bront.

Well how about I start working on my Roguelike Project and maybe change projects when I get tired of it or something else comes along?

Now that I've got it all Git'd up and up backed up on Github I can make changes without losing what I had before.

Now just what do I need to change?

I have the list of features that I wanted to implement after the last one, but I wanted to go back and change some things as well.

4:11pm - I'm going over my notes to see what I wanted to change. I'll make a list here and copy it to my TODO list.

Move all Map elements to a GameMap object under Level
Make the GameMap generate or load Maps instead of having them input from a seperate map maker
Modify Action Timer to only work on the player
Convert actor_list to a Spatial List design.
Create a 'View' system for maps, that can output heatmaps for pathfinding

I think that should do for now.

4:26pm - I've started creating the GameMap object but the stress is hitting now.

4:31pm - Yeah too much stress now. Gonna play a game for an hour, gonna set a timer, we'll see how it goes.

5:38pm - Alright that's about an hour of gameplay. Biomutant's pretty good, if a little rough.

5:50pm - I'm looking at the code to figure out what to shift to the new GameMap object, and how to do it, and I'm thinking about the Fog of War. To make it so that different player controlled entities can have different Fog of War views... hum... while I was having that thought a bigger one slipped in.

The idea I'm having is that maybe the actors should contain their own stored map with what they know and can see, instead of having the map hold that information for just one player actor?

Then when a player controlled actor is up, it displays their personal fov instead of a general one. That changes a lot of things though.

6:46pm - After some work I ended up getting distracted, while trying to figure out how to handle the FoV.

6:57pm - I've become completely distracted and lost my focus on the work, so I think I'm going to finish up here for now and focus on other things.

6:34pm - Well I've spent quite a bit of spare time the last few days trying to figure out a bit more of how the GoRogue library works 'under the hood' and I think I've figured out the key difference to it, as well as figuring out that it can actually modify terrain mid-game.

The key difference from what I've been doing and what GoRogue does is that I was keeping a list of entities like actors and items, while GoRogue uses something called a SpatialList.

7:05pm - Bleh. Got bigtime distracted in the middle of what I was writing.

So, a SpatialList is primarily based on two dictionaries, called _itemMapping and _positionMapping. _itemMapping is a dictionary where the item is the key, and the position of that item is the data. _positionMapping is a dictionary where the position is the key, and the item, or a list of items (depending on the type of spatialmap) is the data. So, you can find out what's at a location using the _positionMapping, or you can find out where an item is using the _itemMapping.

This seems like a good method to track the location of objects in the world, compared to a flat list.

Anyways I just wanted to get that recorded somewhere. I don't think I feel like working more tonight.

5:00pm - So, it's back to work again with me.

I've been thinking about the structure of the game and how I want to change it, but I haven't made any serious progress yet. So let's continue that now.

I've got a MapGenerator that generates an array of MapCell instances, and a MapCell is just a bunch of flags. The first two are simple, but the second two are probably going to have to be changed. They're "is_discovered" and "is_visible" which make the maptiles focused down to a singleplayer game, where only one player can discover or see tiles.

5:10pm - Actually, now that I'm looking at the code, why don't I take a walk through it and see how everything fits together?

It starts with the Level script running its restart_game() function, which is also used to restart the game if it needs to. It initializes everything to the starting point.

First it sets up the actor_list, which is a list of the actors in the scene, then it sets up the actor_timing_list which is an ordered list of the actors in turn.

It sets it to the player's turn, then zeroes out a bunch of game variables, then it makes the map, that should really be in the new GameMap class I want to make. The Level script should tell the map to create itself, rather than creating a map and setting it to the map's variable.

Then it sets up an AStar2D map, which is another thing that should be part of the GameMap class instead of in the Level class. I want the Level class to be a container for the GameMap and the various Actors who live on that GameMap.

After the AStar2D map is set up, the restart_game() function resumes, and creates the actors for the scene. I wonder if the Actors should be collected into some sort of 'Actor Stage' or left on the same level as the GameMap?

Then it initializes the field of view, again that should be in the GameMap class. These should all be set up as a single "GameMap.setup()" call or something.

Then it uses the player's location to determine a field of view, and modifies the cells based on that for the FogOfWarTileMap to update based on the regular terrain map.

Finally it starts the action timer, which is a timer that counts down between each actor's move. I remember I was going to modify this because it only makes sense for the actors on screen, and maybe not even then. It's important for the player though, to prevent them from moving super fast just by holding down the key too long.

That's the initialization phase of the game taken care of. After that, active play begins at the _process() function and the _input() function, two of Godot's builtin functions.

The process function runs every frame, and handles triggering the Actors' on_turn() methods. It's a game pump. The heartbeat of the whole thing.

The input function changes variables based on what keys are pressed, and if those variables are set true, the process function behaves differently.

The Actors do their thing. The tricky bit is how they interact with the Map.

Each Actor has a grid_position that says where on the map they are. There's no accordance for non-wall objects in the AStar2D map; if an Actor wants to move into a square where there's another Actor, it fails. This is a pretty big flaw in my current design, and something I need to change.

And I think that's everything I've got so far. That's it. That's the game.

6:04pm - So there's a lot of changes I'm going to want to make, but I have to figure out how it actually should be first. For that, and since I've been at this an hour now, I'm going to transfer over to my ChromeBook and work on there for a little while, and figure out what I want the game to look like while sitting somewhere else.

6:36pm - This is the sort of thing I want to use for my maps: http://www.roguelib.com/api/GoRogue.SpatialMaps.ISpatialMap-1.html

6:49pm - I'm looking at the GoRogue documentation in order to figure out how to bring what they did over to my project without using the library itself. But I'm losing steam pretty fast...

7:09pm - I realized there was something I wanted to do tonight, and it's happening at 9:30pm. So I want to play some games before then, and time is fleeting, so I'll finish this now.

Next time, I think I'll figure out how to set up an image of my current Roguelike Project on github, and start modifying it to look more like GoRogue's system.