## Chalk

A Real Time Strategy Game, similar to games like Clash Royale featuring a variety of units, except players can also **draw barriers** and **projectiles** in addition to playing units, adding another wrinkle to the strategy of the game!

an RTS game based on the book, The Rhythmatist, featuring drawing as a core mechanic

Chalk (Title WIP)

NathanVP

I spent some time this evening doing some behind the scenes structuring so that everything to do with my entities is more condicive to me adding a bunch more entity variants. Prefab variants, cleaning default values/properties for the base/parent prefab, things like that. I also made this banger chalkfish spritesheet, but was too lazy to figure out how to animate it. Honestly, why does animating spritesheets on unity need to be such a hastle. Anyone know any packages or patterns to make it more intuitive/clean?

my silly little circles are now silly little fish sprites! 🐟 still some bugs in the whole process of everything but I am trying to add more sprites and art so that what I do have working looks good doing it (also the sprites face the direction of motion, which I did not need to worry about when I had the circles earlier because they are symmetric from all angles)

Oh yeah, I figured out how lighting works <:lfg:1017485754005463130> It almost feels like I have a gameplay loop in the works now 🤔

I was finally able to return to some game development today. I editted my GDD to better fit the change in scope (I am pivoting from a pvp to a pve gameplay loop) and I finally added lights to me scenes and fixed the lighting settings on my materials. Still not sure what I'm going to do for the lighting in the game, but the lighting inconsistencies helped me spot a loose end in my chalklines so the work is already paying off.

It seems the less I do game dev, the more I get ideas for game dev because my todo list for this game and list of games I want to make in the future have doubled in my semester-long hiatus 🤣

I keep forgetting to do showoff posts. ~~Today~~ Yesterday, I working more on Chalk and added a debug controller that allows me to add debug hotkeys that do certain things (like manually creating/deleting entities in the world). Still some more stuff I want to add to this feature

Oh, yeah I did program today! Refactored the chalkline code, so now each line, when built is built from scratch, instead of defaulting to a warding line and then scrapping that work if the line type is not that. More efficient and logical this way. Also farmed commits so I'm back at 700 annual 🎉

It seems like forever ago that I stopped in the middle of making the healthbars. Tonight, I finally fixed the visuals so that the hp bar adjusts accordingly (and properly offsets itself to stay inline with the creature) ||ignore my poor aim||

I worked on the HP Bar thing again, it works visually, but I haven't tested the update code yet. Going to canada in a couple of days 🇨🇦 so that'll slow my development progress. Oh, well, the price of vacation 🤷‍♂️

Today, I was investigating making moving health bars for my chalklings. I want to flesh the basics out for these creatures, before i start permuting them and making a bunch of variable prefabs. However, my first attempt at world space hp bars was to spam canvas objects (not performant) so I scrapped that and have been doing research on how to better accomplish this (w/o delving into custom shaders and the like)

Made the damage for the line missiles proportional to the length of line that you draw. Also made that system configurable and its all in one place for tweaking later. V short but it was one of the todo items I put up yesterday so, why not now

