JLJac









Level 10 Project Rain World « on: March 24, 2012, 12:44:52 PM »



Out and available on playstation and steam!





Rain World is a survival platformer set in an abandoned industrial environment ravaged by a shattered ecosystem.



Bone-crushingly intense rains pound the surface, making life as we know it almost impossible. The creatures in this world hibernate most of the time, but in the few brief dry periods they go out in search of food.



You are a nomadic slugcat, both predator and prey in this land. You must hunt enough food to survive another cycle of hibernation. Other — bigger — creatures have the same plan.











The gameplay of Rain World consists of fast paced sneaking and action. The enemies are incredibly difficult (though not impossible) to defeat through direct confrontation. Instead of being easily killable they have been made intelligent enough to be interesting opponents in stealth situations.



Ironically an entity that is stupid enough can be difficult to outsmart. The goal of the Rain World enemies is the opposite of that, being smart enough to be outwitted. This is why a lot of the development has been put towards AI. It makes for interesting situations where you get to measure your wit against an enemy that it's actually satisfying to trick and deceive.



Apart from AI, I have had a lot of fun experimenting with procedural animation. The creatures of Rain World are not animated by traditional means, but rather consist of a few freely moving pieces that are interconnected and rendered as a soft body.





Alongside the game I've been working on a stand alone level editor, which uses a voxel-like method to create graphics. The levels are collages of hand-drawn elements, molded together by filters into one coherent graphic.





For the music and soundscape of Rain World, I have the excellent



If you find the project interesting, please feel free to ask, suggest, comment or otherwise contribute. For those of you who are interested in technical stuff, feel free to plough through the devlog! Below follows the original first devlog entry from 2012.



Thanks for your time!



Rain World is now











Hi! Maze Runner is of course a working title.



A while ago I posted a







I haven't started on the visuals yet, and the game will probably look very different from this screen shot, but the movement of the player will be mostly the same.



I decided to start a dev log to keep track of my progress and keep myself motivated. I work at the game at a low but steady pace, and will hopefully be able to post updates every so often.



The Game

Try out the



The game will have three types of creatures in it. I won't go in to detail on how I plan to design them visually, that's not entirely worked out yet and will hopefully be an exciting surprise. Together the creatures will form a little eco system, where creature B eats creature A and creature C eats creature B. B, the player, is in the middle of this food chain, and the gameplay will consist of trying to hunt while at the same time avoiding to be eaten.







A is a flying creature, that can move quickly and reach every part of the map.



B, let's call it "the Bear" because of its ears, is a running and jumping creature, with medium mobility and probably also access to most of the map, as maps will be designed mainly from this creature's perspective. This is the player avatar in the game world.



C, let's call it "the Croc" is a crawling, climbing creature that can't jump, and is somewhat less mobile than the bear. This one will come in a few sub-species, some of which will be capable of wall climbing, increasing access the different areas of the map. They will have different stats and abilities and be threatening in different ways.



The game will work with one or more players sitting at the same computer. I like 2D, single screen multiplayer games as they according to me have all the feats of a board game as well as those of a computer game. The players have complete overview of the play area, and can shout stuff at each other while interacting in the game world. However I felt that my last game lost a bit of its potential audience due to being multiplayer only, so this one will be playable alone as well. The players will be playing against the computer units, but some competive elements might be doable as well.



The level editor

I love level editors, and especially did when I was a kid and couldn't really make actual games myself. I've been doing some work on the level editor already, and it seems to be coming together nicely.







It's fun to make and play levels together with friends, and I've made the level editor so that two or more people will be able to work at the same level simultaneously.



What's going on right now?

AI, AI and more AI... path finding, to be specific.







