JLJac on March 24, 2012, 12:44:52 PM (Last Edit: May 13, 2017, 12:09:58 PM):

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

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

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

JLJac on March 25, 2012, 10:43:37 PM:

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!

JLJac on March 27, 2012, 11:30:44 PM:

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!

JLJac on March 28, 2012, 07:26:37 AM:

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

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.

JLJac on March 28, 2012, 11:07:07 PM (Last Edit: March 28, 2012, 11:40:38 PM):

Weird, something seems to be wrong with tigsource's server... Anyway

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.

JLJac on March 29, 2012, 12:18:14 AM:

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

JLJac on March 29, 2012, 10:56:08 PM:

Update 6

Added the ability to balance on the tip of a pole.



There are two ways to access this mode, you can climb up a pole, and you can land on it from the air with a well timed key press. The Bear doesn't automatically land on poles, you have to press the "up" arrow at the exact right moment, making jumping between poles very difficult.

I like to add some stuff like this that's very hard to do but won't really be required in any level, so that players who have played for a long time will always have fresh challenges.

JLJac on March 31, 2012, 10:01:30 AM:

Thank you sir 

Update 7
Boring but important progress today: I managed to export a .png file.

This has implications though. If I would have to save the levels as text files I'd only be able to save the geometry of the level, and all the graphics would have to be generated on start up. When you start the level you can't really tolerate more than 5 seconds for the level to be drawn, and this would mean a pretty simple layout.

If the level can be saved as an image file however, its graphics can be generated from the level editor. After you've made an awsome level you can possibly endure to wait a minute or two for intricate stuff such as hundreds of grass straws and light and shadows to be rendered, to make it look extra juicy.

Being able to save levels as images enables me to make levels look much more complex. This stuff is far in the future, but it's nice to know as it helps me when thinking about the overall art direction for the game.

JLJac on April 01, 2012, 12:02:50 AM (Last Edit: April 01, 2012, 04:36:03 AM):

Update 8
I have started working on the AI today. What I've done up until now is path finding, getting from one place to another, but there has to be an AI that makes decisions on what places it wants to get to.

I do not want the croc to be omniscient, it will have to see its prey to know where it is. This will add a slight element of sneaking to the game, you'll want to take routes where the crocs can't see you.

In order for a unit to be able to navigate without knowing where everything is, it has to be able to have an estimation of where things are. This means a little mental mirror of sorts, that will sometimes cohere with and sometimes deviate from the real world.

This is what I've been doing today. Each Croc has a list of where it thinks the players are. For each player it can have a few different ideas, simplified they could be boiled down to:

Visual contact - I know where this particular player is because I see him.
No Idea - I have no idea where this player is.
Memory - I remember the last place I saw this player.

This is the framework I've been working on today. If the Croc has a memory about where it last saw a player and returns to that place without spotting the player there the memory will be deleted, and it once again has "No Idea" about where that player is. It also keeps track of how long ago it saw a player, maybe a memory will be deleted after a while because it's very unlikely that the player would remain anywhere close to that spot. As of now the crocs can't act on this information, but I'll get to that later.

The idea behind this is that if a croc hunts player 1, and in the corner of its eye sees player 2, then if it later looses track of player 1 it will be able to return to that point where player 2 was spotted. I will probably have to create some behaviour for searching the surroundings of a place, so that if it returns to a place where it remembered a player being it doesn't just give up, but looks around the area a little first.

Different crocs will probably have different mental stats as well as physical, with adjustments to memory, patience and the like.

JLJac on April 01, 2012, 11:23:10 PM:

Update 9
Quite a lot of progress today, all happening inside the croc's head. Some basic behaviours are up and running, such as searching, idling, hunting.

The one that has been hardest so far is the "investigate" behaviour, where a croc is given a tile and is supposed to check out its immediate surroundings. Currently I do this by sending out a few "scout" checkpoints from the main checkpoint, they travel only in tiles that are accessable to the croc and stop after a few steps. The Croc then proceeds to check out the main tile and the "scouts" surrounding it, after which it considers the area investigated.



The hunting behaviour needs a lot of work. Especially when the player dissapears around a corner the behaviour is too unintelligent, in situations where it's fairly easy to estimate where the player might have gone it should do so.

JLJac on April 02, 2012, 11:09:17 PM:

Update 10
The AI is coming together, and is now actually playable against (Even though there still aren't any effects from a croc colliding with you). The behaviour is now considerably more competent when it comes to pursuing you, if you for example disappear around a corner it will make a little "simulation" of where you might've gone, and act according to that estimation. It's all very simple, but seems to be working fine.

As it stands the lizards mill about the level idly until they see a player. Then they start hunting, and if the loose track of the player during the hunt they'll look around the area where they last saw him. If the player was moving during the last visual contact they crocs will estimate where he might have ended up since then, and look around that place instead.

One fun thing is the effects of having different ways of calculating visual contact and path finding. This means that a Croc can see a Bear across a gap, but to get there it has to take a much longer way.



I like these situations because here you can see the intelligence at work, you know that it doesn't just charge towards close targets, but it's actually able to plan a long and complicated route to get to a place. I'll try to make a video some time soon.

In the situation in the picture the player would probably be nowhere near that same place once the Croc finally arrives, and it'll use the "investigate" behaviour of the above post to look around for a little while before giving up and roaming the map again. I'm pretty happy with how all this is coming together.

I have noticed a few situations where Crocs get stuck though, will have to work on that.

JLJac on April 03, 2012, 11:02:48 PM (Last Edit: April 04, 2012, 12:57:29 AM):

Yeah, I hope you will be able to play with it in interesting ways. Right now you can do some stuff like dissapearing around several corners quickly, and watch how it gets confused and searches around for you, it's pretty fun.

Update 11
Made the croc aware of when it has reached... eh, like, the destination of an old path that it follows until the new path is calculated... well, I made the croc not turn around again and again on the same spot.

Also I kind of identified and fixed (?) a path finding error that I'm not really even able to formulate for myself... The code is too extensive and complicated for me to fully understand at this point, but it seems to be working OK. Seems like a tile can't be weighted more than a passage between tiles, but if this is an inherent feat in the A* mathematics or something I messed up is beyond me. As long as I keep it in mind it shouldn't be a problem.

Made variable speeds for the croc depending on what it's doing, so that it'll speed up when chasing you and slow down when just roaming around.

EDIT: Solution came to me in the shower. Implementing tomorrow!

JLJac on April 04, 2012, 07:39:09 AM:

Just some of the sketches from when I tried to figure out the path finding



Don't want to think about how long this has taken me, but it might be several weeks... Soon I will let this rest and concentrate on other things!

JLJac on April 04, 2012, 10:52:28 AM:

Update 12
Fixed some quirks and the above mentioned problem in the croc path finding. I pray this is the last time I write the words "croc path finding" in this dev log. Also improved the croc's estimation of where a player might have gone.

I didn't get around to write this as it was something that was finished before I started writing the log, but on the levels there are "short cuts", holes you can crawl into and be transported to another hole elsewhere on the map. This feature was included to make the levels less limited by being two dimensional, with a short cut it's possible to make a path that crosses another path without actually connecting to it, if you get what I mean. You can see the short cuts as the little white dots on the level editor screen shot in the original post, you probably already figured out what they where.

All three creatures in the game are able to use the short cuts, even though the A creature is very hesistant to enter one unless there's no other way around (it knows that a player might see it, and position himself at the exit for an easy kill). The croc path finding (DAMMIT!) has been able to handle those for a long time, and the crocs use them to transport themselves around the map. If a croc sees a player entering a short cut it doesn't simply follow him, but makes an independent estimation of what way is the quickest to get to the exit, through the short cut or by foot. If it's the latter an unpleasant surprise awaits you when you exit.

The AI creatures are assumed to be aware of the entire map lay out, it's only the players' position they don't know about unless there is visual contact.

Today's progress includes that if a croc doesn't explicitly see a player entering a short cut, but sees him dissapearing into a corridor that leads to a short cut, it will still be able to figure out what might have happened.

JLJac on April 04, 2012, 11:38:35 PM:

Thank you. Even coming from someone with [/sarcasm] in their sig it means a lot to the crocs, they send their regards.

Update 13
I gotta say, today was a good day. Not because I was very productive, but because I tested stuff and it worked.

I made this crazy level:



and had two crocs plus four A-creatures run around on it, along with a player. Implemented that if a player touches an A-creature it dissapears and a score counter increases, no animations and no nothing, but still enough to start trying stuff out soon. It's a game!

The crocs adapt well to different environments. They are able to navigate a maze like this without looking too clueless, at least to me.

One thing I've started to notice about how the game turns out is that there is much more emphasis on not being seen by the crocs than I had anticipated. For some reason I imagined that the Crocs would know where you were pretty much most times, and the gameplay would be about hunting/fleeing. Unless I want the Crocs to see through walls this is not really possible though, if you're behind a wall you're behind a wall and the Croc shouldn't know your exact position.

The hunt/flee type of game play had a problem, if the croc would constantly be chasing the player I pretty much would have only two options: Either the croc is slower than the player, and will never ever pose any threat because it's unable to catch up. Or, the croc is faster than the player, and will catch up and kill you within a very limited time, no way to avoid it.

As it looks right now the game is leaning more towards a platformer/sneaker than an action platformer as I had originally planned. I have nothing against this, if that's the direction the project wants to go I'll allow it. I like the feeling that the crocs are physically superior to you, they outrun you easily, the only way to survive is to out smart them. This is a perspective I think is fairly rare in games. (Actually your only advantage to the crocs is your overview, if your vision was as limited as theirs you would be A-B-S-O-L-U-T-E-L-Y C-H-A-N-C-E-L-E-S-S, but it feels as if you're out smarting them!)

Ok, it'll be a long post today.

You see the little yellow things on the level editor screen shot? Those are hives. I felt that the C-creature had an objective, eating the B-creature, and the B-creature had an objective, eating the A-creature, but A was without any motivation. What would it do, just hang around one part of the map until it got chased to another part of the map? I wanted it to do something.

The hives are places where A-creatures spawn, and then during their life time they move around from one hive to another as if transporting something or what will you. This makes them motivated to go somewhere instead of just roaming by random. The behaviour looks a bit ant like, they have their paths between the hives where they move back and forth, until a player chases them and puts them off their course.



The idea is that they should be able to dive down into their hives and dissapear, so that the player has to ambush them on their routes instead.

Unlike the other creatures the A-creature will be respawned when killed, and therefore needs a logical respawning place instead of just popping up from nowhere.

The path finding seems to be more or less behind me and hopefully the pace will increase from here on! Soon I'll make a video or demo or something so you can see the stuff in motion.

JLJac on April 06, 2012, 02:27:24 AM:

Update 14

It's becoming a game! All the creatures are in and behaving somewhat like what I want them to. I've been thinking about about the game rules, here's what I came up with:

1. Catch as many A-creatures as possible within a limited time.
2. Survive! No respawns.

The idea is that I want a basic mechanic that's the same for a multi player game and a single player game. The "high score" of a level will be the amount of A-creatures eaten within a certain time, and you can attempt to break these records, for some single player replay value.

Multi player: There is a timer, urging players to hunt rather than just sitting around in some corner. When a player dies he is not respawned, but the timer is halved, so that you won't have to sit around inactive for ever and ever. The gameplay is less interesting for all players when one is dead, but the surviving players should be given just a little extra time to gain an advantage and compete among each other. The amount of time I'm thinking about is two or three minutes, the multi player game mode should be fairly rapid-fire paced with new levels every so often. This is especially important as there are no respawns.

The players are ranked from how many A-creatures they managed to eat in their lifetime, but a surviving player is always ranked above a dead one. This means that there can be no situation where you benefit from committing suicide. If all players are dead the one with the most "eats" will be the match winner, but if there is one surviving player he will win, despite not having catched a thing. So, the priorities are: 1) Don't get eaten. 2) Eat as much as possible.

Single player: The basic mechanics are the same, but the winning condition for a single player level is 1) Being alive, 2) Having eaten a certain number of A-creatures. If you manage those the next level will unlock or however the campaign will be laid out. In the campaign there could also be levels where you're supposed to just get to an exit like any platformer, the high score of those will be how fast you got there.