got a very lackluster gameplay demo in a new scene (so lackluster that I'm not even going to show you guys 😏) but in playing around with that, I found a number of small and large tweaks and changes and features, that I turned into github issues for future me to work on. The pace is picking up and progress is coming along easier, a shame summer is coming to an end 😭

we cookin now bois 🥘 Got that lerp alpha w/ coroutine going 😈 its only gets easier

she works! it looks jank and super unresponsive, but the circle seeks the weakest part of the line that is closest to get to, and attacks that at some atkSPD until it kills it, at which point the line is destroyed and the pathfinding grid is updated

I wanted to fix the attack range from last post. Today, I extended the range by which creatures check for lines to attack within range. That was a headache to add, definitely deserves a refactor in the near future, is probably not optimized nor extendable, but it do work for now, which means I can continue moving towards a working prototype. The diagram attached shows the node the creature(circle) is centered on, and the box of nodes that it checks, as well as the nodes that have a line within range

game dev is far more engaging than the multiple assignments I have due this week 😉

Figured out the source of one of the bugs I was encountering. Basically, my agent wasn't detecting nearby lines to attack because the attack radius is smaller than the sprite (im checking range using grid pos b/c I already calculate that stuff etc.) so basically, I am going to expand the radius on the grid to check for nearby line targets, and if that is not performant enough, I will switch to manual collider collision checking

More commit farming today 😁 I went back and *didn't* fix what I was working on yesterday. Instead, I had thought up my method for tracking damage on lines from various points of attack and so I implemented that. However, in doing so, I forgot about a helper function that I had made a while back and so I ended up making that same function again, in a different spot, which was far less pretty. My code senses were tingling that I could optimize it somehow and in the process of refactoring, I found the old helper function, was like *'dang, this makes everything so much nicer! lets refactor again'* and then I did and that's all for tonight 😴

today, I am very frustrated because I did not solve the problem I set out to. I'm sure there's a solution out there, bc this is a relatively common implementation. Essentially, I want to run the `Attack` function if 1) the attack cooldown has transpired (accomplished using coroutines to delay code) and 2) if there is a target to attack. When no target to attack, don't trigger a cooldown, check every update/fixedupdate. However, when I don't trigger the cooldown, the whole thing freezes, even though the while loop is inside a coroutine

I completed my Attack-Damage cycle for chalklings and chalklines, by overloading some existing functionality of my API, using `out` keyword ||👀|| and I set up some issues on the repo to remind me what I have to do tomorrow 😁

I FORGOR💀 to showoff post for today!! <:whygodwhy:885673765005066271>. Well, my mega streak was gone anyways, so whatevs. Essentially, I did some more coroutine stuff today, extrapolating the things that william showed me in #🤝advice-n-help into a helper class so that the functionality was accessible everywhere. I also started work on the specifics of the Attack behavior for my chalkling creatures.

Today, I cooked up an attack cycle for my chalkling, much like the attack cycle for units in clash royale. I am using `InvokeRepeating` on the Attack function, of which im not sure the best practices for using that, so if there are any, let me know 🙏

minor structural stuff today. Wrote some kode 😎 to let my chalklings see where they are in the grid, and for each node in the grid to track the line closest to it. This is all in the name of enabling the chalkling creature to check the grid for the node its on, and then check that node to get the closest line. Once it has the closest line, it needs to find the closest part on that line, which I calculate elsewhere, I just need to bring that data in, and then the chalkling does damage to the right part of the line, behaving as intended! 🙏

A return to gamedev and farming commits 🧑‍🌾. Today, I toyed around a bit more with the pathfinding and I found a case where pathfinding can get the entities stuck in a loop. In the attached image, the 4 nodes nera the center of the object all point inwards so the object never leaves that square. Not sure what the ez way to resolve this <:thonk:898024663228239962>

🐛 🔨  BUG SQUASHING 😎. With my new and improved pathfinding algo, I noticed a bug where if just 1 layer of nodes were left (the boundary nodes) on the edge of vector field, trapped between the wall and a line, those nodes would point out of bounds!, causing the entity to get stuck on the wall. 🚫 No Good ⛔. I programmed a clamping function today to catch that and lock those  edge nodes to pointing in bounds  always!

The Return to Game Dev!!!! The first week of July is always busy with what feels like half of my family having birthdays in that time, as well as National Firework Day 🧨. I'm back now, and I wanted yall's opinion in which vectorfield looked most correct/natural? 1️⃣ 2️⃣ or 3️⃣

Leaving for vacation today, so I tried to do some gamedev early. Still no progress on those pesky squares that have higher distances than their neighbors. I think it is an issue with some nodes adding their obstacle modifier to the distance, which is a neighbor nodes distance that has already added the obstacle modifier for that same line, effectively double counting how much a line affects the terrain. I did try a way to avoid double counting, which did fix the issue, but that check also causes the obstacle modifier to *not be added at all* for some nodes, so the line had no effect on the node distances. No good. I have a whole plane ride to think about this so hopefully I can come up with some improvements 🙏 <:galaxybrain:885675080678506566>

