I've mentioned a couple of things (here and on Discord) which I'd rather implement with new blocks rather than keep the original behavior for. So here are my ideas for those new blocks:

Grating:

A block intended to replicate the utility of blocks falling through terrain when a boulder is pushed under them. Grating is a special type of platform that allows blocks to fall through it but doesn't allow Hannah to fall through, so if a crate placed on top of grating was disturbed, it would fall through. If an objects lands in a tile currently occupied by a grating, the grating will be destroyed. It doesn't necessarily make sense that a crate could fall though the grating but Hannah can't, but it makes more sense than falling through terrain and about as much sense as 1-way platforms in the first place.

Vines:

A block intended to replicated the ability of secret area to block arrows and allow Hannah through. Vines don't collide with Hannah at all, but are solid to arrows (and cannot be destroyed by them), so they can act as a shield to protect against arrow barrages. They'll probably interact with dynamite by blocking it and being destroyed by it just like an ordinary block. I think I'll also make vine blocks fall and be destroyed if the block above them is destroyed, so they can behave somewhat realistically when hanging in chains. They could also be destroyed by rolling boulders.

These are just my working ideas for these blocks, I'm definitely open to feedback. I think they'll also provide a nice bit of variety to the aesthetics of the game if their sprites look good enough, allowing map-makers to break up the uniform appearance of platforms and have things besides stalactites hanging from the ceiling.

I dunno if this is the rabbit hole I want to dive back down after all this time, lol...

Diagonal Arrows, enough said, really.

An invisible block that Hannah can't pass through. Not meant to be used for some obnoxious invisible maze or jumping puzzle, but as a way to make boundaries around a level in a way that would give it an open feel instead of every level being enclosed and claustrophobic.

Also, I think there should be a limit to the number of new blocks that are added so we don't get a ridiculous number of them.

I honestly think that diagonal arrows are not too good of an idea as they would break the grid system of HATPC. It's sort of theme-defying in the same way that eighth blocks are for Minecraft, despite how much people want them.

If a diagonal arrow hits a corner with three crates around the corner, which crate should it hit?

@CSD, krotomo, and everyone else
I don't want to add a bunch of blocks just because I can, I want to thoughtfully add blocks that improve the game. The two particular blocks I mentioned address particular needs that mapmakers have - the need to block Hannah but not falling blocks, and the need to block arrows but not Hannah. So yes, I'm trying to keep the number of blocks I'm adding to a reasonable number by only adding ones that serve an important role.

@Rocket Guy 2
I don't think diagonal arrows are really necessary, and they'd be a pain to implement. Not to mention that there would be no good way to code those in text. It was hard enough coming up with 4 extra directional characters for steel arrow crates.

@krotomo
Rather than implement a new block type specifically for letting map makers prevent Hannah from walking off the map, why don't I just prevent Hannah from walking off the map? I believe if you walk off the map right now the game just crashes because I didn't code anything special for that, but I'd say that the top, left and right sides of the map should act like walls and the bottom side should kill you if you fall into it. IDEK what the original HATPC does when you touch the map edge since I've never tried it, but that seems reasonable to me. In the flavor of the original game, you never actually touch the map edge since it's intended to seem like each level is a distinct cave surrounded by an endless field of terrain.

Also, did anyone actually read the OP? The point of this thread is to discuss the two block ideas I have, not to suggest a bunch more. Not that I'm not open to other ideas.

The grating could be interesting though I don't totally follow what you meant about when it was broken, but I'm sure it would make more sense once playing around with it. The vines don't seem all that necessary to me, I don't really think you need an object to shield Hannah from arrows, but maybe that's just me.

checkpoints

I don't think that new blocks would detract from the game. If making a user level, they don't have to be used. The wording regarding the grating is a little confusing, but the boulder making things fall through terrain has been implemented in many caves. Removing that mechanic might break a lot of older caves.

IMO I would just finish the base game first. Main amazing addition would be checkpoints, but other than that I don't think we need new blocks or many changes

@Harumbai
I don't really see a huge need for blocking arrows either, but I hear from CSD (who knows a lot more about the HATPC level building community than me) that user levels used to use secret area specifically for blocking arrows but letting Hannah through, and now secret areas no longer do that, so I figured adding a block that did do that might be in order.

As for the part where I said "If an objects lands in a tile currently occupied by a grating, the grating will be destroyed." keep in mind that the game is composed of a grid where you can never have two stationary blocks in the same position, kind of like how you can never have two blocks in the same position in Minecraft. However, since falling block can fall through grating, if there's a solid block (something that stops falling blocks) directly below the grating, the falling block will stop in the same position as the grating, replacing it. This is sort of like in Minecraft how falling sand will break if it falls on a torch, except the opposite. The falling block will take precedence over the grating.

So, for instance, if grating was - and you had a cave like this:



and Hannah pushed the boulder to the right, you'd end up with this:




@aych bee
I was already planning on adding those. I just need to figure out how to implement them.

I agree with FlashMarsh and Soccerboy. I'm mainly afraid that the mechanics won't let us play our old, good caves. I know the game won't maintain the same, exact 100% mechanics, but IMO I'd at least try to finish the base game first. Too bad that it'd already conflict with some caves since secret areas let the arrows pass through now.
A controlled amount of new blocks is a good idea.

Well, I don't think I'm ever going to get to the level of being exactly like the original that the old caves can be played without modification, at least the complicated ones. They rely on so many glitches and/or such precise timing that there's really no way I could replicate that behavior exactly. Instead I'm opting to make it so that those caves could be modified to work in the new version and new caves with similar mechanics could be created. Honestly, replacing arrow-blocking secret area with vines and floors that blocks fall through with grating will be the easiest part of converting those caves to work in the new game, the minor physics differences will have a much larger impact I expect by changing the timing.

