JLJac on June 11, 2014, 11:16:12 AM:

Yup, sent him an email!

Sorry people, no proper update today. I spent all day fighting with an A* implementation, and finally found the bug, so that's good. The pathing algorithm can now be fed different preferences, such as ability or disability to climb walls and the like, and find paths according to those. This was substantially harder to implement than I thought it'd be, mostly because of the little bug that gave some weird unpredictable results and took quite a while to identify. More exciting stuff tomorrow!

JLJac on June 11, 2014, 11:35:15 PM:

Surf's up!

JLJac on June 12, 2014, 08:27:06 AM:

Thanks!

Update 254
Pathfinding continues! It's a bit frustrating, because it's very hard to write about my progress when it comes to pathing. Like, half a day might be "it seems to prefer using a ledge drop here, even though I told it to use a climbing connection. Is this because the heuristic is wrong, the sorting algorithm, or because it disregards the sorted order all together?"

Excitement!

Today though, I have made some pretty cool progress. I now have a class called "Creature Template", which holds a few data points about a specific breed of creature and which is accessible from anywhere in the game. The creatures defined right now are Slugcat and Lizard, and at this point it only holds some pathing preference info on them.

Still, this has some potential. An example - today I made one implementation of what I call a "connectivity mapper". It's a thing applied to a room - it goes by every entrance to the room times every other entrance to the room, and pretends to be each of the creatures drawing their data from the creature templates. Then it paths between the entrances using that creature's pathing stats (can I climb on walls or not? Do I prefer climbing to running?) and decides if that path is traversable, and saves its cost to an array.

The result - for any room any creature can know if it's able to pass through it just by doing a quick lookup. My idea is to use this in particular for abstracted creatures moving in offloaded areas, but more on that when I get to it.

This isn't the only thing the creature templates can be used for though. Anything that might need to be known of another creature that's common to its entire breed can be accessed through this generalized system. For example I could hook each creature template up with a list of "prey creatures" and "predator creatures". Then when a creature encounters another I wouldn't have to make a hardcoded event for their interaction, I could just have the creature ask "does this species eat my species" and if so it can initiate a fleeing behavior.

I hope for it to be a huge asset when working with AI, as in decision making AI, not just path finding. In an encounter a creature could easily check if, for example, another creature is able to fly or not, and make decisions based on that.

Creatures could be assigned tags such as "poisonous" etc.

The main difference here is that instead of everyone just having their individual stats, the species themselves are entities.

So that's cool! Now back to path finding!

JLJac on June 13, 2014, 09:34:41 AM:

Decision making AI and pathfinding AI have probably been the two most demanding task technically, though I doubt they'd be overshadowed by the staggering amount of hours that has been soaked into everything else combined... Why?

JLJac on June 13, 2014, 11:06:58 AM:

Yeah, they probably took more time than any other identifiable "things", though that still wouldn't be enough to make them the majority of the time spent as there are in fact many many more "things" than you'd expect. Making the menu work, saving and loading levels correctly, making UI for the level editor etc etc etc are all tasks that have taken a lot of time as well!

Update 255
Speaking of which, we're in the middle of one of those kind of tasks right now! What I'm currently doing is setting up the very framework for the rain world - a bunch of levels that are interconnected. Today I managed to load a world structure from a text file. This I hope will make it easier for me to do changes, and also helps me separate data and functionality in a way I wouldn't be able to if I just built the world by having a bunch of commands and hard coded level names in the actual code.

So basically there is a World class, which has an AbstractRoom object for each room that exists on the map. This is a very simple little object that basically only knows what other rooms it's connected to and what its level name is - the level that will be loaded if the player enters this room.

What's the purpose of this? It's that now the entire world "exists", though in an extremely abstracted form, even if it's not currently loaded. Rooms that are off screen can be asked for basic properties, such as what other rooms they're connected to. Also, each of this AbstractRooms have a reference to an actual loaded active room, though most of them will just be referencing null most of the time. When you exit the room you're currently in an enter the next one, the game will fire up a new room object according to your new world coordinate, and place you in it. Eventually I'll want to unload rooms after you exit them as well, but I'll get to that when I see how much of a memory concern it actually becomes. I think it would be kind of cool to have the rooms live a little while after you've exited them if there are creatures in there, so you can go back and see that events have been happening.