Malheureusement, my work is never finished. I am trying to fix these outlier nodes that crop up, seemingly randomly, with much larger distance values compared to their neighbors. I have managed to identify these nodes programatically, but I haven't figured out a way to negate this. I'll sleep on it and see what I can do tomorrow. I go on vacation, so this may be where my streak ends 😭

ALL HAIL, MY GENIUS!!! I FIXED THE RAINDOWS 🏳️‍🌈
top is broken (the color gradient is not smooth, when it clearly should be)
bottom is fixed (smooth smooth colors 🥵 )

made some tweaks and configuration changes today, making debugging easier. I messed around with how much I weighted the obstacle health when modifying path distance, but I am still getting sharp lines of contrast in the gradient field, when I would expect softer color transitions. Definitely need to re-investigate my ComputeDistance function to make sure there aren't any bugs in there

improved the edge node vectors today, so that they point a bit more in the right direction. I can't make the vectors more accurate without risking the vector point out of bounds (which would be a whole lot more edgecases to look out for)

It's Pride Month!!!! sorta cool color stuff today. Still on a quest to wrangle the pathfinding into working as intended, I switched up the gizmo alg for displaying nodes as a function of distance, and I got this! Looks cool 🏳️‍🌈, but also reveals some troubling info a bout how distances are calculated. Ideally, the gradient should be smooth across the grid, and not have these sharp lines as we're seeing. V curious about why those are happening and if fixing that will ameliorate my grid 🙏

I have performed a paltry amount of work on the game today, but that's mainly because I have encountered some limitations with the goal-vector pathfinding and I've been rattling my brain to try and figure out how to improve it. The weighting causes all of the nodes on the perimeter to point inwards, not exactly optimal. The weighting basically causes the nodes to point away from its high-dist neighbors. The nodes on the edges count the outside of the grid as infinitely far away, so they always point away from the outside. Additionally, the red obstacle nodes have a really high distance (because it takes a long time to wear the obstacle down) so all of the nodes next to them always point away, even if it's not the most efficient direction. hence why I need to add to or rework entirely the vector calculation. <:galaxybrain:885675080678506566> 😩

I am perpetually puzzled by the bugs that are appearing in the code. I made some small simplifications: I was able to remove an alternative method of calculating the pathing vectors, since all of the nodes were valid (including obstacles) and I changed the weighting of obstacle nodes to try and elicit the right behavior from the vector field. That change caused a bug to appear, which was simply that normalizing a Vector2 with a really small magnitude resulted in a zero vector. I just had to add a manual check for that and I was good. Now, the vector field is still not acting as I want it to, so I made a new, separate testing scene to hopefully focus on just the pathfinding

🙏 I found the culprit 😠 It was me <:whygodwhy:885673765005066271> I had messed up the bounds on my for loops, overcompensating to avoid OoB exceptions 😔 
```csharp
//incorrect               \/
for (int i = 0; i < length - 1; i++ {
  array[Mod(i-1, length)];
  array[Mod(i+1, length)];
}

//correct                \/
for (int i = 0; i < length; i++ {
  array[Mod(i, length)];
}
```The mod operation I was doing compensated for OoB so I didn't need to adjust the range of the forloop as well. The result was that I was skipping the last element in the array, leaving it at the default values, which is why those numbers were showing up later in the code. Learn from my mistakes!

also nothing that interesting for me as well. I am still working on squishing this bug. I have ruled out a lot of things it could've been, but I haven't found the culprit yet. Here's hoping I can find it tomorrow 🙏

working on ironing out le bugs from the pathfinding changes I've been developing the past couple of days. I've connected those changes to the distance evaluation for the whole map and caught bugs that I missed before, but I still need to fix a bug where the health of nodes on a line keep getting read as the default `1` rather than the `>100` it would be if the health value was actually set on initialization. Probably has something to do with how I've reduced the node count to improve performance but I'm not sure. Probably would've caught it sooner if I had unit tested but o well 🤷‍♂️

