Passable platforms?

[DivFord]

A fairly common feature in platformers is a type of platform that you can jump up through (and often drop down through by pressing down). For example, the wooden platforms in Frogatto: http://www.winsoftware.de/screenshots/big/frogattoscr.png

I was thinking about level design, and it struck me that at the moment, we can only let the player move upwards by placing steps, which take up a lot of horizontal space. The proposed jump pads help with that, but I don't know that we'll want them in every zone. Basically, I think this sort of platform might be quite handy.

So, my question is this: Is this something we can do with the engine we have? If it is, is it simple enough to implement that it would be worth doing?

[Fyll]

To answer your first question: Not easily.

I do think it'd be a nice thing to have, but it'd be quite tricky/roundabout. The way I can see to do it would be to use an EFF_PLAYER_ON effect (this'd also be good for the crumbing props) to cause it to become solid, but de-solidify every turn. Then, if you're standing on it, it's solid, but if you're anywhere but on top of it, you'd be able to pass through.

This wouldn't allow you to drop down by pressing down or anything like that, but without changing things quite a lot, I imagine it'd be the best approach.

As an alternative I thought up while writing this, we could change solid to be a Direction rather than a bool... It'd require a lot of rewriting, but would be the most elegant solution I'd think. The main worry is that it might play up a bit, and it'd be hard to check specifically which something is contacting it from.

[DivFord]

That second one does sound quite good, but as you say, lots of re-writing involved.

Would it be possible to have a block group only place the top edge? And would that do what I think, or would you collide from both sides or be launched through it?

[Fyll]

I'm pretty sure that the collision code uses the inside() function to check if it's colliding, so, assuming you stopped it from automatically connecting the first and last nodes, it would be a mess (specifically, you'd constantly collide with it whenever you were between the middle of the group and the one edge).

[DivFord]

That makes sense… Ok, last suggestion before I give up: Could we bring back the old way of collision checking for the purposes of this block type? That is, check the cell immediately below the unit, if it's a platform, stop falling.

[Fyll]

I'd be against having essentially two bits of collision code if possible. Also, as shown by how that way needed rewriting, it was rather dodgy code.

I definitely like it as an idea, so don't completely give up! If it comes to it, we could just make it have an effect EFF_CAN_JUMP_THROUGH or something, and check this property against your y velocity before saying whether or not the Block is solid.

[DivFord]

That sounds like it might work… Do you think you could prototype it at some point? It doesn't sound too complex to implement.

[Fyll]

Hmm. It turns out it's not quite as easy as that. The problem arises when you jump into a Block, but not all the way through. I still think this is probably the way to do it, but I'll need to spend a bit more time thinking about it.

[DivFord]

You prototyped it already? Wow. Perhaps you could flag it as non-solid when the player jumps up into it, and leave it like that until they aren't inside it? Of course, that would mean it didn't play nicely with enemies.

[Fyll]

Prototyped and pushed. It has the code Bj, and is a Block that uses the Ice sprites. It all seems to work, but have a play around and see what you think.

It has rather shown me that you can't jump very high. I feel this needs further discussion.

[DivFord]

Seems to work, albeit with a few glitches.

• You have to jump to enter the block from the side. Not sure how to fix that.
• While in the block, it's possible to launch yourself out the level.

It doesn't work well if you put these blocks on top of each other, but maybe that's a feature rather than a bug. Why would you have a tower of platforms?

Not sure what there is to discuss with regards to jump height. The values we have at the moment, both for that and for movement speed, aren't ideal, but I assume it's just a question of tweaking values until we get something we like. I reckon we should be able to jump up about 1.5 blocks high. That's enough to comfortably jump onto a block, but with no risk of jumping up a 2 block-high cliff.

[Fyll]

I'll sort the side entry out when I get back. It should just be a matter of changing a `> 0.0fto a>= 0.0for something like that, possibly withSMALL_FLOAT`` instead.

The launching sounds wierd. Any further info? They get a bit tempremental about letting go of you, but I thought I'd managed to iron that out.

Yeah, I hadn't thought about doing that. I see no sensible way to allow that using this method, so let's agree that a tower of platforms is a terrible idea. :P

Fair enough. I always tested the platform being a whole tile above you, so couldn't actually jump onto it without increasing the jump height (I miss the cannon jetpack D:). Thinking about it though, do we want it as a Block or a Prop? I made it a Block, but am having second thoughts. A Prop makes more sense from the point of view of it being a platform, rather than wierd terrain. Also, if it were a Prop, we could make it narrower than being a whole tile wide, which'd probably help out with a lot of problems (due to there being less collision space to worry about). Actually, yeah, I might try that too when I get home. I've got my heart set on a moving platform now! :D

[DivFord]

I'd be in favor of making it a prop. That way, I could make scaffolding as a non-solid block, and we could place the platforms on top of that. I think that would look pretty good.

"narrower than being a whole tile wide" - Wouldn't it make more sense for it to be one tile wide, but less than a tile high?

[Fyll]

That's what I meant to say. Honest! Although we would also be allowed to make the platform wider or thinner if need be.

On Fri, Jan 22, 2016 at 11:49 AM, DivFord notifications@github.com wrote:

I'd be in favor of making it a prop. That way, I could make scaffolding as a non-solid block, and we could place the platforms on top of that. I think that would look pretty good.

"narrower than being a whole tile wide" - Wouldn't it make more sense for it to be one tile wide, but less than a tile high?

— Reply to this email directly or view it on GitHub https://github.com/mspraggs/potentia/issues/104#issuecomment-173896407.

[DivFord]

Investigating the launching bug, it seems to happen when you move upwards and sideways at the same time. I've only been able to do it with the cannon though, not by jumping.

This is the setup I've been using for testing. The launching is to the left, so I think the problem is that while I'm inside the platform, weird things happen to collisions with the wall.

[Fyll]

So, when you shoot a cannonball through it, the cannon ball sometimes launches out? It's fair enough that I didn't see that then, as I always test things on the menu screen, which is now a gun-free zone. :(

I've had an idea as to why it might only be acting up for Bullets: It may be because Bullets move so quickly. I can definitely see a way in which that could cause problems, involving clipping through corners at just the right angle. I don't see how it could travel through the walls, but it would be thrown one (quite large) step into them before dying.

On Fri, Jan 22, 2016 at 12:01 PM, DivFord notifications@github.com wrote:

Investigating the launching bug, it seems to happen when you move upwards and sideways at the same time. I've only been able to do it with the cannon though, not by jumping.

This is the setup I've been using for testing. The launching is to the left, so I think the problem is that while I'm inside the platform, weird things happen to collisions with the wall.

[image: platforms] https://cloud.githubusercontent.com/assets/10687893/12510175/e00a4f5a-c0ff-11e5-9d7f-124b87b66974.png

— Reply to this email directly or view it on GitHub https://github.com/mspraggs/potentia/issues/104#issuecomment-173899933.

[DivFord]

No, it's the player getting launched. I just meant that I used the recoil on the cannon to push him up and left.

[Fyll]

Hmm. Well, that's wierder then. I'll stare at the code some more tonight. Feel free to play around with it if you want, it's all just in the second to last function in Skeleton.cpp.

On Fri, Jan 22, 2016 at 12:32 PM, DivFord notifications@github.com wrote:

No, it's the player getting launched. I just meant that I used the recoil on the cannon to push him up and left.

— Reply to this email directly or view it on GitHub https://github.com/mspraggs/potentia/issues/104#issuecomment-173908849.

[DivFord]

My theory is that I overlap the edge of the platform while I'm jumping, then it becomes solid and shunts me out. I'd suggest leaving this until you've made the switch to a prop, in case that fixes it. If the platform is thinner, it would presumably shunt you to the top or bottom instead.

[Fyll]

Right, I should probably update on what I've (not) been doing. I changed it to a Prop yesterday, but then ran into a load of problems because the collision engine doesn't like thin Objects (I'm thinking of an efficient way to overcome that problem, but that's lower on my list of priorities). Also, the code was just a mess of things that somehow worked, despite any and all logic.

So, I spent today procrastinating and playing games. Just after I'd finished this tiring task, it suddenly occurred to me that directions can be auto-cast to bools. So I decided to just try that approach, as it only involved rewriting about 4 lines of code, and tweaking all of the lists.

It's all working (I think) and pushed now. The platform's code is "Pj".

[DivFord]

It works for me. Plus, the launching bug seems to be gone. Hooray! However, there's something weird with my jumping. Sometimes I just can't jump. It feels like I'm stuck to the ground. Would your changes to direction have had any effect on the jumping code?

This looks like it's going to work, so I'll add the art to my to-do list. Along with procrastinating and playing games, of course.

[Fyll]

Yeah. I noticed that when changing beams to work with the platforms (will be pushed after I fix this). I think it's just a rounding error or not-quite-zero error, and will have a poke around.

EDIT: Just poked. It turns out that's not the problem. For some reason, you're only colliding with the platform on every second frame... To be honest, I'm not sure why the jump leeway's not sorting this out.

EDITx2: It turns out the leeway was being too strict, so I've loosened it up (i.e. you were being pushed up out of the platform each frame, and it turns out that every second frame your net movement was slightly upwards, rather than downwards, so the jump leeway just ignored you. Hence, no jumping). I'm still going to look into why it's doing this at all, but I'll push this working version.

EDITx3: And, fixed. it was because when you were moving slowly enough (i.e. standing y-still on top of the platform), the platform got confused and couldn't decide whether or not it should be solid.

EDITx4: There's now also a (horizontally) moving platform. It's code is "Up", and it initially moves rightwards from where you place it. At the moment, it doesn't hold you, so you just slide off, but I'll look into that later.

[Fyll]

You now stick to the platform as it moves. The end result feels a bit hacky, but the idea of a moving platform doesn't make much sense anyway (as the platform cannot be moved, but is able to move itself. Naturally, this makes collisions wierd), so it'll do until something else breaks it (it's all in its own function, so would be easy to cut out or change).

Also, as a consequence of this, bouncing is back in (so bouncy Blocks will be good to go down the line).

You still get pushed a bit wierdly when you pass through a platform, and can get thrown by it in some corner cases, but their separate from the sticking-you-to-the-platform code, so I'll look into them separately.

EDIT: A note to future me in case I forget (and in case anyone else is interested in what's going on here), I think this is a fault of the dodgy drag code, as commenting it out seemed to remove this problem altogether. Seeing as I'm intending to improve the drag, I'll leave this until after that.

[DivFord]

I'm updating the level editor to include the new stuff. Crumbling props are in without any problems, but the platforms cause the game to crash if I put them in a level.

Am I supposed to give them metadata? At the moment they're just using default settings (so coordinates and facing).

Are platforms just broken generally? I'm not sure what the input format for them is, so I can't tell if the editor is writing the wrong information, or if they simply don't work.

[Fyll]

I'll have a look when I get home.

Off the top of my head, they don't want a facing, just a list of coordinates (i.e. a path to follow), so it could be crashing because you've passed in an odd number of things (it sees the facing and goes "Ah, coordinates!" then tries to find the second one and crashes).

[DivFord]

I tried deleting the facing from the level file, and that fixed it. Good call. The question now is whether we want to make it accept a dummy facing value, or whether we should make facing a metadata value rather than a default part of unit data.

[Fyll]

I think my idea for not having a facing was so that the path it follows was a series of coordinates, rather than one pair of coordinates, a facing, and then the rest of the coordinates.

Can you think of anything else that wouldn't want a facing? I can't, unless it's another odd thing like the floating platforms (which are only pretending to be Units in order to get their hands on an AI). I suppose we could have the set of coordinates making up the path be separate from the starting coordinates. That way it would still accept a dummy facing, whereas now it'd be wierd (both from a code and aesthetics point of view) to have the path be broken up by putting the facing in second.

[DivFord]

Not off the top of my head, but we may well find something down the line.

Shall I just shift facing into metadata? It's easy enough to do in the editor code, and it sounds like it won't affect anything in-game.

[Fyll]

That's probably best then. It may already be metadata in the code, seeing as the floating platforms work without it.

[Fyll]

Having looked at the platforms a bit, the initial position is not actually included in the path, and the path coordinates are all upside-down (or actually, the position coordinates are all upside-down, which means that the path is upside-down compared to everything else).

Also, you should now have a much easier time walking through the platform and jumping through it, and standing on it, so I'm believing that's my part of this done....