To be even more specific, it's the path finding of unit C that's a hassle. Thing is, C is not supposed to be able to reverse. Unless it's really stuck it should move forward, trying to find a way that doesn't require moving backwards into its own body. As anyone who has worked with an A* knows the main thing is crossing out tiles, like "OK, this one is checked, now I don't have to think about it again". But, if this unit is moving to a target behind it, it has to start moving away from the target until it finds a turning place, and then move back over the same tiles towards its target.



This is difficult, especially as even a conventional A* can be a sort of complicated matter... And yeah, both the start and goal positions are constantly moving and I can't afford to calculate the entire path in one frame, so it has to be realtime... And different crocs have access to different tiles... This has been, and is, very very hard. However, I'm starting to see the light at the end of the tunnel, which is why I'm going online with this now. Hopefully from now on every single update won't be about croc path finding, as it would if I started two weeks ago.



The combination of giving the user access to a level editor and having autonomous units moving around in the environments is an interesting challange. I don't want the user to be required to place "flags" of any sort, you're supposed to be able to simply create a level and then have the units move around in it in a sensible way. Moving around without reversing, that is... Well, enough on that.



The development so far has been very technical, and will probably continue to be for a while, but I'm originally an art guy and I'm much looking forward to creating some juicy sounds and visuals for this.



I hope you find the project interesting, and am looking forward to your comments, suggestions and questions.

Thanks for your time! The gameplay of Rain World consists of fast paced sneaking and action. The enemies are incredibly difficult (though not impossible) to defeat through direct confrontation. Instead of being easily killable they have been made intelligent enough to be interesting opponents in stealth situations.Ironically an entity that is stupid enough can be difficult to outsmart. The goal of the Rain World enemies is the opposite of that, being smart enough to be outwitted. This is why a lot of the development has been put towards AI. It makes for interesting situations where you get to measure your wit against an enemy that it's actually satisfying to trick and deceive.Apart from AI, I have had a lot of fun experimenting with procedural animation. The creatures of Rain World are not animated by traditional means, but rather consist of a few freely moving pieces that are interconnected and rendered as a soft body.Alongside the game I've been working on a stand alone level editor, which uses a voxel-like method to create graphics. The levels are collages of hand-drawn elements, molded together by filters into one coherent graphic.For the music and soundscape of Rain World, I have the excellent James to rely on.If you find the project interesting, please feel free to ask, suggest, comment or otherwise contribute. For those of you who are interested in technical stuff, feel free to plough through the devlog! Below follows the original first devlog entry from 2012.Thanks for your time!Rain World is now Kickstarting! Hi! Maze Runner is of course a working title.A while ago I posted a movement prototype in the feedback section. Since then I have worked some more on the project, starting to turn it into a game.I decided to start a dev log to keep track of my progress and keep myself motivated. I work at the game at a low but steady pace, and will hopefully be able to post updates every so often.Try out the prototype to get a feel for what kind of basic mechanics I'm working with. More on that to be found in the old thread. More moves are to be added, such as balancing on poles, maybe some gripping mechanics, stuff like that. The core of the game is the movement of the player character in the environment.The game will have three types of creatures in it. I won't go in to detail on how I plan to design them visually, that's not entirely worked out yet and will hopefully be an exciting surprise. Together the creatures will form a little eco system, where creature B eats creature A and creature C eats creature B. B, the player, is in the middle of this food chain, and the gameplay will consist of trying to hunt while at the same time avoiding to be eaten.A is a flying creature, that can move quickly and reach every part of the map.B, let's call it "the Bear" because of its ears, is a running and jumping creature, with medium mobility and probably also access to most of the map, as maps will be designed mainly from this creature's perspective. This is the player avatar in the game world.C, let's call it "the Croc" is a crawling, climbing creature that can't jump, and is somewhat less mobile than the bear. This one will come in a few sub-species, some of which will be capable of wall climbing, increasing access the different areas of the map. They will have different stats and abilities and be threatening in different ways.The game will work with one or more players sitting at the same computer. I like 2D, single screen multiplayer games as they according to me have all the feats of a board game as well as those of a computer game. The players have complete overview of the play area, and can shout stuff at each other while interacting in the game world. However I felt that my last game lost a bit of its potential audience due to being multiplayer only, so this one will be playable alone as well. The players will be playing against the computer units, but some competive elements might be doable as well.I love level editors, and especially did when I was a kid and couldn't really make actual games myself. I've been doing some work on the level editor already, and it seems to be coming together nicely.It's fun to make and play levels together with friends, and I've made the level editor so that two or more people will be able to work at the same level simultaneously.AI, AI and more AI... path finding, to be specific.To be even more specific, it's the path finding of unit C that's a hassle. Thing is, C is not supposed to be able to reverse. Unless it's really stuck it should move forward, trying to find a way that doesn't require moving backwards into its own body. As anyone who has worked with an A* knows the main thing is crossing out tiles, like "OK, this one is checked, now I don't have to think about it again". But, if this unit is moving to a target behind it, it has to start movingfrom the target until it finds a turning place, and then movetowards its target.This is difficult, especially as even a conventional A* can be a sort of complicated matter... And yeah, both the start and goal positions are constantly moving and I can't afford to calculate the entire path in one frame, so it has to be realtime... And different crocs have access to different tiles... This has been, and is, very very hard. However, I'm starting to see the light at the end of the tunnel, which is why I'm going online with this now. Hopefully from now on every single update won't be about croc path finding, as it would if I started two weeks ago.The combination of giving the user access to a level editor and having autonomous units moving around in the environments is an interesting challange. I don't want the user to be required to place "flags" of any sort, you're supposed to be able to simply create a level and then have the units move around in it in a sensible way. Moving around without reversing, that is... Well, enough on that.The development so far has been very technical, and will probably continue to be for a while, but I'm originally an art guy and I'm much looking forward to creating some juicy sounds and visuals for this.I hope you find the project interesting, and am looking forward to your comments, suggestions and questions.Thanks for your time! « Last Edit: May 13, 2017, 12:09:58 PM by JLJac » Logged