today, implemented the many functions I wrote out in pseudocode yesterday. They work, per se, after fixing a few race condition errors and removing print statements in nested forloops (they were taking my performance). I still need to plug this factoring behavior into the actual pathfinding, so it updates with the rest of the non-obstacle nodes (`ln. 140 in Grid2D.cs`), but that's for tomorrow

added many comments today, working out the pseudocode for how I am going to this (see original post). In doing so, I revised my pipeline and structure again for how this will work, and I am still uncertain of the performance impact of my plan. However, almost all of the nuance and gimmick of this game idea revolves around this mechanic working, so I don't have a choice. We'll see how many days it takes to make and then I'll benchmark.

Continuing to work on my "dynamic pathfinding obstacle weighting algorithm" plan today. Good news is that I imagined a better approach to everything that uses the code/data I already am calculating, which reduces redundant work and saves time:
> UpdateObstacle (iterate over obstacle nodes)
> - find each obstacle node
> - grab the chalklines it is near to from the Physics2D.OverlapBox() check
> - give each obstacle node a weight modifier as a function of nearest chalkline health (consider that multiple lines can stack modifiers on the same node)
> UpdateDistField (calculate distance for all nodes)
> - for obstacle nodes, add obstacle modifier to them during weight calculation
> UpdateVectorField
This avoids calling UpdateDistField (a hefty O(n^2) operation) multiple times, and utilizes the colliders that I'm already finding in UpdateObstacle, which is much better than running those expensive physics calculations a second time.

much thought went into my game today. I fixed a visual bug with the line missiles, but I mostly spent my time considering ways of factoring in the difficulty of eating through a line obstacle into the pathfinding. Since that time should be variable and the chalklings should target the weakest part of the line, I want the system to be super robust and not just a simple `if (line) { add arbitrary modifier to distance weight }`. My plan for that goes as follows
> UpdateDistField (calc dist for non-obstacle nodes)
> Iterate over obstacle lines
> - give each obstacle node a weight: lowest weight from non-obstacle neighbors + weight modifier calculated from nearest line health (consider that     multiple lines can stack modifiers on the same node)
> - if all neighbors for an obstacle node are also obstacles, don't weight that node
> UpdateDistField (recalculate distance for non-obstacle nodes again)
> UpdateVectorField
This feels too expensive, recalculating the whole grid again, but I may be able to optimize by pruning nodes that are unaffected. I also want to investigate how other games may have solved this issue of dynamic pathfinding distance weighting. Hopefully there's a god-algorithm that just solves all of my problems 🙏

not finished with the work today, but I was working on aborting the line drawing procedure if it was drawn over the target (because then pathfinding would break). gif when I finish

Not big stuff today, just more polish. For drawing closed shapes, I made the `"enclosure detection algorithm"` (real advanced, I promise) a bit more lenient and also smooths out the curve a bit at the closure point making the shape a bit nicer and the strength of the line more forgiving. I also added a catch for the slim chances someone draws a line that is super short so there aren't enough data points to properly calculate the line's HP. in those cases, I just set each of the *at most* 2 line segments to the base hp value. those are 2 bug/QOL changes that I am happy to have made 😁

bug fixes today on my lineHP code. I fixed a bug where my calculation for strong/weak side of a line segment was always the same, rather than the strong/weak side being opposites. So not only did I have to fix it so that the strong/weak side were opposites, but I also had to fix the code so that the strong/weak sides were correctly assigned, rather than always being on the same side of the line, no matter how the line curved

Today, I fixed a bug where the health of each line node was incorrect when that line segment bend had a negative angle. I also discovered that the strong/weak side math ended up with basically the same answer for both, so I need to take the time to sort that out tomorrow!

grinded out HP calculation for each node in the lines I'm drawing. Lotta funky trig math here that I was working with, like `(Quaternion.Euler(0, 0, -180f + angle / 2) * leftVector).normalized` and `Mathf.Cos(ToRad(90f - angle / 4)) * _enclosedHPScale` and its all terribly illegible, but I think I did the best I could and was finally able to cross that feature off of the issues list, which has been on there since January <:lfg:903129436851949620>

