next »

[Slader16]

Woah, that's crazy! It looks so similar!

[JLJac]

Wow that's really awesome! Ghost cats :D

Yeah, as James said, right now we're concentrating on making it before porting it, so it might be a while :S

Update 271
Alright, moving between multiple loaded rooms done!



In the gif, when you see the tiles up above the pit turn blue, that's me setting a destination. The lizard (pink cubes) has to make its way up there! Then the gif shows it as it's moving through multiple rooms in order to reach the destination.

Let's take a closer look at what's happening when you enter a room:



Notice how there's a path that's already there, and then it starts to swell out all over in two waves? When entering a room, the quickPathFinder - of a couple of pages ago fame - kicks in. It looks at all the neighboring rooms, checks which has the lowest pathing value (closest to the target) and makes a quick and dirty path to the corresponding exit.

The thing with quick paths is that they're made to be quick to calculate, not necessarily the most effective way to get there. Though they might be, if the maze is very simple. Anyhow, the quick path algorithm finds a quick and dirty way to the next exit, because the lizard should have something to follow right away when it enters the room. As it goes the real path finder will catch up with it, and it'll get a more reliable path, but the quick path is good enough to follow for the first couple of tiles.

As you might have noticed the accessibility mapping swells out from the quick path. This is because these tiles are already set to accessible when the level starts, and need to continue to be so as the accessible area is mapped, or the creature might stop in its tracks. Because of that I've fed all of the quick path tiles into the accessibility mapper as starting tiles.

Once the two layers of accessibility (reachable/possible to get back from) have been mapped, the path finder is told to create a new pathing generation, just like it would when chasing a target inside the room. But this time, it's the off-screen goal that's assigned. The path finding algorithm will search throughout the network of abstract rooms, and find its way to the current, realized room, where it will start flooding the tiles from the correct exit. In the gif this can be seen as purple, if you look closely.

Once the creature starts to follow this path, it stops calculating and just goes along - until reaching the next room, when the procedure is repeated.

One thing that was difficult in this was that when the creature is leaving the room where it's destination is, the destination needs to be translated from "tile space" to "abstract node world-map space". I solved this by partly using the quick connectivity check I threw together a couple of days ago, partly just checking straight distances to doors. It has been working OK, but the connectivity check is super expensive, so I'm thinking about more optimal solutions. No noticeable hickup though, so it might work just fine.

[gimymblert]

I was wondering, could not you pre process the path to only retain waypoint with more than 2 neighbor? Path finding on a straight line (two or less neighbor) is trivial as decision only occur at fork (3 and more neighbor). You might only have 3 primitives, waypoints (string of tile), caps (dead end tile) and forks (where decision happen), even storing which of the branch is a dead or not ... something like that. So it won't have to check and store all the tile that does not contribute to decision (waypoints and caps).

[JLJac]

Yep, that's true. The thought crossed me that each segment of a corridor could be made to one big, rectangular cell, or similar solutions. In the end I decided to keep to this solution as the connections between different tiles are on the tile level, and because the path finder is not only supposed to be able to find a legal path to a legal position, but also the closest you can get to an illegal position. If you were to only map the corners, or some similar solution, it would be kind of unclear how mapping illegal space should tie into that, which is why I've kept it simple. But if performance issues start to pop up, I'll definitely reconsider it!

Update 272
Sorry guys, this is not gonna be an exciting one.

Averted a number of null reference exceptions that would happen because some coordinates were not properly migrated from tile space to node space on exiting a room.

Changed it so that instead of connecting a tile of the realized room to a node in the next room through an exit, the tile is connected to the node in the same room, which is then in turn connected to the next room. Ie it doesn't bypass nodes in the realized room any more, which is cool for a number of reasons, one of which is that it'll help later when I come to giving creatures cozy little holes to crawl down and hibernate in.

Moved the quick connectivity mapper to a static class, making it accessible from everywhere.

When deciding which exit a coordinate is closest to, in order to convert it to node space, I check both if it's possible to get from the coordinate to the exit and vice versa, hopefully giving a slightly better representation of tile coordinates in node space.

Etc etc etc.