Alex Norton







www.msoa-game.com





Level 0www.msoa-game.com Re: Maze Runner « Reply #1 on: March 24, 2012, 04:39:24 PM » This actually looks quite cool. I'm not even sure the graphics NEED an update. Those cat-ghost things look creepy and cool! Well done! Can't wait to see some videos of this! Logged

The Infinite RPG

www.msoa-game.com Malevolence: The Sword of AhkranoxThe Infinite RPG

JLJac









Level 10 Re: Maze Runner « Reply #4 on: March 25, 2012, 01:59:38 AM » Thanks! I hope you'll like the final visuals even more!



Update 1

I have worked a little with the Croc's movement, the physics of its body. Earlier I've mainly been working with the path finding, now I'm moving over to how it will animate when following those paths. Cleaned up a few situations where it would get stuck, and made it so that if it is, for some reason, cornered in a dead end it will swallow its pride and slowly and awkwardly back out again. Also identified a... path finding error... -.- Will get to that later.



Another three hours or so I've spent struggling with the eldrich horrors of recording, trimming and cropping a little gameplay video.



This seems to be in the same category as printers, a seemingly menial task that for some unknown reason coheres with an undescribable, inherent blind spot in human engineering, making it about a bazillion times as difficult as it has to be. Nothing can ever, under any circumstances, just simply work... Well, I'm out of patience, maybe tomorrow there will be a vid.

Logged

RayJack







Level 0 Re: Maze Runner « Reply #5 on: March 25, 2012, 05:12:45 AM » The "food chain" element is pretty interesting. What does the little flying thing eat? It would be pretty cool if there were little patches of moss on some walls that the A creature wants to go eat, but maybe that would be too easy for the player.