Soooo... weren't I supposed to make pathfinding AI? Yeah! I'm just preparing everything for when I get into some serious A* implementations. Without breaking the policy of not telling in advance too much I can at least say that I want the creatures to be able to take other rooms than the ones they're currently in into consideration in their AI - that's why I need to create the world they're to move through before I get down to actually making them run around.

Today the first step has been taken to putting the World in Rain World, so that's a pretty huge improvement even if the game looks and behaves exactly the same as yesterday. That's the kind of thing you learn to appreciate as a programmer, I guess

JLJac on June 16, 2014, 12:21:09 PM:

Update 256
This week there's some family stuff going on, so I'm in a house with other people  . This situation doesn't really lend itself to the super deep concentration I need for path finding stuff, so instead I think I'm going to do some art.

Today I did some experimentation with Rain World "plant life", or whatever you want to call it. Not at all sure if all of them will go in the game, but it's a lot of fun to play with different shapes and ideas.

jamesprimate on June 16, 2014, 01:45:13 PM:

ohhhh i love all these. id say "especially the gross slug ones", but theyre pretty much all gross slug ones XD

JLJac on June 21, 2014, 01:46:34 AM:

Hi people! As you might have noticed it's a bit quiet here this week - I'm attending a family gathering. I just wanted to let you know I'm alive, and we'll be back to daily updates monday! 

JLJac on June 24, 2014, 08:21:03 AM:

Update 257
I've been doing a bit of animation work on the spears and stones. In the Unity version the framerate is potentially very high, and I find myself wanting to account for that - ie I want things to snap between positions and rotations as little as possible but instead have them move smoothly. One way to check if I'm achieving this is to look at it in slow motion. There shouldn't be any jumpy movements even when played at 1/20 of the speed, is the philosophy. This is intended to give that extra little bit of crispness to the animation even when played at normal speed. All of those frames will be displayed after all, and if they are all smooth that'll probably add up to an impression of general smoothness even though you don't perceive the individual frames.

Here's a spear being thrown in regular speed and in slow motion.



Note that there's no animation work what so ever done on the slugcat for throwing, only the spear. Obviously we're gonna want the slugcat to really lean into the throw later on. Right now it looks like the spear is throwing itself 

In other news, the pathfindingpocalypse has begun.



I have a few ideas for path finding in general, that I want to get into a big base class to be used by all the sub classes later. The most important of those ideas is this:

You guys remember how I made something that could map the connectivity between different exits in a room, right? Here's the deal - using that data, the path finder can consider paths through offloaded rooms. In each offloaded room (or abstract room, as I call them in the code) I place a path finding cell for each exit. Key is that it's not one per room, but one per exit. The idea is that the path finding algorithm will be able to check for viable paths through the offloaded world by using these cells, and the pre-calculated data of how difficult it is to get between them. When the pathing creature is in a room, and that room is loaded, a high-res pathing map with one cell per tile is created for that specific room. These pathing cells are the same class as the ones in the world map though, and they are hooked up to the world map through the exits.

So, the idea is that this system will allow creatures to find paths through loaded and offloaded rooms completely seamlessly - there won't be a separate system for path finding on the world map or in the local area. At the same time, the world map will be grossly simplified compared to the local area, making it way easier on the processor and RAM, but providing the same paths as if all of the world was loaded and taken into consideration at once.

Wish me luck.

JLJac on June 25, 2014, 08:02:52 AM:

Update 258
Pathing is coming along nicely. I'm not not making amazing progress, but I'm also not spending all of my time hunting bugs - it's just trotting along. I have spent some time writing debug functionality though, such as the little dots showing what's going on.

Don't really have much to show as this work isn't very visual - but this is what lizard pathfinding looks like as of now.



What I'm happy about is that it looks like I'm going to be able to make a huuuuge part of the path finding code shared between creatures. Ideally I'll be able to have everything in the same class, and only outsource a few things to creature specific path finders. Those things would be, for example, questions of what moves are legal and what number of cells the creature requires per tile (which would be 4 for lizards and 1 for everything else).

Also I've been able to make the path finder tap into the template creatures I talked about earlier, which is pretty cool. This means it can be given a creature template to path as, and it seems to be working. For example in the above gif you see some wall climbing attempts, but no flying, which would be present if the path finder was instead hooked up to the "fly" template.