Basically I've been cleaning stuff up. I tend towards working like that - first I just go in there and massacre the problems in whatever way possible, then I go over the solution and tidy it up. By now I think the path finding is actually solid enough to start moving on to either embryonic AI (keeping track of where I want to go, having a few modes of behavior to finite-state-machine between) or abstract creatures (creatures in a super-simplified state as they are outside of the currently loaded world), perhaps both. Abstract creatures also need some AI, such as a basic idea about "where am I going?" and "what am I doing?" to be able to know if the current behavior is "hunting" or "retreating to hole because of approaching rain". For this reason it might actually make the most sense to have these two next problems be one, and integrate the most basic aspects of AI with the super simplified creature.

[Vesper]

This game looks so amazing! Just found it a couple days ago! Can't wait for the release! Good Job!

[jamesprimate]

did an update for the kickstarter crowd focused on pathfinding: https://www.kickstarter.com/projects/rain-world/project-rain-world/posts/914855

if you've been reading the devlog it'll be nothing new to you (im totally just paraphrasing what Joar has done the past few pages), but I tried to make it relatable to an audience that might not be as knowledgeable on the subject as you dudes. 

[JLJac]

Update 273
Ok, so on to the next task! Today I've created a class for abstracted creatures, and made them able to move around between rooms. They're also contained in little lists in the abstract rooms, and receive updates.

Each abstract room has one "node" per exit. Abstract creatures keep track of which such node they are "in". The quotation marks on that last one is the complicated bit. A node doesn't really symbolize a specific area of the room, rather all the nodes tend to share most of the area of a level. Take a look at this room:



This room has three exits, and therefor three nodes. Let's call the top left one A, the upper right one B, and the one down in the pit C.

So, from A you can get to B, from B you can get to A, and every tile you can get to from A you can also get to from B. So it's not as simple as saying that a certain group of tiles represent a certain node. Rather nodes symbolize goals and destinations.

Now imagine that this room is offloaded, and represented solely with its nodes.

Remember how I told you that the game has mapped how to get from every exit to every exit for every room as every creature? That info is used here. Say that a creature enters from the left exit. It's position will now be set to this room, and node A. Each creature has a timer for how long it has been in that node. When it moves the timer is reset.

The creature also know where it wants to go next, in this case let's say out the exit C. The pre-baked mapping knows the distance between the two exits, so in the abstracted space it's very simple - once the creature has been in node A for a time that is long enough to correspond to that distance times a movement speed, it switches to node C. Then the timer resets, and the same procedure repeats for the next destination. This way the creatures move between nodes with a speed that corresponds to the actual tile-level distances between them.

The roaming behavior I have currently set up looks at what node a creature is in, and looks at exits for adjacent rooms. It can only go to nodes that are mapped as reachable, and also only follows paths that can be followed back, in order to not get stuck in a dead end. So say that the creature is in node A, then its next move can either be to move back out through the exit A, or the exit B, but not C as it won't choose routes where it can't get back. If it is in node C, its only option is to return out through the same exit.

The framework also allows for saving paths, meaning that creatures can have more deliberate movements throughout the world as well. An obvious example of this would be getting back to their dens when the rain gets closer. I imagine that it would be kind of cool to suddenly notice a lot of traffic of creatures through your room as they are all scurrying back to their respective dens.

In the future, if you were to walk into the room while the creature is moving from A to B, it'll just use the timer to place the creature at a certain point along the path between the two exits. That way you'll be able to walk in on a creature in the middle of traversing a room.

What I'm working with now, is having the creatures transition seamlessly between abstracted and realized modes. Say that you are in a room, hidden. Then you should be able to see a lizard come in through one exit, pass through the room without noticing you, and continue out the other. This means that the lizard has to change from abstracted to realized back to abstracted again, with some parameters remaining intact. More on this tomorrow!

[JLJac]

Update 274
So now I have the basics down for the abstract creature framework, and am trying to connect it all together, so that creatures can move seamlessly between the two states of abstraction. However it also means that I have to re-structure quite a lot of the stuff handling things such as how rooms are loaded and the like.

I'm actually building some very fundamental infrastructure for the game here, so it takes a little thinking. Right now my basic idea looks like this:



Each of the areas is a level of abstraction. The very core of a creature is the top left cell, to which the other components are attached according to the nature of that creature and the level of abstraction.