The first thing I thought of when you mentioned same-screen multiplayer is "man it would be cool if you could each pick a different creature and try to eat/evade one another" but thinking about it for more than a few seconds makes me realize that would be pretty boring because unless you are the B creature you only have one goal (either eat or evade). But a co-operative game between a flying A creature and a crawling C creature would be cool, you'd have to work together to lure the computer-controlled B creature into the C creature's mouth without letting it eat the A creature.



N E WAIZ



This game looks cool and I'm watching it. =] Logged

JLJac









Level 10 Re: Maze Runner « Reply #6 on: March 25, 2012, 01:07:51 PM » Haha! Yeah, the idea is that a food chain of three is the smallest possible where one unit can be both hunting and hunted, making for an interesting situation for the player. I could possibly make the other units playable as well, but, as you said, the gameplay as those would be more one-sided. Creature B can't really be computer controlled though, download the prototype to see for yourself why... Way too complicated movement for an AI to handle :O



I was also thinking about some plant or something for creature A... Stick around and we'll see what happens!



Update 2

Made the speed of the croc variable, across different sub-species and different terrains. For example, one could be a quick runner but a slow climber, while another one has other stats. Gravity now affects the croc, and its body has some substance so that the body parts won't collapse into themselves (as much). Path finding seems to be working nicely now, I haven't seen it getting stuck for a while. What needs work though is the behaviour when it's thinking about a path but doesn't have one yet, it should probably slow down while thinking stuff over instead of rushing around at random. Logged

RayJack







Level 0 Re: Maze Runner « Reply #7 on: March 25, 2012, 01:28:39 PM » Quote Creature B can't really be computer controlled though, download the prototype to see for yourself why... Way too complicated movement for an AI to handle :O

I'm on a Mac =\



Could you post a video? I'm on a Mac =\Could you post a video? Logged

Jay Tholen









Level 1 Re: Maze Runner « Reply #9 on: March 25, 2012, 05:46:53 PM » Oh man, that little prototype thing was rad. A fun element to consider may be the ability to swing/hang from things. You know, chandeliers or ropes or vines or what have you. Definitely keeping an eye on this. :0) Logged Dropsy!



Hypnospace Outlaw - You're a cop/moderator of the future-internet, which looks suspiciously like Geocities. Also you have a sweet car. Hypnospace Outlaw - You're a cop/moderator of the future-internet, which looks suspiciously like Geocities. Also you have a sweet car.

JLJac









Level 10 Re: Maze Runner « Reply #10 on: March 25, 2012, 10:43:37 PM »

(Silent, no need to pause your music!)



Jay Tholen, been thinking about stuff like that as well, such as a chain or ring on the wall that's grabable... Stuff like this is fairly easy and fun for me to add, so there'll likely be some more stuff like that in there eventually!



Thought I'd do a super quick overview on "no reverse path finding", if someone else would be in a similar situation. It's an overview of the genereal idea, not a step-by-step how-to, but if someone wants more detail I'll provide it!



So this is how most path finding works:







The red dot wants to get to the green dot. You start at the goal, and make a "bucket fill" outwards, and for every step you save how many steps that specific tile is from the green dot. Once you reach the red dot, it can follow the path by each frame moving to the neighbour with the lowest score. An A* is basically the same thing, but you check tiles that are in the right general direction first instead of spreading out equally in all directions, making for a more quickly found path in most situations. This is of course an entire field of science, and there's much to read on it out there.



In my situation, however, the red unit is not supposed to be able to move backwards. That's OK in most situations, but what if the goal is behind it? In some situations it might be able to "walk around the block" and reach the goal from behind, you could create such a solution by simply blocking the tile behind the red dot (treating it as a wall) and going at it with the conventional method. Eventually the spreading numbers would reach the tile directly in front of the red dot, and it would be able to make a lap around and get to the green dot.



If this is not possible, then? Say, for example, that the green dot is behind the red dot, and the red dot is facing a corridor that's later widening up enough for it to turn around. In this situation it should go forward, turn, and then pass over its old position again to reach the green dot. Tricky!