The reason why I'm doing this super generalized system is that I hope it will allow for more creatures later on. If I get this right, we might reach a point where adding a new species to rain world is easy - I'll just fire up a new template, write the path finding rules and AI stats, and the creature will be alive and path finding dynamically through the world according to its own interests. Seems far away, but we'll get there!

JLJac on June 26, 2014, 07:42:02 AM:

Update 259
I made a little obstacle course consisting of a few rooms to test the path finding in, with a few tricky mazes and other situations I want to try out. Some of the tricky bits are things like having to go through another room in order to get from one place in a room to another, and rooms that have completely non-connected areas that can only be accessed from other rooms. Before I get around to try those things out I have to get creatures moving within the room, though 

Path finding is very slowly, but also kind of surely, moving forward. Today I made a method that checks if a movement between two tiles is legal. The method is outsourced to the individual creatures, and can take weird preferences such as the lizard's aversion for moving backwards into account. I don't quite know if it works yet. It looks like it from the colored dots, but when the lizard is supposed to follow the path it doesn't really behave as I want it to.

I gotta say, my biggest concern with this Unity/C# thing is becoming more of an actual problem when doing complicated stuff like this. I still after learning them don't think my debugging tools can compare to what I had in Director. In Director, whenever it threw and error, it would automatically open the code to the place where it happened, and allow me to look at all the parameters in that object. Here I can just use the debugger to set a stop point, but even then the debugger isn't half as good. I don't get a list of every relevant parameter by default, I have to write their names letter by letter in a little box to see their values. If their values are references to objects, I can't click them to go into that object, which means that if you have an architecture where you divide tasks over many different classes the debugger quickly becomes useless. I can't even view the contents of an array. There's no console where I can try little snippets of code, call methods in my objects or ask for parameters to be traced. In Director I could use the console as a calculator (how exactly does the modulus function work, let's try it quickly in the console) a convenience that I find myself missing. In the end I pretty much only rely on the Debug.Log method for debugging, which clutters my console horribly. Any tips on better debugging equipment?

From how I understand it I can't use the Unity debugger, as the objects in the game aren't Unity objects. Even the profiler doesn't seem to recognize my different methods, it just puts one fat list item for "Rain World Game" 

Despite this stuff being slightly frustrating, I'm making progress. I think I'm sacrificing a little bit of performance in the path finding in the sake of making it general - but that's in line with modern game development from how I've understood it. The computers are fast enough, the logistics of writing the code is oftentimes more important.

That's the good news though - the pathfinding seems to become very generalized and customizable, more than I had dared to hope for!

JLJac on June 26, 2014, 09:13:28 PM:

Oh yeah now that you mention it I totally did notice the locals tab, just forgot about it while writing my rant. I didn't find it until much later than what would be awkward to admit considering it sitting right there, so I did spend the majority of the time typing and mistyping in the watch tab D:


Thanks a lot for the links! Checking them out now

JLJac on June 27, 2014, 06:58:22 AM:

Thanks! I'm glad someone isn't dying from boredom haha!

Update 260
Pretty nice progress! The lizard path finding algorithm seems to be basically working! It's only implemented for a weird flying lizard with no gravity and like 50% air friction, none of the lizard moves (reaching across a gap, dropping from a ledge, turning around) are implemented, the path finding can fire once only and then the game has to be reset, etc etc etc. But it seems like the very basic functionality of saving the path finding matrix as a 3D array and having the third dimension represent direction is down. I've been able to place the lizard in a corridor and ask it to path to behind it, the path finder passed the lizard without it moving, made its way to a point where it could turn or move around something, got back to the lizard, and the lizard started to move. It's able to follow the paths pretty decently, though there is some getting stuck going on.

When the lizard path finding is done, every other path finding is going to feel easy in comparison. The lizard path finding is complex on a level where I can really feel the limitations of my mind, I simply don't have enough working memory to hold an entire situation in my head at the same time. When it gets to that I have two standard solutions. One is to not think but just mess around at random, which never gets me anywhere. After an hour or two of that I resort to the other one, which is bringing out pen and paper and thinking REALLY HARD. It's a weird feeling out there on the edge of one's cognitive ability - you'd imagine that sitting on a chair and thinking couldn't be very exhausting, but it's actually super unpleasant, like working out without having eaten enough beforehand. I have a bunch of coins on my table which I find myself stacking and unstacking over and over instead of focusing on what I'm supposed to.