not much to do today, since I am v 🥱 but I did get wall collision working, as per the gif. Some things I learned is that edge colliders do not collide with each other, thus I needed to use a box collider instead for the wall. I also need to add a switchcase pattern to the `OnTrigger` event to differentiate between the line colliding with a chalkling, and a line colliding with a wall. More to do, but that's just commits for tomorrow, I say

not a visual change, but I segmented the straight line missile so that it can bend like `\/` as if it were reflecting off of a surface. This segmentation is calculated with respect to the line's movement, so that hopefully when it reflects, each frame falls on when each segment jump changes direction (that doesn't make sense, but when I program it, I'll show you) I still need to add this segmentation to the collider, but then I'll be closer to making it programmatically reflect off of walls 🙌

now my line missiles can interact with and damage chalklings! All that's left is to do the wall reflection, but I could even declare that a non-MVP feature and ignore it for now <:thonk:898024663228239962> I just need to make a few changes to the behavior of chalkling pathing, and add a variety of chalklings with different stats and sprites, then I may have a working prototype 🤩

Investigated a bug where my grid was detecting colliders on *all* layers as obstacles, not just the colliders on the obstacle layer. That was a quick `overlapFilter.useLayerMask = true;` fix but it also reminded my to organize my layering for all of my prefabs, before things got out of hand. I used this handy triangle in the project settings to do that 📐

still refactoring, currently, but I'm just going back through my codebase and reworking things to be a bit more legible, especially my pathfinding code since I was really in the weeds while I was developing it 😅

🔫 I got the missiles moving! In doing so, I also discovered the `use local space` setting on the line renderer, so that funny business I had to do yesterday to differentiate between the two, can just be cut, since both the collider and the renderer use local space now 😁 Next up is making the line missile reflect off of walls, but I haven't made any walls, nor am I prepared to do the math to make the line bent like `\/` like those science diagrams of light rays as it propogates. That's a problem for tomorrow me!

mostly refactoring today on the line missile object. I added a rigibody, so I can make it move with trajectory next time. I added the end circle objects. I also figured out that colliders work in local space, but line renderers and setting child transforms work in world space, so I had to figure out some related bugs and set both local and world positions inside the LineMissile. The only visible change is that the ends are curved, and not flat.

Added the edge collider component to my shoddily-constructed LineMissile Prefab. That was set much the same way as the line renderer. I also looked into adding those 2 components to the GO at runtime w/ AddComponent, rather than leave the components on the GO, only to be changed immediately after Awake. However, I saw that AddComponent is not performany, thus I will leave the dummy component on the prefab and not add anything at runtime. Related: is there a simple way to copy a component's data/fields across to another component? That'd be nice to investigate

I spent like 3 hours making a Warlock character (still on the Dnd hype train) so I didn't have much time to do game dev. I did make a dummy prefab for my Line Missile object! It doesn't do anything now, but will eventually be able to interact with other lines and creatures, as well as reflect off of walls 👀