The trick is to divide every tile, one sub-tile for each direction. This means that a tile can have one value in one direction, and another in another direction, like this:







The red dot's start tile is very close to the goal if facing left (2 steps away) but very far from the goal if facing right (10 steps).



Look closely at the green numbers and you can see in what pattern they spread. According to this pattern every sub-tile will have a value that is one less than the tile it's pointing towards. That's because when the numbers spread to a new tile they spread to the subtile that's pointing backwads to where they spread from. If that makes any sense... Just look at the numbers ;P



When the red dot is in a specific tile it doesn't ask the neighbours for their values, instead it asks the sub-tiles. It does not, however, ask for the sub-tile that indicates a direction opposite to its own. This means it has three options every frame: forward, left or right, but not reverse. Then it just moves in the direction with the lowest value, exactly like the standard solution up there.



Voila, you have a behaviour where the path finding will intelligently either "walk around the block" or find its way to the closest turning point and back, depending on what's more efficient, shorter or otherwise preferable.



In my game this is meant to create some fun and interesting situations. One such might be that you jump over a croc, but the croc runs forward, climbs up on something, climbs out to directly above you, then drops down on you. Another scenario could be that the croc has momentum and can't stop, so it runs into a narrow corridor where it has to solve a little maze looking for a turning place or another way out, to get at you again.



Hopefully this will make the game play more interesting! Let me tell you, it has to be real good to be worth it... The example above is very theoretical, doing the same thing in a more "real" (complex, that is) environment has been... Try it out if you like a challenge! Working on a video! Just that screen recording software is such a damn hassle ... Here's a horrible little video for you in the meantime: http://www.youtube.com/watch?v=FbAhRjsXBko&feature=youtu.be (Silent, no need to pause your music!)Jay Tholen, been thinking about stuff like that as well, such as a chain or ring on the wall that's grabable... Stuff like this is fairly easy and fun for me to add, so there'll likely be some more stuff like that in there eventually!Thought I'd do a super quick overview on "no reverse path finding", if someone else would be in a similar situation. It's an overview of the genereal idea, not a step-by-step how-to, but if someone wants more detail I'll provide it!So this is how most path finding works:The red dot wants to get to the green dot. You start at the goal, and make a "bucket fill" outwards, and for every step you save how many steps that specific tile is from the green dot. Once you reach the red dot, it can follow the path by each frame moving to the neighbour with the lowest score. An A* is basically the same thing, but you check tiles that are in the right general direction first instead of spreading out equally in all directions, making for a more quickly found path in most situations. This is of course an entire field of science, and there's much to read on it out there.In my situation, however, the red unit is not supposed to be able to move backwards. That's OK in most situations, but what if the goal is behind it? In some situations it might be able to "walk around the block" and reach the goal from behind, you could create such a solution by simply blocking the tile behind the red dot (treating it as a wall) and going at it with the conventional method. Eventually the spreading numbers would reach the tile directly in front of the red dot, and it would be able to make a lap around and get to the green dot.If this is not possible, then? Say, for example, that the green dot is behind the red dot, and the red dot is facing a corridor that's later widening up enough for it to turn around. In this situation it should go forward, turn, and then pass over its old position again to reach the green dot. Tricky!The trick is to divide every tile, one sub-tile for each direction. This means that a tile can have one value in one direction, and another in another direction, like this:The red dot's start tile is very close to the goal if facing left (2 steps away) but very far from the goal if facing right (10 steps).Look closely at the green numbers and you can see in what pattern they spread. According to this pattern every sub-tile will have a value that is one less than the tile it's pointing towards. That's because when the numbers spread to a new tile they spread to the subtile that's pointing backwads to where they spread from. If that makes any sense... Just look at the numbers ;PWhen the red dot is in a specific tile it doesn't ask the neighbours for their values, instead it asks the sub-tiles. It does not, however, ask for the sub-tile that indicates a direction opposite to its own. This means it has three options every frame: forward, left or right, but not reverse. Then it just moves in the direction with the lowest value, exactly like the standard solution up there.Voila, you have a behaviour where the path finding will intelligently either "walk around the block" or find its way to the closest turning point and back, depending on what's more efficient, shorter or otherwise preferable.In my game this is meant to create some fun and interesting situations. One such might be that you jump over a croc, but the croc runs forward, climbs up on something, climbs out to directly above you, then drops down on you. Another scenario could be that the croc has momentum and can't stop, so it runs into a narrow corridor where it has to solve a little maze looking for a turning place or another way out, to get at you again.Hopefully this will make the game play more interesting! Let me tell you, it has to be real good to be worth it... The example above is very theoretical, doing the same thing in a more "real" (complex, that is) environment has been... Try it out if you like a challenge! Logged

