next »

[JLJac]

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!

[gimymblert]

Are you cross posting on unity forums? I think you should, you are likely to stretch teh expertise you can find in this thread and forums as you deal more and more with unity/c# subtleties ...

[besttof]

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?

Hey, I feel like captain obvious here but did you look at the locals tab while debugging? It sounds like you've only use the (selected by default) watcher tab. It allows you to inspect arrays, objects, etc. etc. the thing is that you might need to dig deeper than you'd expect for some contents...



As for the console code execution: One of the nice features in NIck Gravelyn's Unity Toolbag is an immediate mode window which can also be very useful for programatically editing your actual scene https://github.com/nickgravelyn/UnityToolbag. Another useful code scratchpad is http://rextester.com/runcode which is nice for general c# stuff.

Hope that helps (and I didn't state the obvious or maybe overlooked something  )

[JLJac]

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

[deab]

Love the detailed  posts, fascinating stuff.

[JLJac]

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! 

[tortoiseandcrow]

I know you're knee deep in the nuts and bolts of porting the code, but I find myself really curious about your larger scale plans. Can you talk a little bit more about the structure of the singleplayer game? It seems like the rhythm of hunt/find shelter/hunt/find shelter could be really fluid and exciting if left relatively open-ended, or become stale and stilted if made overly linear.

I ask, because what makes me excited about the game is the thought of these emergent narratives that result from being dropped into this world and being left to survive and take care of the pups. I find myself imagining what it would be like to emerge from short hibernation to roam freely and hunt, trying not to get eaten, and then desperately attempting to find the closest shelter when the rain threatens to come. I imagine over-estimating my time and having to take shelter elsewhere, becoming separated from the pups and hoping they have enough food to last until I can return. I imagine my primary shelter becoming unsafe (flooding, perhaps, or the threat of a tunnel collapse), and having to make the treacherous journey with the pups between one shelter and another.

While this may not ultimately be the game you imagine yourself, it seems that an open-world game with multiple shelters, an unpredictable (though perhaps roughly estimate-able) rain timer, and randomized state changes with regards to the security or viability of a shelter are well within the boundaries of the mechanics you've devised so far. Basically, what I find myself wanting is a "Parenting Mode", where you navigate a large non-linear level with the goal of keeping the pups safe and fed until they grow up over the course of many rain-cycles. The drama and narrative pull of such a play mode is pretty much built in, and instantly compelling to me. Even dying or losing all the pups is a story in itself. Is a game-type of this nature at all a possibility (either built in, or through the level editor)?

If not, what are your plans for mod support?

[jamesprimate]

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!

[tortoiseandcrow]

I'm glad to hear you talk about the open nature of the world, as well as the emergent nature of the mechanics (often the simplest rules yeild the most sophisticated games). I guess part of what I'm interested in is the possibility for multiple replays. If you dropped me randomly in a world with some aspect of the levels dynamically changing and said "protect these pups", I'd play that game pretty much forever. While I absolutely get that the way the AI is programmed makes every playthrough really dynamic and different each time, I can't help but think about how that incredibly pleasurable process of discovery is often kind of a once-off thing (there's only so many time I can play the same damn level in the same damn order, no matter how much the minutia of the way the enemies behave is different). I don't want to insist on the increasingly trendy procedurally generated "rogue-like" level model or what-have-you, but if discovery is one of the main attractions of the game, I'd really like to be able to discover it anew a couple of times. Without pressing for details, is that something you guys are planning for?

[jamesprimate]

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 

[tortoiseandcrow]

Well, even this is very exciting to hear! Glad to know that this is something you guys are actively thinking about. Certainly just reading this dev-log I get the sense that the difficulty of a solution is barely a factor in whether it gets implemented, so I'm incredibly curious to see what you guys end up ultimately doing. I'll sit tight and enjoy the log until the game is done.  

[JLJac]

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?

[dancing_dead]

if you have a company or something established, google "biz spark", apply, and get your free, legal visual studio pro. contrary to popular beliefs, Microsoft is not actually (pure) evil

don't have enough experience to comment on multithreading, except, do you really need it? haha, but no, ignore that, multithreading is useful knowledge anyway.

[visuar]

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.

I'm assuming you are doing C# with Mono from.

1: use a lock if any memory access between threads is read/write or write/write. Otherwise it's extremely easy to get things to go wrong horribly. Read/read does not need a lock. There are optimizations possible (read up on intrinsics), but if you've never programmed threads before I would start with locks to keep it simple. C# makes threading a breeze, but things get more complicated with Unity, from what I've seen (all the Unity stuff needs to run on the main thread I believe). Depending on your code you may want multiple locks for different variables / structs / lists / queues etc. so as not all threads are fighting over the same lock. The shorter you keep a lock the better. You would not need a lock if the pathfinding thread does it work creating the map, then signals (event) the main thread the work is done and only THEN does the main thread read the data (ie, it waits for the pathfinding thread to be done).

2: the Operating System schedules those automatically, don't need to do anything. For very high performance scenarios you may want to lock a thread to a certain core, but there should be no need for you.

3: if you use Mono + C# you should not need to worry about this. That's the nice thing about using a setup like that   In language like C/C++ you definitely do, but it's not really complicated.

Writing good multi-threaded code is an art form and experience helps a lot, but you got to start learning sometime.

Visual Studio Express should be fine, as I'm sure you can set up Unity to simply open the project & .CS files inside Visual Studio. Quick Google search found this:
http://forum.unity3d.com/threads/unity-visual-studio-express-2013.205671/

Also price for Pro seems to be $499: http://www.microsoftstore.com/store/msusa/en_US/pdp/Visual-Studio-Professional-2013/productID.284832200

Hope some of this helps!

I'm new here and must say your game looks awesome and have enjoyed reading your dev log! Can't wait to see where this goes.

Rob

[JLJac]

@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]

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.

[Toastie Republic]

Dude, everything has so much personality. For the characters its the animations that really bring them to life. The world is pretty stagnant comparatively, but I'm guessing that's intentional. Really awesome stuff

Did the game evolve from mechanics or just like a small idea? I'm curious as to what inspired the game since it's one of my favorite combinations: simple but compelling.

[JLJac]

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.

[Toastie Republic]

Awesome!

Well I wish you a speedy development and the best of luck.

I'll be watching :]

[JLJac]

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!