An example of how a command might move through this infrastructure is when a creature with an AI addon (the player for example doesn't have an AI, meaning that the entire right column is absent) is given a new destination. This is handled from the top level - the abstract AI, and then the command is passed down to the AI and the path finder in turn. Processes in the AI are going to change the destination a lot, but each time the new destination will walk down this entire hierarchy - that way, when the room is suddenly abstracted and everything on the realized level is thrown out, the destination will still have survived in the abstract AI, which remains.

[Christian]

I know others have said it before, but after reading about the crazy situations going on with that Yogscast campaign and the Areal campaign, it's worth repeating. I really appreciate how much effort and dedication you put into keeping us updated on Rain World's progress. Not just as a fan of the game, but as a backer as well, this is easily my favorite game to follow. I can't think of any other campaign I've backed that can boast such detailed and near daily updates

[JLJac]

Thank you :D

Update 275
Similarly to how the human brain has its inner part, the reptile brain, and the surrounding cortex, the idea is that the rain world creatures will also have two levels of intelligence where the more complex works as an addon to the constant more static part. In rain world it's not going to be human level and reptile level though, rather like... Reptile and aemoba... Anyhow, the idea is that in the simple, abstracted world the creatures will make simple, abstracted decisions. When the environment is realized at tile level, the AI should get a more powerful component as well, to match it.

Today I've been having a bit of a conundrum. Here are the options I'm choosing between:

A - reptile brain keeps control always, and when the reptile brain decides on something ("let's hunt!") that command is passed down to the complex brain, which refines it into more complex behavior ("i'll go to this and that particular tile, etc etc"). This is cool because it makes the creatures behave generally the same regardless of if they're abstracted or realized, which gives them truer autonomy.

B - reptile brain controls the creature when abstracted, but when the creature is realized the complex brain takes the wheel completely. It still uses the simple brain for storing destinations etc, meaning that if the creature is suddenly abstracted those essentials will remain for simple brain to use, but while the complex brain is running the simple brain is not allowed to execute any behavior. This is cool because it's cleaner - two different solutions instead of one gooed together, and because it means that the complex brain isn't held back by the simple one as it can do its own thing without relating to the abstract behaviors.

Hmmmmm... I'm really unsure about this one actually! Which one seems the cleanest and easiest to work with to you guys?

[jamesprimate]

Joar is going in deep with the Plato / Heidegger stuff!

Is there any advantage you can see from either of these over the other one in terms of easy of execution or processor strain? I like A simply because it sounds cooler, and i dont think keeping abstracted "personality" is such an issue (as the player will be unaware of it either way.)

[Slader16]

Even though I'm a programmer, I usually avoid giving my opinion when it comes to the technical side of things. But in my opinion, "A" sounds like the best choice. Despite the fact that the player won't notice it, it adds life to the lizards. 

[Vesper]

This game looks so amazing! Is it going to have to be bought?

[Slader16]

This game looks so amazing! Is it going to have to be bought?

[Christian]

This game looks so amazing! Is it going to have to be bought?

As an avid IOS gamer, I can say that comic is painfully true. Can't count how many times I've see comments like that. That mentality really hurts IOS devs

[jamesprimate]

i think its going to be $900.00 retail

[Slader16]

i think its going to be $900.00 retail

Sounds legit 

[Vesper]

I'd buy.

[Fuzzy]

This Game Looks so cool!
I'd go with A for the lizard's brain.

[JLJac]

A you say... Hm - in that case I'll have to do a little bit of thinking. I don't want the abstracted creature to be too heavy, as the very point of it is that hundreds of them should be able to run in the background as you play. But maybe there could exist a thing that goes over the abstracted creatures one by one and create "fake events" for them to react to - such as "hearing prey" which changes the mode from "idle" to "searching" for example. When the creature is actually loaded, this fake event engine would be replaced with the actual events of the room. Which would actually be a little bit of solution B I realize when writing this, but would perhaps hit the sweet spot between them. More on this later!

Today and probably tomorrow I'm making a website for our company, Videocult, which is necessary to get across some business hurdles. One of those is getting approved for the Bizspark project and receive a Visual Studio license, so that's going to be a nice boon for the development process. But until then, there might not be real devlog updates - so see you guys in a day or two!