JLJac









Level 10 Re: Maze Runner « Reply #13 on: March 27, 2012, 11:30:44 PM »



Update 3

Talking of path finding, I did a few lab tests today.



I created a floating island kind of structure, and had the croc try to path to it.







With the new dynamic abilities I've added I can change what a croc is able to do easily from its initiation code. A croc that's able to climb ceilings will, as expected, climb up the wall, then out above the island and drop down on it. A croc that's only able to climb walls will rush around desperately without ever finding a way, a behaviour I have to work with.



Actually this is going to be the next big step, I imagine. As a croc is able to drop down from somewhere it might easily get stuck in a hole. Also a croc might see a player across a gap, and the path finding will go on for ever and ever without realizing that there actually is no way across.



The task of making the croc aware of what's a "pit" where it will be stuck is almost impossible, as there's no way of saying "this is the level" and "this is a pit", all the code can find is two chunks of tiles from which you can pass from one to the other but not the other way around. You can of course say that the biggest chunk is "the level" while the rest is "dead ends" that should be avoided. This doesn't really apply to all situations though, look at the above picture for an example. The island structure might be smaller than the rest of the level, but it's more important, because more stuff is going on there. Here the majority of the level is a "pit" that you don't want to fall into.



The solution I imagine for this is that the crocs will live in holes. At start up the area that is accessable from the hole will be pre processed, and even more importantly, the areas from which you can't get back to the hole will be mapped out. The croc is only active in the area reachable from its hole.



This also allows the user of the level editor to place a croc, and decide what area of activity it'll have. For example you might want one that's confined to a pit at the bottom of the level and eats players that fall down.



More on that tomorrow! Glad I inspired you! It's a lot of fun to do path finding, as there's really nothing else that does as much for the feeling of AI units being autonomus and having their own minds. Ask me anything!Talking of path finding, I did a few lab tests today.I created a floating island kind of structure, and had the croc try to path to it.With the new dynamic abilities I've added I can change what a croc is able to do easily from its initiation code. A croc that's able to climb ceilings will, as expected, climb up the wall, then out above the island and drop down on it. A croc that's only able to climb walls will rush around desperately without ever finding a way, a behaviour I have to work with.Actually this is going to be the next big step, I imagine. As a croc is able to drop down from somewhere it might easily get stuck in a hole. Also a croc might see a player across a gap, and the path finding will go on for ever and ever without realizing that there actually is no way across.The task of making the croc aware of what's a "pit" where it will be stuck is almost impossible, as there's no way of saying "this is the level" and "this is a pit", all the code can find is two chunks of tiles from which you can pass from one to the other but not the other way around. You can of course say that the biggest chunk is "the level" while the rest is "dead ends" that should be avoided. This doesn't really apply to all situations though, look at the above picture for an example. The island structure might be smaller than the rest of the level, but it's more important, because more stuff is going on there. Here the majority of the level is a "pit" that you don't want to fall into.The solution I imagine for this is that the crocs will live in holes. At start up the area that is accessable from the hole will be pre processed, and even more importantly, the areaswill be mapped out. The croc is only active in the area reachable from its hole.This also allows the user of the level editor to place a croc, and decide what area of activity it'll have. For example you might want one that's confined to a pit at the bottom of the level and eats players that fall down.More on that tomorrow! Logged