I finally got around to the straightness algorithm. I used the third response on this post here (<https://gamedev.stackexchange.com/questions/98059/how-can-i-quantify-a-drawn-lines-straightness>) to determine straightness. Essentially, I just integrate over the line segments that compose a drawn line and
> - find the rate of change of direction of the line segment (how much is has changed direction)
> - square that to weigh bigger changes more
The integral sums those deltas together, and outputs a value which is essentially the weighted amount of net change in direction the line undergoes. Then I compare that value to some threshold value to determine if the drawn line is straight enough to be considered straight.
```csharp
float sumOfDelta = 0f;

for (int i = 0; i < reducedNodePos.Count - 3; i++)
{
    Vector2 segment1 = (reducedNodePos[i + 1] - reducedNodePos[i]).normalized;
    Vector2 segment2 = (reducedNodePos[i + 2] - reducedNodePos[i + 1]).normalized;
    Vector2 segment3 = (reducedNodePos[i + 3] - reducedNodePos[i + 2]).normalized;

    Vector2 delta1 = segment2 - segment1;
    Vector2 delta2 = segment3 - segment2;

    sumOfDelta += (delta2 - delta1).sqrMagnitude;
}

float straightness = 1 / (1 + sumOfDelta);
Debug.Log("Straightness: " + straightness);
return straightness;
```

Ok ok ok ok I know I said I would get into the funny line math today, but I procrastinated and spent too much time reading up dnd homebrew 🤷‍♂️ ||no regrets ✋😔|| but I DID reduce the amount of line nodes needed to be tracked for collision and chalkline strength calculations, while keeping the same amt of detail for the line renderer. I forgor💀 to take before and after pictures, but essentially, there are fewer nodes on the edge collider (1/4th) than compared to the line renderer. This is sort of how you can reduce tri-count in blender without sacrificing detail

Used some of those neat local functions in my code and made space in my BuildChalkline pipeline for new line types, state enum + switchcase included 😎. No actual line math magic written bc I was playing dnd 🗡️ 🤩 but I'll get to it, I promise 🙏

Still nothing visual to showoff today. I did clean up my issues on Github for the project, add comments to the codebase and generally try and clean that up after all of the refactoring for optimization that I've been doing for the past couple days. The next step forward is to try and detect when the player draws a straight line and turn that into a new line-type object, so I was refamiliarizing myself with the code related to making Chalklines. Hopefully tomorrow 🙏 I will get a working prototype of the Line Missile 👀.

Sidenote: its very cool to read all of the proofs and algorithms related to geometry and doing robust line manipulation/analysis. <https://gamedev.stackexchange.com/questions/117613/how-to-smooth-hand-drawn-lines> and <https://stackoverflow.com/questions/35763547/how-to-smooth-hand-drawn-lines> were posts I bookmarked for later 😁

Today, I continued to try and optimize my code. doing circle checks on each node was prone to leave holes because the line collider went between the range of the nodes so the nodes didn't detect that they were supposed to be impassble. The solution, since the nodes were arranged in a cartesian matrix, was to use cartesian (square) bounds to check rather than polar (circle). So I changed `OverlapCircle` to `OverlapBox`. While fiddling around with that, I noticed a huge performance cost when there are many nodes in the grid that overlap with one or many lines. `OverlapBox` was unnoticeable when there was no collision, but became very expensive each call when there was. I found a faster `OverlapBox` overload on the docs <https://docs.unity3d.com/ScriptReference/Physics2D.OverlapBox.html> that helped, but I think that I have learned that I will not be able to run vector field pathfinding in FixedUpdate, since it just is too expensive at the scale I want it to be. Oh well, Event-based grid update it is 😄

Today, I spent a while optimizing my pathfinding algorithm that I developed in the last couple of days. I was wondering if my algorithm was performant enough to be run on FixedUpdate(), 50fps, because a possible arcade game idea depended this performance. So I spent the better part of 2 hours looking of Unity and c# documentation and recalling Data Structures lectures and lessons about optimization and I am happy to say I brought the cost of generating the goalvector field down from ||**~16ms**|| to ||**~6ms**||🎉 🥳! YAY!!! that's almost passable now. Considering my computer is dogwater, this was tested in the editor and now on a built version, and a good chunk of that time is simply unavoidable memory alloc and collect calls, I am happy with what I have. I also added parameters to my grid and lines so that I can tweak collisions and grid density since `Physics.OverlapCircle()` is really expensive when there actually is an overlap.

Not much done today, I just finally added a proper README to my chalk project. While I was writing it, I was reminded of all of the features and gameplay mechanics that I am considering adding to the game in various capacities and I can't until I have the gameplay basics down so I can start work implementing and testing those cool features!

Refactored my GetNeighbor code today, among other things. It was largely illegible with the following repeated for all 8 directions
```csharp
if (node.GridX >= 0 && node.GridX < gridSize.x && node.GridY + 1 >= 0 && node.GridY + 1 < gridSize.y)
                neighbors.Add(_Grid[node.GridX, node.GridY + 1]);
```clearly, that's 🤮 so I refactored all of that into nice nested forloops:
```csharp
for (int x = node.GridX - 1; x <= node.GridX + 1; x++)
{
  for (int y = node.GridY - 1; y <= node.GridY + 1; y++)
  {
    //skip center node
    if (x == node.GridX && y == node.GridY) { continue; }

    if (CoordsInGrid(x, y))
    {
      neighbors.Add(_Grid[x, y]);
    }
  }
}
``` 👌 much cleaner. However this implementation didn't prioritize the cardinal directions so the pathfinder sometimes defaulted to taking diagonal paths rather than straight ones, even through there were no obstacles to avoid and going straight was the shortest path. Thus, I had to refactor again to a middleground: one that wasn't as clean as the forloops, but was able to prioritize the cardinal directions while still being legible ||I hid the ugly boolean stuff behind functions||
```csharp
//top neighbor
if (CoordsInGrid(node.GridX, node.GridY + 1))
{
  neighbors.Add(_Grid[node.GridX, node.GridY + 1]);
}
```

🙏 fixed the issue with the vector fields. I added line gizmos to represent what the vectors were and I could see that the red obstacle nodes were always pointing tangently away from the line, irregardless of the optimal path. luckily, the video I was using to design my vector field had considerations for this, so instead of doing a weighted average of neighbor nodes to determine the position, when the neighbor nodes contain an obstacle, I instead do a min function, which avoids the miscalculation that occurs when trying to find the path weight of an impassable node. I hope that makes sense. Basically, the agent never gets stuck on lines now!

Today, I finished the vectorfield pathfinding I was working on b4 the game jam. Still kinda jank, and I need to figure out why its colliding, but this is much more performant than running A* for every pathing object in the scene 👍 https://cdn.discordapp.com/attachments/865431151383150612/978459185765314600/Unity_pAOkn10Nvg.gif

I ended up changing and rewriting and cross-referencing a bunch of things, but I finally got `ComputeDistField()` to work 🙏 🙏 🙏 🙏 🙏 and not loop infinitely. I want to spend more time and finish the Vector-goal pathfinding, but Berni Murcer commences shortly so that's gonna be hype <:pogfish:885672794556334091>

bro, I can't with this `ComputeDistField()`. It's stuck in an infinite while loop and I can't figure out why. I referenced with William's code, my old code, code with strangers online, examples of Dijkstras online. All of the pieces should be in place, so I'm not sure why I'm still in this loop. Also debugging is terrible because when it does go into infinite loop mode, it freezes Unity and none of the console logs are printed so I can't see how far it gets. I'm taking a break and will probably resort to sacrificing my time complexity by brute-force checking that every node has been checked

Not enough time to finish the vector-goal pathfinding today, but I think I got `ComputeDistField()` down, using the following resource, my own A* code, and William's, code which he leaked me (that contains some handy optimizations) https://www.youtube.com/watch?v=ZJZu3zLMYAc

I made UpdateObstacle occur on a call rather than on the update loop.  that already shaved 15ms off of the profiler so I think that's a W. the current implementation can trigger the event when a line is destroyed and when it's created so that's all I need. I still need to transition from A* on fixedupdate to vector-goal pathfinding, but that should be a simple heuristic change (or so William says) 🙏

Added more code style to the codebase today. I also discovered that, when no path is available for the pathfinder, it has to check the whole board before coming to that conclusion. thus tanking performance. This won't be a grand issue once I replace the 'no walk' obstacles with 'weighted distance' obstacles but it showed me where I can make performance optimizations. I'm going to replace A* with vector-goal pathfinding, which calculates a pathfinding solution across the whole board  at once (currently, multiple creatures will call the pathfinding algorithm multiple times) and I will also only update the vector field when it is changed, rather than at every Update() call

I moved back to Gainesville today, but I still was able to get some dev work done. I added Namespaces to most of my scripts according to my existing folder structure. I saw this video https://www.youtube.com/watch?v=vLrGdx-Ob3g and heard it that namespaces could improve compile times, something that I could definitely feel taking a toll on my productivity. I'm curious what some of the experienced Unity used have to say about namespaces and best practices surrounding them in game dev

Multiple layers of refactoring and codebase simplification. Happy with the direction of everything and so far it all works as it did before the refactor so that's all good. Also 🧑‍🌾 farming commits (700 annual commits, here I come!)

🙏 Bless my brain and whatever I ate for dinner tonight because I just thought up like 3 possible features to add to my funny drawing game. AND a small arcade-y miniature game jam scale game to act as a proof of concept and intermediate step to the full game. Also updated the GDD for all of this and drew some diagrams 🖋️

REDEMPTION <:pogfish:885672794556334091> ! Cleaned out like 6 issues and bugs with the pathfinding system to get it to work, including bugs that I didn't have fixes for in the last implementation.
> ✅ Correctly gets grid nodes from worldspace, regardless of grid node density
> ✅ Proper behavior when path length is 0
> ✅ Proper behavior when no path is found
> ✅ Removed default edge collider segment during line draw that was messing w/ pathfinding and not synced with the line renderer
> ✅ Adjusted margins so pathing creature does not collide with line following the pathfinding
> ✅ Fixed the debug grid bc I was checking equivalence via object instance instead of object properties (Prog 1 moment)
Still a huge refactor needed for the system, since it has negative scalability rn, but I got it to work for 1 creature at least

very not pog progress today. The old pathfinding system I did for PantsFireAnvil has put up a fight as I am trying to wrangle it to fit this new game context. I think the path is no bueno, but I've run out of time to debug that tonight. very sadge

🧑‍🌾 Farming commits today. after the refactor from yesterday, I added line drawing to me creature test scene, fixed a bug caused by bad params, adjusted grid and line colliders, and voila, Lines drawn are now obstacles! Pathfinding for creatures comes tomorrow 👀

Not much to show, other than the refactoring I did of my chalkmeter into a scriptable object

busy day, Mother's Day was great. Shoutout to all the moms in GDA ❤️ . In terms of game dev, I started work on setting up the environment for all of the units that will be in the game, starting with the pathfinding. that, of course, starts with obstacle detection. Still a lot more to do to get the whole system working and my todo list keeps growing by the day. 🙏 Game Dev 🙏 though bc this is fun stuff!

tried tweaking the line renderer settings to be more appealing. The corner vertice count did something, improved the line in some cases, but had visual glitches in others. First pick is without corner vertices (no-smoothing), second is with.

tiny bit of QoL this day. Patched a hole in the Edge collider of enclosed lines from yesterday and added rounded tips to the line renderer when you're drawing the line, hopefully to make the line look smoother. I could also increase the node frequency, but that could get more costly with and line calculations I have planned

hardly much, but I added an edge collider to my Line object. I drew it using the same list of nodes to make the LineRenderer. This will come in handy when I add entities to the game 👀. Also a bunch of new issues on the ~~github repo~~ **TODO list ** 👍

messed around with my line nodes because they weren't actually intervalically even when was adding them to the line. I made the node distance really big to test this. I also fixed a bug where, on small node distances, it was easy to accidentally "enclose" a line and then the system stops drawing that line. Now, a configurable measure is in place to adjust the sensitivity on line min length before checking for line enclosure

not very easy to show, but I did a bit of a refactor (already 🙄 ) and combined 2 classes since they didn't really need to be separate and passing data and synchronizing state and behavior betwixt was getting messy. I'm absolutely <:pogfish:885672794556334091> ing at all of the **__Clean Code Characteristics__**™️ the final class is exhibiting though. 
> minimize redundant code ✅ 
> null/Destroy variables/GOs when finished to avoid accidentally changing those and causing bugs ✅ 
> consistent code style and formatting ✅
> descriptive and abundant comments ✅
🙏 Prof. Fox would be proud 🙏

Chalk (Title WIP)

Dev Logs

Chalk