Possibly there could be some kind of co-operative mode where two or more players play the single player campaign, and their score is added up and then divided by their numbers or something like that. We'll see what's reasonable.

I'm currently setting this framework up, and will soon try it. Some (most) things might be revised.

Yesterday I saved a version of the game and tried on another computer, seemed to work fine. The import of text files and export of .png files worked too, which was a huge relief.

The level editor will probably save a level as an image file, which will contain the level image as well as the level data, the latter coded into a block of different-colored pixels which will look like noise to the human eye. This is probably not the optimal way to do things, but it compresses the entire level into one file, which is nice.

JLJac on April 06, 2012, 08:25:06 AM:

A video!
http://www.youtube.com/watch?v=Jnpocoxuzg0&feature=youtu.be
It's a horrible horrible cellphone video, but it shows what I wanted to show... Now you can probably tell where I'm from from my accent

Glad to get something up here that isn't just another wall of text, hope you'll find it interesting! If I have any readers left, that is...

In other news saving level data in a noisy square in an image seems to be working fine, which I'm rather happy about. Soon I'll move the level drawing code over to the level editor, and then I'm set to start working on the graphics.

JLJac on April 06, 2012, 01:50:00 PM (Last Edit: April 06, 2012, 08:20:31 PM):

A sketch I made, just playing around.



Before you get excited/dissapointed, keep in mind that this is my very first pixels I ever draw for this game, it is much more likely that it will end up looking nothing like this than something like this. However, a first tiny step towards working on the visuals has been taken.

It's nice to have art in the dev log, now I might actually have read it myself!