peous







Indie opportunist





Level 2Indie opportunist Re: Maze Runner « Reply #14 on: March 28, 2012, 12:58:33 AM »

It could be nice to display the pathfinding periodically while editing a level. Like when you cplace a croc and select it, it could display all the zones it can go from the AI point of view.

About not trying to not "fall" for example, it could be done by adding more cost to the bottom cells than the ones on the top, for A*. The algorithm will naturally prefer going straight than down.

Anyway, following Nice project !It could be nice to display the pathfinding periodically while editing a level. Like when you cplace a croc and select it, it could display all the zones it can go from the AI point of view.About not trying to not "fall" for example, it could be done by adding more cost to the bottom cells than the ones on the top, for A*. The algorithm will naturally prefer going straight than down.Anyway, following Logged

OSome Studio - White Night | SpaceBeam DevLog

JLJac









Level 10 Re: Maze Runner « Reply #15 on: March 28, 2012, 07:26:37 AM »



Update 4

Made the user able to place croc holes in the level editor and made crocs spawn at those holes.



Made a humble little start in the direction of mapping which areas are accessable from a specific hole. The goal is that in this situation







the croc (here represented by the three big dots) will not pursue the player further, as if knowing that it'd just get trapped at the bottom of the pit. That goal is however not reached yet haha!



This is especially important because of the very different movement mechanics of the Bear and the Croc. It's not that the Bear is always much more mobile, a wall climbing Croc can often reach areas unaccessable to a Bear, but the ability to jump creates some situations where a Bear can pass an obstacle that's impossible for a Croc.



This means that some levels could easily contain traps, where you let a Croc chase you to a place from which you're able to get out, but it is not. This wouldn't be fun, as constantly being chased is an important part of the game. Tricking a croc should buy you some time while it's trying to figure out a new way to get to you, not immobilize it for ever. So I think it's worth it to make the Croc do a little extra thinking to avoid that kind of stuff. Yeah, was also thinking about that, but I think showing the reachable areas in the level editor would ruin the illusion that the croc is actually thinking by itself, if you saw it all laid out like that... We'll see...Made the user able to place croc holes in the level editor and made crocs spawn at those holes.Made a humble little start in the direction of mapping which areas are accessable from a specific hole. The goal is that in this situationthe croc (here represented by the three big dots) willpursue the player further, as if knowing that it'd just get trapped at the bottom of the pit. That goal is however not reached yet haha!This is especially important because of the very different movement mechanics of the Bear and the Croc. It's not that the Bear is always much more mobile, a wall climbing Croc can often reach areas unaccessable to a Bear, but the ability to jump creates some situations where a Bear can pass an obstacle that's impossible for a Croc.This means that some levels could easily contain traps, where you let a Croc chase you to a place from which you're able to get out, but it is not. This wouldn't be fun, as constantly being chased is an important part of the game. Tricking a croc should buy you some time while it's trying to figure out a new way to get to you, not immobilize it for ever. So I think it's worth it to make the Croc do a little extra thinking to avoid that kind of stuff. Logged

JLJac









Level 10 Re: Maze Runner « Reply #16 on: March 28, 2012, 11:07:07 PM »



Update 5

I'm happy with today's progress. I finished the mapping of accessable areas for the croc. The method is that I first map all the tiles that are reachable, then I map all the tiles that the hole is reachable from, and the overlap of those is the active area for that hole.







In this pic the blue areas are areas from which I can get home, while the red areas are areas I can get to from home. The platform at the top left is blue, because from here you can drop down to the rest of the map but there's no way to get there. The pit at the bottom of the map is red, because you can drop down here but not get back up again. Green areas are both reachable and returnable from, and it is this that's the croc's active area.