The trick to this stuff was that it needed to have slightly different validity checks for paths when creating them and when following them, which probably has to do with the fact that the paths are calculated backwards. If I create the scenarios on paper as above and run them backwards and forwards I can see the problems and correct them, but I'm unable to really comprehend and summarize what's happening, which is frustrating.

Despite being a bit unexciting, this week has been very productive! If the rest of the path finding stuff isn't significantly worse, we're better off than I'd thought.

Have a nice weekend! 

jamesprimate on June 27, 2014, 12:54:48 PM:

spot on! youve intuited a bit of what were going to be going for as far as implied / unforced narrative stuff.

its an interesting scenario, because exactly as you say there is a built-in game mechanic that is fairly simple (and fun!), yet has a large amount of possibilities as to how things could potentially play out within the open world were trying to create. we dont want to limit a persons play options to one narrative path just for the sake of "Telling A Story" because you would feel that artificiality, like bumping up against a glass wall: "I want to go here, but a big blinking arrow is telling me to go there." That sort of thing we really want to avoid. So it'll be a matter of baking the potential for scenarios into the structure of world itself and letting the player find their way through that (if they like) by whatever means they can.

We don't want to get too much into specifics (in fact were being pretty secretive about it), because a lot of the fun will be discovering how this happens. Very good question though!

jamesprimate on June 27, 2014, 05:55:21 PM (Last Edit: June 27, 2014, 06:03:26 PM):

now i wouldnt say that we are thinking specifically of discovery as one of the main attractions of the game, but as one way the game *might* be played. there wont be much in the way of blinking arrows forcing you to search through this or that region, so potentially a person could "successfully play the game" a number of times in a number of different ways without ever feeling the need to explore certain regions (or likely even being aware of some of these regions existence!) thats kind of the idea anyways: a large complex world where "the narrative of this slugcat" is just one meandering part. choices will also play an important role, so its even possible that going one direction might make going another direction impossible (or at least very very difficult), one potential action vs another action, that sort of decision tree stuff. these may be pretty subtle too.

this touches a bit on replayability, and again i really dont even want to even allude to too much here because holy cow spoilers, but the idea we are working from in that regard is that aspects of the meta-world and game mechanics might evolve depending on how the player chooses to play the game, so perhaps on the second play-through the world might be ready for your bag of tricks. were thinking of replayability as fairly central aspect, and even having it being tied into the mechanics of the multiplayer.

but this is all quite a bit far off though! as you mentioned before, were still in the nuts and bolts for quite a while yet 

JLJac on June 30, 2014, 08:00:52 AM:

Your ideas line up very well with what we've been talking about, so I think you won't be disappointed

Update 261
Path finding path finding path finding. As I said, this is not going to be quick and easy. Made some progress though - now the embryo of an automatically updating destination for the path finder is in. My goal is that I want to have the path finder completely self-contained. In the end the AI should only need to tell it "I want to go here" and get a very simple response consisting of a statement as to if that's possible and if so what direction to start moving.

I've been thinking a little bit about threading. After looking at a few tutorials I don't think it looks sooo complicated... The idea I'm toying with is putting the path finding in another thread. It would be so very cool to have that basically for free - it would mean much more freedom when it comes to amount of creatures on screen, and would free processing cycles for other stuff such as animation. Also it would make gameplay more fun as the enemies would have faster reaction times...

So I have a few questions about multithreading
1: From how I have understood it, many threads can access the same working memory. The problem with this is that a field might get changed as you do an operation on it, which is where locks come into the picture. My path finding consists of a huge map of cells per creature. If the path finding thread would only write to this map, and the main game thread would only read from it, I would theoretically not need to worry about locks, right?
2: When creating threads, are those automatically placed on vacant processor cores if available, or do I need to manage that somehow?
3: Threading surely brings compability issues, right? Feels like it would.

The other big project of the day was to install Visual Studio to try it out. Something I ended up doing no less than 5 times! I now have like, infinite versions of visual studio and trials on my computer :/ Express doesn't want to hook up with Unity because it doesn't allow extensions, so then I got trials for the pro version (2010 and 2013) but then there were problems with migrating the project... Hm. Having tried nothing but monodevelop and freaking Macromedia director I don't find monodevelop that bad, but people say VS is better, and from the very little I've been able to try it - yeah, it seems really cool.