I guess right now, we kind of replicated grating by putting a spike over a hole in the floor, but a non-lethal platform equivalent could open up some new options too. I'm in favour of adding grating.

Checkpoints are an interesting one, and a feature that could make the game much more accessible. The question is of how you would implement them:
* When the player respawns, all the entities return to their starting positions, excluding collected treasures. This would probably be the easiest version to implement, but the least useful.
* When the player respawns, all the entities remain where they were when the player arrived at the checkpoint. Though what about objects in motion? Taking that snapshot could be tricky. This could also leave the level in an unbeatable or unplayable state. This version only really works with linear caves.
* When the player respawns, all entities are set to a configuration specified by the level designer. This adds a fairly significant burden on the level designer - they can't just dump checkpoints in one click. This version could work better with caves that have branching and backtracking, but could be really complicated to make.
* What happens to the treasures that the player collected or didn't collect en route to the checkpoint? If I reach a checkpoint without getting any treasures, do I magically collect them when I respawn, respawn without them, or is that checkpoint only activated when I've collected all treasures up until that point? If it's the latter, the level designer would need to mark any treasures they want to associate with a given checkpoint.
* The level designer may need to specify checkpoint ordering. Also, if I reach checkpoint A, can I return to it after hitting checkpoint B? Do we assume that a checkpoint is forever disabled after the player has moved through it to another checkpoint?
* Due to this complexity, checkpoints will probably need some metadata associated with them. You'll need to decide where in the level code this will live.

Based on the above, my first stab at the checkpoint concept would be this:
* Have two types of checkpoints, a Simple Checkpoint and a Complex Checkpoint. The simple one just preserves the state upon arrival. The complex one requires a whole level state to be specified by the user. In the level code, this could be encoded at the bottom as the delta between the starting state and the respawn state, using triples of the form <xCoordinate, yCoordinate, entityTypeOnRespawn>.
* This encoding could also implicitly specify the order of activation.
* It could also specify the coordinates of any treasures required to activate each checkpoint.
* Each checkpoint must respect the specifications of previous checkpoints, unless they conflict, in which case the latest checkpoint's specification takes precedence. e.g. If I pass through checkpoint A, which specifies a boulder appears at (1,1) on respawn, pass through checkpoint B, which specifies a steel crate appears at (1,1) on respawn, and then die, a steel crate will appear rather than a boulder. However, if I had died before checkpoint B, the boulder would appear.
* e.g...


I don't think implementing checkpoints will be easy, but if you use a simple encoding like above based on simple rules, it might not be so bad. A fun programming challenge, I'd say.

A checkpoint that just maintained the starting state could be specified as a complex checkpoint without a state encoding:
  

I was just planning on making a simple checkpoint that saves everything in the game state when you reach it and then including an option to restart the level rather than starting at a checkpoint (in case you missed treasures). As for whether the player can loop back and activate the same checkpoint twice, I'm not sure.

I have a few opinions on things.

First off, we should only worry about this stuff once you've gotten far enough that all main levels are playable. Maybe it's something to think about as we move forwards but I wouldn't get too caught up in ideas for new tiles yet.

I feel kinda bad for you, DroidFreak, because you've said repeatedly that you're okay with making changes that break old caves, and yet repeatedly I hear people talking about how your changes are gonna break old caves. It almost feels like it's gotten to the point where you've heard it so much that you're now trying come up with ideas for new blocks that will act as workarounds to help fix our old caves (which would be ill-advised)

For the grates idea, you're not actually replacing functionality. You're implementing part of the functionality, but it wouldn't translate to be able to replace the actual trick and what it brings to the game. There are two reasons why the boulder-under-blocks trick is so appealing that I probably use it at least once or twice in every level.
1. It is triggered through boulders, making it incredibly flexible. I've always found boulders extremely useful for level design because they are the only object that Hannah can physically move around.
2. It is pretty subtle, doesn't stand out in the level or level map, and is a bit unintuitive. This is nice because it keeps the map clean, makes the solution less straightforwards, and makes the level design just feel more satisfying.

The idea of this grate block would be pretty limiting in comparison, at least if you're talking about it as a replacement for the functionality of this glitch. In most cases it would be comparable to a column of spikes with a platform across the top, like so:

x#  o x
xx= =xx
xxxmxxx
xxxwxxx
xxxmxxx
xxxwxxx
xxx xxx

Obviously this would still add new functionality, like you could have Hannah dodging a bunch of falling objects in a room where the objects don't immediately stack up. But what I take issue with is that it sounds like you've come up with this to replace a commonly used trick, rather than you've just come up with this idea because you thought it would be a good idea. There are gonna be some things in hatpc that you think shouldn't be included or should be done differently. People will complain. You should either press forwards with your view anyways, or if you think the argument for keeping said functionality is good enough, you can (try to) add it in. You can't make both worlds happy without making 2 versions of the game.

So basically my opinion is, let people complain about missing features/glitches. If you think they bring up good enough points, then try to implement it. If not, push forwards on implementing the base game. Don't worry about ideas for new tiles until after you're done with the base game. Then we can argue about the worthiness of a trick that allows objects to fall through other objects. Oh, and don't add any objects solely to replace functionality that you removed. Gotta be a good idea for a block irrespective of what we're used to or what we've done in the past.

Thanks Quirvy, I'll keep that in mind.

don't let them get you down droidfreak36 this is miles ahead of any hatpc remake that's been done so far