You can't really see the hole itself, but it's there in the middle structure. If I remove the climbable pole connecting the structure to the floor the entire floor becomes red, and the croc will keep only to the central structure, knowing that it won't be able to get home if it drops down. Weird, something seems to be wrong with tigsource's server... AnywayI'm happy with today's progress. I finished the mapping of accessable areas for the croc. The method is that I first map all the tiles that are reachable, then I map all the tiles that the hole is reachable from, and the overlap of those is the active area for that hole.In this pic the blue areas are areas, while the red areas are areas I. The platform at the top left is blue, because from here you can drop down to the rest of the map but there's no way to get there. The pit at the bottom of the map is red, because you can drop down here but not get back up again. Green areas are both reachable and returnable from, and it is this that's the croc's active area.You can't really see the hole itself, but it's there in the middle structure. If I remove the climbable pole connecting the structure to the floor the entire floor becomes red, and the croc will keep only to the central structure, knowing that it won't be able to get home if it drops down. « Last Edit: March 28, 2012, 11:40:38 PM by JLJac » Logged

JLJac









Level 10 Re: Maze Runner « Reply #17 on: March 29, 2012, 12:18:14 AM »



As you might remember the Bear has two major modes of movement, standing up and crawling. I don't remember the exact numbers, but I think that you're almost twice as fast when running. The croc, as it stands, moves with a speed that's variable depending on terrain, but will move along a floor with the same speed as it would a horizontal tunnel. If the tiles directly above are a ceiling or open air doesn't affect it.



This means that right now this







is no problem what so ever, while this







is a HUGE problem. A branchless corridor is more or less a countdown to death.



I like it that the Croc is faster than you in some situations and slower in some, but it might be too extreme. I don't want the player to avoid tunnels entirely. If I make the croc slower over all it will be way too slow out in the open, if I make it faster it'll be way too fast in tunnels.



Currently I'm thinking about maybe making the croc able to stretch its legs when outside a tunnel, and gain a little extra speed to match the player's ability to stand up and run. Still, this would mean making the Croc closer to the Bear in terms of movement, and maybe it's a good thing that they have those differences... Hm... Maybe this is a question of level design, levels should simply be designed in a way that makes both the player and the croc stand a fair chance.



Another problem that arises is that if the Croc is vastly inferior on open floors but much faster in close quarters the AI should probably somehow be aware of this. How would that work?



A lot of decisions here. Maybe I'll just wait until the basic gameplay is up and working, and see what needs to be balanced. I will talk about something that's not path finding for a change.As you might remember the Bear has two major modes of movement, standing up and crawling. I don't remember the exact numbers, but I think that you're almost twice as fast when running. The croc, as it stands, moves with a speed that's variable depending on terrain, but will move along a floor with the same speed as it would a horizontal tunnel. If the tiles directly above are a ceiling or open air doesn't affect it.This means that right now thisis no problem what so ever, while thisis a HUGE problem. A branchless corridor is more or less a countdown to death.I like it that the Croc is faster than you in some situations and slower in some, but it might be too extreme. I don't want the player to avoid tunnels entirely. If I make the croc slower over all it will be way too slow out in the open, if I make it faster it'll be way too fast in tunnels.Currently I'm thinking about maybe making the croc able to stretch its legs when outside a tunnel, and gain a little extra speed to match the player's ability to stand up and run. Still, this would mean making the Croc closer to the Bear in terms of movement, and maybe it's a good thing that they have those differences... Hm... Maybe this is a question of level design, levels should simply be designed in a way that makes both the player and the croc stand a fair chance.Another problem that arises is that if the Croc is vastly inferior on open floors but much faster in close quarters the AI should probably somehow be aware of this. How would that work?A lot of decisions here. Maybe I'll just wait until the basic gameplay is up and working, and see what needs to be balanced. Logged