Then I ran into a price for the pro version if you didn't have any version already, which was at $13 000, which obviously scared me senseless. And then I also saw a thread somewhere that said that if you're developing commercial software on a trial version, you are in trouble. So I haven't really dared to try it after that, frankly. Am I too paranoid? Should I give the VS trial a go?

JLJac on July 01, 2014, 03:32:25 AM:

@dancing dead, thanks a million for the bizSpark heads up! Applied this morning, just waiting for their response :D

@visuar, hi and welcome to the forums! And thank you so very much for your help! Ok, so concern #2 and #3 are not that bad, but with the locks I should take it pretty seriously? I think it would be fine as the reading thread would not read very often, so I don't think the threads would keep each other waiting much. Learning locks it is! I think my approach will be to first just make the pathing work as it did in the old game, then try to migrate it to a multithread solution. It's hard enough to debug etc as it is, so it would be useful to have it at least somewhat working before I bring that whole threading thing into the picture.

Update 262
Today learnt a little bit more about how the monodevelop debugger works while trying to hunt down some weird pathing behavior. It's not as bad as I made it sound, obviously - there's a ton of cool stuff I didn't consider back then because I didn't know it existed. Still in the process of learning it all - Step over, step in, step out. It's not all good though, some stuff still annoys me. I can't seem to examine the contents of a list where the instances are a custom class for example, and it annoys me that a super simple struct such as a Vector2 has to be clicked to have its contents viewed - there has to be some simpler solution. But the more I learn the easier it is.

Also did a thing I should've long ago, a mouse pointer object that displays the mouse position and what tile it's in. I've been putting that off forever, but now I finally took the 15 minutes and did it, which is going to be a huge headache releif in upcoming bug hunting.

Apart from all this debug stuff, I've done some actual work on the path finding algorithm as well. I've reached one of those road forks where you have to pick which problem to start to solve, and with which solution, and it stalls you a bit. In the end I will have to solve all of them though, so I might as well just pick whichever and get started, head first.

In slightly more exciting news I had a bunch of lizards path find at the same time, and it seemed to basically be working. Except it wasn't because the lizard animation/behavior isn't even started on, meaning they're just limp socks being pulled around by the head by a magical force. Meaning that if a bunch of them tries to squeeze into an opening at the same time they get hopelessly stuck. Or if one of them tries to get up or down a slope it gets hopelessly stuck. Or if they try to use a shortcut... they do, indeed, get hopelessly stuck.

When it comes to, for example, creatures getting stuck I tend to resort to cop out solutions such as making them shake around after being stuck for a while, hoping to end up in another not-as-stuck position and angle. Those solutions are nice because they end up saving the day despite the problem being sort of undefined, but this time I will really try to rely on them as little as possible. In the old game I had a mind set where I was always going to release the game in the next 2 weeks, so when I encountered a bug I quite often covered it up like that. I'd cure the symptom rather than the disease.

So say that something was slowly moving to the right but wasn't supposed to, I'd just add a slow leftward force to it and call it a day. Obviously that becomes a huge problem when you don't release the game two weeks later, but these quick fixes start layering up instead. So, this time around I will keep that stuff to a minimum. It will take longer and be more annoying, but the code will be better and most importantly more dynamic. All those little quick fixes tend to act like a layer of rust on the mechanics - they're not in the way until you try to change something, then nothing works and you have to hunt them down and scrape them off again. So, this time I will really make an effort to actually solve the problems, exhausting as it may be.

JLJac on July 02, 2014, 07:39:44 AM:

Update 263
After getting the path finding to a state that could basically be considered "working" yesterday, I decided to take it to the next level today.

This idea was applied to the pups in the old build, but this time I wanted to generalize the concept so it'd be available to all path finding creatures.

Now the path finder is able to find paths that are not actually possible for the creature to follow. Why? Because sometimes you might want to have a behavior where a creature gets as close as possible to a certain place, without actually being able to reach all the way there. An example would be a pup trying to follow you, but there's a gap which it's unable to jump across. Then you want it to walk all the way up to that place where it's unable to get across, and then wait, rather than just not moving at all because the path finder tells it it's impossible. Another example would be if you're on a platform and there's a lizard under it that isn't able to get up to you. In the old build the lizard would just forget about you, but with this functionality it will still try to get as close as possible and hang out in the general area, despite actually getting to you might be futile.

