next »

[tortoiseandcrow]

I think fylth and Christian are on the right track - when you are idle & feeding would be ideal points to communicate your current level of hunger.

Joar and James made it pretty clear that status effects are unilaterally out, and that death is a binary state, but perhaps it might be more useful to think of this problem as one of signalling, rather than changes in gameplay. It's like the rain timer - it has a definite value, and when it shows up you are one hundred percent dead. But that precise value is obscured from the player and all the changes you observe are just a countdown to that point. There's dramatic potential built into that uncertainty that I think can be exploited here as well.

Lets say you need to eat 8 bats per rain cycle in order to be properly fed, +/- 3 (one for each pup). Let's also say there's a starvation timer with a value of 4. If your bat consumption for a given rain cycle is less than the required 8, the difference is subtracted from the starvation timer. When the starvation timer reaches 0, you die. For each value of the starvation timer, from 4 (you're fine) to 1 (you'll die if you don't get enough bats), there is a different signal - perhaps when you wake up in your den you range from getting up with a sprightly step to groggily waking with a terrible rumble in your tummy. If you eat the necessary amount of bats (or more) the next rain cycle, the timer resets. So, if you eat 5 bats one rain cycle, you get one more rain cycle to catch back up again or you die. If you eat 6, you can get away with 7 the next rain cycle, but no less. This also means that if you're taking care of the pups and you are able to get enough for yourself but not for them, you can sacrifice 3 of those bats to feed them for at least one rain cycle with no immediate consequences, but you can't do that forever.

There's also ways of training the player's awareness of what the slugcat is doing. If the first "tutorial" level contains the exact amount of bats for ideal health, then if the player collects fewer than that the game immediately lets them know something is up through the reaction of the slugcat, indicating that the slugcat's responses have meaning. It's like how Super Mario Bros. taught players that walking into goombas was fatal, and that players needed to jump on them in order to defeat them, without ever having any text explanation at all: by having this be the very first thing the player encounters.

[theEasternDragon]

Lets say you need to eat 8 bats per rain cycle in order to be properly fed, +/- 3 (one for each pup). Let's also say there's a starvation timer with a value of 4. If your bat consumption for a given rain cycle is less than the required 8, the difference is subtracted from the starvation timer. When the starvation timer reaches 0, you die. For each value of the starvation timer, from 4 (you're fine) to 1 (you'll die if you don't get enough bats), there is a different signal - perhaps when you wake up in your den you range from getting up with a sprightly step to groggily waking with a terrible rumble in your tummy.

I like this idea, of it being in the den. Remember the "bat calendar" or something similar mentioned a few pages ago? It would have been in the den. If hunger is to be communicated through the slugcats idle moments, then a good place to make it really noticeable is the den. It doesn't impact gameplay, so you could have some status effects, say for 2 seconds immediately after you wake up. Think "monday morning". Then have the slugcat be normal throughout the gameplay after that, so that you could still count on its movements being the same.

[Christian]

I think fylth and Christian are on the right track - when you are idle & feeding would be ideal points to communicate your current level of hunger.

Joar and James made it pretty clear that status effects are unilaterally out, and that death is a binary state, but perhaps it might be more useful to think of this problem as one of signalling, rather than changes in gameplay. It's like the rain timer - it has a definite value, and when it shows up you are one hundred percent dead. But that precise value is obscured from the player and all the changes you observe are just a countdown to that point. There's dramatic potential built into that uncertainty that I think can be exploited here as well.

Lets say you need to eat 8 bats per rain cycle in order to be properly fed, +/- 3 (one for each pup). Let's also say there's a starvation timer with a value of 4. If your bat consumption for a given rain cycle is less than the required 8, the difference is subtracted from the starvation timer. When the starvation timer reaches 0, you die. For each value of the starvation timer, from 4 (you're fine) to 1 (you'll die if you don't get enough bats), there is a different signal - perhaps when you wake up in your den you range from getting up with a sprightly step to groggily waking with a terrible rumble in your tummy. If you eat the necessary amount of bats (or more) the next rain cycle, the timer resets. So, if you eat 5 bats one rain cycle, you get one more rain cycle to catch back up again or you die. If you eat 6, you can get away with 7 the next rain cycle, but no less. This also means that if you're taking care of the pups and you are able to get enough for yourself but not for them, you can sacrifice 3 of those bats to feed them for at least one rain cycle with no immediate consequences, but you can't do that forever.

There's also ways of training the player's awareness of what the slugcat is doing. If the first "tutorial" level contains the exact amount of bats for ideal health, then if the player collects fewer than that the game immediately lets them know something is up through the reaction of the slugcat, indicating that the slugcat's responses have meaning. It's like how Super Mario Bros. taught players that walking into goombas was fatal, and that players needed to jump on them in order to defeat them, without ever having any text explanation at all: by having this be the very first thing the player encounters.

I really, really like that give-and-take idea. It adds an dynamic sense of danger and intensity. Damn, you had to cut your hunt short since fighting off that vulture took too much time. Next venture will be one where you'll be focused on gathering food and probably evading predators rather than sticking around and fighting/observing. And in turn, by focusing on that, your following venture would have more breathing room to explore since you ate some more food last time

[JLJac]

Sorry for not being very active in this discussion, I'm deep in level editor overhaul. But just wanted to let you know I'm following it, and there's a lot of interesting stuff popping up 

In overhaul news, I have just played the first ever 20-screen room in RW history! It takes something like 3-4 minutes of just running to get from one end to the other. Most of the level editor logistics become pretty awkward at this level size, but it technically works. I seriously doubt we'd want/need to go beyond 10 screens anywhere in the game, but it's cool to know that 20 is a theoretical possibility.

Note though that the mile stone here was that a 20 screen room was actually spit out by the editor and accepted by the game, not that everything is done and flawlessly working haha! Basically all the effects (rust, slime, plants) need to be adapted to the new rendering pipeline, and quite a lot of other stuff has to be sorted out as well. But hope is good and there's wind in the sails! Onward!

[Rojom]

Sorry for not being very active in this discussion, I'm deep in level editor overhaul. But just wanted to let you know I'm following it, and there's a lot of interesting stuff popping up 

In overhaul news, I have just played the first ever 20-screen room in RW history! It takes something like 3-4 minutes of just running to get from one end to the other. Most of the level editor logistics become pretty awkward at this level size, but it technically works. I seriously doubt we'd want/need to go beyond 10 screens anywhere in the game, but it's cool to know that 20 is a theoretical possibility.

Note though that the mile stone here was that a 20 screen room was actually spit out by the editor and accepted by the game, not that everything is done and flawlessly working haha! Basically all the effects (rust, slime, plants) need to be adapted to the new rendering pipeline, and quite a lot of other stuff has to be sorted out as well. But hope is good and there's wind in the sails! Onward!

Question: Will the transitions between screens always be "panel jumps"? I remember you had a slugcat camera tracker way back. Do you have plans on implementing this so that moving through screens will be smooth?

[Christian]

Sorry for not being very active in this discussion, I'm deep in level editor overhaul. But just wanted to let you know I'm following it, and there's a lot of interesting stuff popping up  

In overhaul news, I have just played the first ever 20-screen room in RW history! It takes something like 3-4 minutes of just running to get from one end to the other. Most of the level editor logistics become pretty awkward at this level size, but it technically works. I seriously doubt we'd want/need to go beyond 10 screens anywhere in the game, but it's cool to know that 20 is a theoretical possibility.

Note though that the mile stone here was that a 20 screen room was actually spit out by the editor and accepted by the game, not that everything is done and flawlessly working haha! Basically all the effects (rust, slime, plants) need to be adapted to the new rendering pipeline, and quite a lot of other stuff has to be sorted out as well. But hope is good and there's wind in the sails! Onward!

Question: Will the transitions between screens always be "panel jumps"? I remember you had a slugcat camera tracker way back. Do you have plans on implementing this so that moving through screens will be smooth?

I would like to know this too. I noticed it mostly while in Canopy, but sometimes the panel jumps in multi-screen rooms can be jarring. Especially when you're at the border of two screens and you're moving around to evade lizards, the jumps between screens can throw you off for a second or two.

[fall_ark]

Bit late on the UI discussion. I've just watched the Shelter 2 review video (and the Shelter 1 one, too), can I offer a few opposing pointers?

Despite the reviewer's praise, Shelter 1 has myriads of information that's player-oriented only. The tutorial is revealed by on-screen images that has text. Even the main point, the "visually significant points on the horizon" that replaced "objective markers", are only visually significant to a human. -- Even if the badger could see that huge tree on the horizon, it should have no influence on the badger's decision making at all.

He then goes on to praise the game's audio design where "each successfully fed cub rewards you with a triumphant strum of a guitar while the presence of danger is revealed through a soundtrack panicked and urgent".

I'm not saying that his reviews are inconsistent. The criticism on Shelter 2 seems to be spot-on, but when he talks about "really feeling like you are a badger" and "animal instincts", he's not asking to eliminate everything outside of a badger's cognition from the game. An image/icon based bat counter or a thought bubble like hint wouldn't necessarily distract from the immersion. Heck, in Journey the chirp symbol is larger than the player module, and no one seems too concerned about that, yeah?

I'm still firmly in the stomach grumble/refusing to eat too much camp though. Just don't want to see everyone so hung up on the  "no UI at all" thing.

[Teod]

Stomach grumble is a fairly abstract sound. Players hearing it will not always be able to identify the source. It could be environment or some creature out of sight. Simpsons example had a good animation to clarify that, but our pixelated model doesn't really have enough space for that.

And refusal to eat doesn't make sense from the world perspective. Slugcat is an animal. He doesn't have "no, thank you, I'm full" state. And while everyone has a physical limit of consumption it's certainly not one bat away from lethal starvation. Making bats take progressively longer to eat after going over the requirement makes much more sense, even through it's not as clear as a piece of interface.

I think that the best solution of this problem can really only be found through prototyping and testing as many ideas as possible in a working game. Maybe just a row of bat symbols will turn out to be the best option, but I really hope that there is more interesting solution. My favorite idea is still burp/hiccup that produces bubbles.

And form the gameplay perspective I agree that gradual starvation system that gives some room for error is better than flat "eat N or die" system. But again, it creates a more challenging UI problem, because the number becomes variable and stops being a straight up requirement.

[Woodledude]

I think we're kind of getting into the deep questions of the very existence of UI, which is actually pretty great. To me, it speaks to the bravery of Rainworld, and it's also an important discussion to have. Of course, it's also a naturally contentious issue, because UI exists in lieu of many important forms of feedback that games in their current state simply can't convey, or have to convey in different ways - Hunger being a prime example.

[JLJac]

Question: Will the transitions between screens always be "panel jumps"? I remember you had a slugcat camera tracker way back. Do you have plans on implementing this so that moving through screens will be smooth?

Yup, sorry! If you look at for example the water, you see that the levels have a bit of 2.5D perspective rendered into them, and this stuff needs to be rendered from a specific camera position. That's why we can't just render the room from a bunch of camera positions and then graft the pieces together into a continuously scrolling unit. There was a moment when we played around with the idea of having each of the 30 layers be its own separate sprite in order to scroll, but that would put each room at about 10-15 MB (per screen!) and slow down the rendering quite a bit, possibly to the point where that would be the only cool graphical effect we could do. Basically everything we have now that's good looking shader-wise (water, shadows, darkness, etc etc) relies on the level being a single texture. So it's been a bit of a trade-off, and definitely a decision we have seriously considered before making, but now it's made and it's gonna be fixed screens, with jarring jumps between them. If you play in wide screen there's a bit of an overlap, which makes it somewhat better because at least you know a few tiles of the terrain you're headed into. Buuuut yeah, we know this is maybe not strictly optimal, yet we consider it worth it after carefully weighing the options.

Shelter 2 review seemed super relevant!

As for the stomach stuff, I realize when reading the stuff you guys are discussing that I've never really considered the actual bat eating a full-fledged, interesting mechanic in its own right. Subconsciously the bat hunting has always been just a "reason to play", while the actual interesting gameplay is the predator encounters. Under this logic it made sense to just say "catch this many bats or you'll starve" - that's the minimum needed to actually propel the player out into the world. This might be a problem! Catching bats is what you do, after all ~ so it should probably be interesting enough in itself. However, this might be a pretty common video game trope? In Mario you win by reaching the flag at the end of the stage - the flag reaching itself is actually pretty anticlimactic, you just... reach the flag. What's interesting is the problems facing you in order to get there. To a degree I think this is desirable and/or unavoidable, in a video game it will always be the obstacles that are interesting rather than the goals themselves. However, because of the nature of our game, the obstacles can't really be guaranteed - predators roam as they please, and a certain percent of cycles you'll be able to go get the bats without actually encountering any, or only encounter them in easily avoidable situations. For these scenarios, we probably need to make the bat hunting interesting in itself.

I'm still not sold on making the slugcat stomach an entire intricate sub-system, though. I think it's bat hunting that needs to be made more interesting, not bat ... eh ... digestion. When it comes to starvation states that stuff is certainly interesting, but there'd really be no way to do it without punishing a player who's performing poorly. Nature generally punishes the weak (if you're starving you become slow and dumb, if you're born poor you have fewer opportunities, etc etc) but a video game should do the opposite (the further back you are in mario kart, the better power ups you get). This combines with the design guideline that the slugcat should generally not be affected by status effects too much - the slugcat is this little blank-eyed, completely white silhouette, it's a blank slate to project yourself onto, and only through controlling it you can make it succeed or fail. It shouldn't be bogged down or beefed up by lasting "stats", it's defined only in the moment, by the situation it's currently in and by the player controlling it. The slugcat does things rather than is things. Starved and fat are adjectives rather than verbs, and for that reason I'm not sure they fit the slugcat character.

But this is sort of a separate branch of the UI discussion. As for the strictly UI related discussion, I would definitely love to do it without throwing symbols on the screen. The problem is that most solutions seem to require stylistical diversions. A stomach rumbling animation or burping bubbles is a little too goofy for the somewhat grim and creepy atmosphere in the game. Where the slugcat looks and what idle animations it has is probably too subtle, and it veers into the adjective territory. I doubt naturalistic sound cues would work as there'll be a quite a bit of weird stomach-growly ambient sounds going on, and artificial sound cues such as an upwards DIIING if you have enough and a downwards BEEENG if you don't is essentially just as HUD as an on-screen HUD, just coming through your speakers instead of on the screen. Having the character change color would work, but then it'd have to be really clear to effectively communicate what's going on, and might mess with the art style. And what about coop and multiplayer? For proper multiplayer, aka Sandbox, we'll probably have to give in an add actual UI either way because there'll be game rules and stuff going on, and support for 4 players. That's okay though, as Sandbox isn't really canon - it's just for fun. But coop is a strange mid-case.

My favorite option so far is to just evade the problem entirely by having the required amount of bats always be the same, but I don't know if that is James' from a level design viewpoint. Also it still doesn't solve the problem of conveying how many of the required bats you've caught so far.

Not trying to shoot your ideas down btw, I'm really interested in this discussion and there has been a lot of great stuff coming up - just haven't seen The One idea just yet. Awesome talk though 

[gimymblert]

Instead of ambient sound "cues" why not having ambient "background" sounds changes, like in zelda when you get close to enemy, it reflect more state of mind. Also totally ignoring bats once full. Also why not reward the player as he get more bats, ie the backflip is replaced by a normal functionallly equivalent jump at the start and is enable once there is enough bat eaten, things like that, have embelishment, or literaly some chance of evading a predator mouth after being bitten.

[jamesprimate]

Ohhhhh I'm really into Gimmy's bat idea. Joar had plans for something similar using move timing and an "adrenalin" system to unlock more advanced move sets (which I really liked the idea of), but the bats as a perpetually available version of the same makes perfect sense, solves a bunch of problems and is already built in. See this is why you're our lead designer G. 

[gimymblert]

[chriswearly]

Instead of ambient sound "cues" why not having ambient "background" sounds changes, like in zelda when you get close to enemy, it reflect more state of mind. Also totally ignoring bats once full. Also why not reward the player as he get more bats, ie the backflip is replaced by a normal functionallly equivalent jump at the start and is enable once there is enough bat eaten, things like that, have embelishment, or literaly some chance of evading a predator mouth after being bitten.

There we go. So when bats fly out of tunnels, slugcat stops reaching for them altogether. That seems perfect.

[Woodledude]

I think the "not eating any bats" thing has been shot down several times already - Not just in the fact that animals will always eat whenever they can, generally, but also in the fact that it eliminates the ability to do any sort of high scoring. 

[theEasternDragon]

I am with Woodledude; it really makes no sense if you think about it. the whole nature in action, eat everything you can mentality.

[Christian]

I am with Woodledude; it really makes no sense if you think about it. the whole nature in action, eat everything you can mentality.

In Rain World's case, I think it makes sense in context. You're not just out hunting for food like a normal animal. You're hunting and eating so you won't starve in your shelter while the rain falls. The motivation is prolonged survival. Like a squirrel hording nuts or a bear gorging on meat before hibernation. For the slugcat, eating and gathering excess food (aka eating everything you can) makes sense in that context

[Kytin]

A stomach rumbling animation or burping bubbles is a little too goofy for the somewhat grim and creepy atmosphere in the game.

Personally I quite like the idea of burping up bubbles once you reach the required amount of food. I think that a small amount of 'goofiness' can actually enhance an overall grim/creepy mood. It creates a bit more contrast when things go horribly wrong.

[Tiredvd]

Question: Will the transitions between screens always be "panel jumps"? I remember you had a slugcat camera tracker way back. Do you have plans on implementing this so that moving through screens will be smooth?

Yup, sorry! If you look at for example the water, you see that the levels have a bit of 2.5D perspective rendered into them, and this stuff needs to be rendered from a specific camera position. That's why we can't just render the room from a bunch of camera positions and then graft the pieces together into a continuously scrolling unit. There was a moment when we played around with the idea of having each of the 30 layers be its own separate sprite in order to scroll, but that would put each room at about 10-15 MB (per screen!) and slow down the rendering quite a bit, possibly to the point where that would be the only cool graphical effect we could do. Basically everything we have now that's good looking shader-wise (water, shadows, darkness, etc etc) relies on the level being a single texture. So it's been a bit of a trade-off, and definitely a decision we have seriously considered before making, but now it's made and it's gonna be fixed screens, with jarring jumps between them. If you play in wide screen there's a bit of an overlap, which makes it somewhat better because at least you know a few tiles of the terrain you're headed into. Buuuut yeah, we know this is maybe not strictly optimal, yet we consider it worth it after carefully weighing the options.

Hi JLJac long time lurker here I have loved following this devlog from the beginning. Just made an account to reply because I want to understand your point about the impossibility of a slugcat camera tracker.

In my limited knowledge, the way the scene is rendered doesn't need to change, just that the boundaries of the rendered scene visible to the player should be linked to the slugcat position.
My understanding from reading the devlog is that the whole level has multiple screens... scenes? (forgive any wrong terminology) The whole level is rendered and the slugcat can transition between the various screens. So instead of jarring panel jumps, the  "view frame?" which is linked to the slugcat is smart and smooth about showing what is in proximity to the slugcat in the various screens (scenes).

This is just me trying to understand why the levels being rendered from a specific camera position, prevents the possibility of a slugcat camera tracker.

Also just to highlight a valid point that Torchkas raised earlier, that I feel you might have missed.

This doesn't make any sense, the squirrel should be lighting up when there's a shadow in the background. That's when the light is touching it. Unless you already noticed it (you said you were gonna change some stuff about it still).

Also feel I should comment on the bat hunting/food gathering discussion.
I kinda like all the various ideas that have been posted however I don't think the slugcat should refuse eating food like a binary switch... or that there should be any binary switch regarding hunting/feeding behaviour. Maybe the behaviour could change like, not looking at/being interested in bats, or leisurely eating them instead of rushing the meal at the first chance it gets... I'm sure you guys will come up with a good solution eventually.

Again, I really love the work you guys have done on this. Looking forward to more awesome stuff.

[marcgfx]

how about just not grabbing bats, if you are not intending to eat them? would be pretty obvious, that slugcat is not hungry. or do the bats have other uses, besides eating them. can i throw one at a lizard, so he loses interest in me?