next »

[JLJac]

Rain World is a sneaker/action platformer under construction.



Video!



The gameplay consists of platforming and fast paced sneaking, both sneaking on your prey and sneaking in order to avoid larger creatures. A lot of focus in the development has been on enemy AI.

The player character moves a little differently from in most 2D platformers, it is not animated by traditional means but with simple physics. This is an attempt to make a character that appears a little softer, as well as an experiment with a different control scheme.



Alongside the game I'm also working on a level editor, which will allow you to make your own levels and render their graphics. Right now both game and level editor are unfinished, but it's likely that the game will be released before the level editor.

The level editor uses a voxel-like method to create graphics, and does some basic raytracing for light. If you go to the newer pages you'll see a lot of level editor related progress.



Everything, including the title, is subject to change, but the project is much more defined now than when this thread was started! Below is the original post from some time ago, if you want to follow the progress of the project from the start.

I post updates more or less every day, and am making slow but steady progress.


If you find the project interesting, please feel free to ask, suggest, comment or otherwise contribute.
Thanks for your time!

----------------------

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 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 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.

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!

[Alex Norton]

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!

[Franklins Ghost]

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!

Yeah I agree with this, I like the visuals.

[zede05]

This sounds really interesting, but based on the name, I came in expecting the game to be based on the book...heh.

[JLJac]

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.

[RayJack]

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. =]

[JLJac]

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.

[RayJack]

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?

[Franklins Ghost]

Tried the prototype and it's really nice. Love the movement of the player, feels very smooth and just looks great. Looking forward to seeing more of your idea develop and seeing where you take it.

[Jay Tholen]

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)

[JLJac]

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 ;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!

[Franklins Ghost]

Nice video, like the grab you've added. Also really interesting to hear how you've approached the pathfinding when it comes to turning around. Seems like you've approached it really logically and it's a nice and clear solution to the issue. Never attempted pathfinding but hearing how you've achieved it makes me want to work with it 

[lasttea999]

Multiplayer level editor... Interesting!

[JLJac]

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!

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!

[peous]

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