The system also allows creatures to know whether the path they're following is actually going to get them to the goal or not. This info will be usable to the AI - say that you have a lizard camping out under a platform with a player and another player shows up, just next to it. Then the lizard will be able to prioritize the player it actually has a chance to get at, because it knows that the other path it was following was a dead end.

The system works by not only weighting pathing costs as 1D floats, but by having another "legality" parameter to them as well. So if we have a ground dwelling creature that's trying to get from A to B, the path finder will exhaust every possibility that's only passing through ground tiles before starting to path through the air. If exhausting every possibility there as well, it will start to look for paths through solid walls. Once a path is found it will be followed as far as possible.

The system also has a category for moves that are possible, but not preferred. For example the lizard can move backwards, but it will consider every other possibility of getting to the destination first. Another creature might be able to drop from high distances, but have an aversion for it, and so on.

Note that this behavior isn't always going to set in. I'm just making it available for the AI to use. For example we won't have every annoyingly lizard camp out under platforms you're on for ever, bringing the game to a stalemate. In most situations the AI will get tired of that pretty quickly and go look for something else to do. But it's nice to have the behavior available, especially for possible future friendly NPCs.

JLJac on July 02, 2014, 11:32:20 AM:

Hi, glad you like it :D

The game actually evolved around the main character - the "slugcat" as it's been named recently was created and made to move around in a sterile environment to try out the soft puppet animation technique. Then I asked myself what kind of world this creature would live in, and came up with a couple of ideas that are now scrapped, maybe I'll share them some time ... however I settled on the Rain World theme, and here we are!

Yep, the environments are really static. As many things in this project that started out as a technical limitation, but later became a point of the artistic expression if you will - the contrast between the fluid creatures and the static environments is somewhat visually interesting, and there's a reason for it in the "story" (hesitate to use that word as there's no script, we're having more like an emotional narrative going on) as well.

JLJac on July 03, 2014, 02:05:58 AM:

Update 264
Did some trimming, meaning that the path finding matrix shaves off tiles on the sides that are not accessible to the creature. Was told I shouldn't worry about memory too much, but this is a fairly simple measure that saves literally hundreds of path finding cells that would just be sitting there idly, so I'm fairly happy to have it done. If nothing else for peace of mind.

More interestingly I've managed to implement accessibility mapping, as I call it. This is a sub system of the path finder that maps whether each tile is accessible to the lizard. The accessibility has two parameters to it, "can I get to this tile?" and "if at this tile, can I get back to where I am again?".

The first is used by NPCs to dismiss targets that they already know they can't get to without having to run the path finder. When programming the AI later it'll be a huge boon to be able to just ask "can I get there?" for any tile.

The second is used so the NPC won't venture down into some pit where it's unable to get back again. Some times you might want it to venture past a point of no return, but the default behavior should be not to go where you can't go back from.



Here you can see the mapping in action. Blue tiles are "I can get here", red tiles are "I can get back from here" and green tiles are both - these will be the territory of this creature. Reachability and get-back-from-ability are easily calculated by doing a flood fill using outgoing tile connections and incoming tile connections respectively.

You can see how when the creature is held at the bottom of the pit, the level above becomes red as these tiles are possible to "get back from" by dropping down the pit, but not possible to reach. When the creature is held at the higher level the bottom of the pit becomes blue, as these tiles are reachable but not possible to return from.

What triggers the accessibility mapping is simply being in a tile that is flagged as either unreachable or beyond return. Then the creature assumes that it's been moved out of its territory by an external force, and starts reconsidering its surroundings.

Get-back-ability is currently calculated after reacability. As the reachability is mapped every tile is actually flagged as possible to get back from... I think this could be a fun detail - as a creature is momentarily confused by a change of environment it's actually possible to trick it into a pit or something. This is easy enough to change though, some creatures could play it super safe by immediately on exiting their comfort zone mapping the entire world as inaccessible, and then just add tiles as they're sure to be double-safe.

This whole behavior is handled by a sub-class in the path finder class, of which an instance is created on re-mapping and then destroyed as the mapping is done.

The next big pathing hurdle is going to be inter-level pathing. I have the idea pretty clearly laid out, and actually most of the infrastructure as well. For example, on birth a creature will create a set of pathing nodes for the off-screen abstract rooms already, I just have to utilize those. Stay tuned!