![[pl]](/mwf/flags/pl.png "Poland")
Pixels... we all know them, and love to get stuck. My request is simple - when player presses movement keys, but his clonk does not move - perform a check if he is stuck, and free him. This would wear off the most painfull thing in Clonk...
What if some clonk without a shovel got burried by an enemy attack? There must be checked more than just Stuck(). But it's something I would like to get rid off too.
No, it would check if he is stuck "a bit" when he is completly, or mostly buried he does not get free. Maybe limit of removing max of 5-6 pixels? Also usually players get stuck when climbing, that could be considered as well.
![[de]](/mwf/flags/de.png "Germany")
I don't like the idea of solving this problem with some sort of an unstuck check.
It would be much better to remove the origin of the problem, that would be:
a.) Living creatures and moveable vehicles shouldn't get stuck at small amounts of material.
or....
b.) Small amounts of materials should fall down to the ground (like Fly-sand).
It would be much better to remove the origin of the problem, that would be:
a.) Living creatures and moveable vehicles shouldn't get stuck at small amounts of material.
or....
b.) Small amounts of materials should fall down to the ground (like Fly-sand).
The (b) option is great! I agree ith that, but sometimes players can get stuck on walls, not sinlge pixels. And btw. something disallowing clonks to get stuck would be nice as well.
b is still as calculation intensive as it used to be.
Would a mean vertex-areas?
Would a mean vertex-areas?
![[ca]](/mwf/flags/ca.png "Canada")
I don't know how vertexes work (in the engine), but maybe lines could be drawn between chosen vertices? These lines could collide with landscape or somesuch.
Polygonal landscape is the plan for OpenClonk's landscape, is it not? Surface area checks aren't that CPU-intensive iirc.
There's actually already a half-assed implementation of option b.) in the engine, after survivor suggested something similar: When digging the engine will look at the edges for single pixels and remove them. It will also somewhat smooth hard edges (making digging through ceilings much easier than it used to be).
Apart from that, it shouldn't be that hard to implement. There's already the special pixel counting code in the engine that disregards small pixel groups (used for oil). Destabilizing such pixel groups won't be that hard.
On the other hand, I still think that the best solution against small pixels is just removing small pixels from the game in favor of, well, bigger pixels. Though we will need some graphics code to make them look well. See also below.
Apart from that, it shouldn't be that hard to implement. There's already the special pixel counting code in the engine that disregards small pixel groups (used for oil). Destabilizing such pixel groups won't be that hard.
On the other hand, I still think that the best solution against small pixels is just removing small pixels from the game in favor of, well, bigger pixels. Though we will need some graphics code to make them look well. See also below.
The core problem is something you seem to take for granted: Detecting whether the Clonk is stuck. The only real surefire way to make a Clonk stuck is embedding one vertex three pixels thick into material - a situation that's highly improbable in normal play.
In reality, most "stuck" situations arise because the movement procedures of the Clonk have some kind of loop for the given terrain, or the wrong vertex is embedded for the given procedure. Detecting both is not directly trivial. Doable, yes - but one needs to keep in mind that there are a huge number of terrains a Clonk might encounter, and dozens of different procedures that might work on it. That it works as well as does is most likely the result of an evolution of the movement procedures that stretches back a good deal to matthes' original code. And literally nobody has dared to touch the code since then because it's most likely to break more things than in fixes. Even Sven's fix for the multiple vertex attach bug turned out to have unforeseen consequences, as suddenly watchtowers could be climbed.
Now we obviously have some more flexibility with OpenClonk (I think Sven's fix is now the default). One key aspect, imo, is that we can now choose the Clonk scale freely (relative to landscape pixels). So if we just scale the Clonk down, we might cut down the number of corner cases substantially and make dealing with such situations much easier. So then it might be worth to revisit the issue. But before that, I'm not optimistic that significant improvement is possible without months of tracking down corner cases and producing horrible spaghetti code.
(And just for the record: I consider polygon landscapes to make matters worse, because it's actually even more difficult to get a grip on all possible cases.)
In reality, most "stuck" situations arise because the movement procedures of the Clonk have some kind of loop for the given terrain, or the wrong vertex is embedded for the given procedure. Detecting both is not directly trivial. Doable, yes - but one needs to keep in mind that there are a huge number of terrains a Clonk might encounter, and dozens of different procedures that might work on it. That it works as well as does is most likely the result of an evolution of the movement procedures that stretches back a good deal to matthes' original code. And literally nobody has dared to touch the code since then because it's most likely to break more things than in fixes. Even Sven's fix for the multiple vertex attach bug turned out to have unforeseen consequences, as suddenly watchtowers could be climbed.
Now we obviously have some more flexibility with OpenClonk (I think Sven's fix is now the default). One key aspect, imo, is that we can now choose the Clonk scale freely (relative to landscape pixels). So if we just scale the Clonk down, we might cut down the number of corner cases substantially and make dealing with such situations much easier. So then it might be worth to revisit the issue. But before that, I'm not optimistic that significant improvement is possible without months of tracking down corner cases and producing horrible spaghetti code.
(And just for the record: I consider polygon landscapes to make matters worse, because it's actually even more difficult to get a grip on all possible cases.)
Well, the other "obvious" fix would be to make the movement procedures no longer employ a lot of either-or decisions. All objects and all walls are completely rigid, which does not resemble the real world much at all, and it's no wonder that things get stuck. I think an approach that assumes that objects bend when faced with a wall could do a lot better. Even if we don't go all the way to those equation-solving physic simulation engines which do stuff that takes a lot of time to understand. Unfortunately, I think you're right that any change here would first make things worse before they can tweaked to be playable. But that applies to your suggestion as well, and I don't think we can make a coarser grid feel better than the current one: Players are going to notice it even if they cannot see it.
I doubt bending objects can really formally solve the problem that there's possible to have landscapes where you can get in, but can't get out. I mean, we still need limits on how far the Clonk is able to stress his bones or move his vertexes, or the Clonk will be able to get through anything. On the other hand, making Clonk pancakes with an elevator might be kind of fun ;)
And what exactly do you mean by "Players are going to notice it"? Obviously you're going to see it if you're playing side by side. The real question is what kind of problems it could cause. And I, for one, can't see any substantial gameplay issues arising at least until the Clonk is about 3 pixels tall (not that I'm advocating that, I'm actually talking about 50%, tops). You can still dig, mine and have all the fun in the world. The engine will "just" have to work harder making the whole thing pretty. The engine will have to do it anyway - and I'm pretty sure anything we can come up with is going to be prettier than the ugly pixel noise left over by, say, granite.
And what exactly do you mean by "Players are going to notice it"? Obviously you're going to see it if you're playing side by side. The real question is what kind of problems it could cause. And I, for one, can't see any substantial gameplay issues arising at least until the Clonk is about 3 pixels tall (not that I'm advocating that, I'm actually talking about 50%, tops). You can still dig, mine and have all the fun in the world. The engine will "just" have to work harder making the whole thing pretty. The engine will have to do it anyway - and I'm pretty sure anything we can come up with is going to be prettier than the ugly pixel noise left over by, say, granite.
They are going to notice that there are steps. If the Clonk is ten pixel tall, one pixel is about as steep as a step in a stair for a human. So you couldn't differentiate between a stair and a ramp. And the Clonk probably shouldn't be able to climb more than one or two pixel at a time, so a small mistake in digging would lead to climbing.Hm, thinking about it again, the real change a smaller Clonk would have is that there would be more vertices per area. We should probably first try to get the same effect with more vertices. The "weird behaviour with more than one vertice with the same CNAT" problem should be fixed, and the performance disadvantage might not be noticable anymore.
Sorry if I'm getting unfair, but seriously, stairs? When was the last time someone did stairs? I only remember some from that old ghetto scenario. Back then, it didn't even make that much difference in terms of Clonk movement - but I distinctly remember that a notable difference was that you couldn't properly jump from them and you were very prone to fall them down (so to speak). Making it ramps would have made it a good deal better from a gameplay point of view - and I'm open to adjust graphics as far as needed to make the ramps actually look like stairs if someone wishes to (material flag?).
My initial idea was to cut the Clonk down to 4 vertexes or something to that effect (maybe 5 - with 2 at the top to make scaling over stuff harder?). More vertexes actually sound like more reasons for the Clonk to get stuck. I stay by my point: If we're trying new stuff, let's make sure we move into the direction of less complexity.
> Hm, thinking about it again, the real change a smaller Clonk would have is that there would be more vertices per area.
My initial idea was to cut the Clonk down to 4 vertexes or something to that effect (maybe 5 - with 2 at the top to make scaling over stuff harder?). More vertexes actually sound like more reasons for the Clonk to get stuck. I stay by my point: If we're trying new stuff, let's make sure we move into the direction of less complexity.
My point is that for a ten-pixel-Clonk one pixel would already be a stair step, so there would be steps everywhere.And a Clonk completely covered by vertices would be unable to get a stray pixel into it's body. Admittedly, it would work even better if most of those vertices would be "soft" and just gently nudge the Clonk away from the wall, instead of forcing a complete and immediate halt.
Or ramps everywhere, depending on how you see it. I still don't get what the problem is - are you worried that the Clonk might "stutter" when climbing?
Having no material "inside" doesn't automatically imply that you can't get stuck either. Well, admittedly, it also cuts down on the possible cases - but then again we will still have landscape changes (loam, elevator, freezing water...), teleporting and the likes. We can't just have the Clonk teleport or die when this happens. We need stuck Clonks somewhere in the design.
> And a Clonk completely covered by vertices would be unable to get a stray pixel into it's body.
Having no material "inside" doesn't automatically imply that you can't get stuck either. Well, admittedly, it also cuts down on the possible cases - but then again we will still have landscape changes (loam, elevator, freezing water...), teleporting and the likes. We can't just have the Clonk teleport or die when this happens. We need stuck Clonks somewhere in the design.
> are you worried that the Clonk might "stutter" when climbing?
It'll stutter just walking around. You couldn't have slightly uneven terrain anymore, you'd be limited to really uneven terrain. And the player will notice that an uneven but mostly flat terrain just has two or three different height levels.
> We can't just have the Clonk teleport or die when this happens.
Can't we? There's no reason teleport couldn't be limited to air and liquids, and the other changes are fairly local, so moving a Clonk out of the way wouldn't be teleporting.
Well, it's obviously right that at some point, we will get stuttering problems - but do we really know where the lower limit is? I'm just arguing that we should test it. Just using the sizes from CR seems awfully arbitrary to me. Those were probably chosen more for graphical reasons then for anything else.
Other changes? It's just that I strongly suspect it'd be easy to have one Clonk push the other through, say, a castle wall just by using one or two loam appropriately.
> Can't we? There's no reason teleport couldn't be limited to air and liquids, and the other changes are fairly local, so moving a Clonk out of the way wouldn't be teleporting.
Other changes? It's just that I strongly suspect it'd be easy to have one Clonk push the other through, say, a castle wall just by using one or two loam appropriately.
Btw, I decided to try it out - having a 50% Clonk with only 5 vertexes (of which one is for attachment) seems completely viable from the Clonk's movement point of view. Sure, it makes you "feel" pixels a lot more, but that's not necessarily a bad thing in my opinion, as it also makes it easier to predict what the Clonk will be doing. So you can obviously see some stuttering when you are moving the Clonk slowly and zoom in a lot - but that's also the case with the current Clonk.
Well, the problem is obviously that I can't claim to have a killer argument why we should introduce it. I do think it would save us a lot of trouble in the long run. I guess that's not enough to turn the running ship around now?
Well, the problem is obviously that I can't claim to have a killer argument why we should introduce it. I do think it would save us a lot of trouble in the long run. I guess that's not enough to turn the running ship around now?
A quick test scenario is now in the repository. Note that 50% is quite extreme, so it's obvious that the rest of the game doesn't quite match (wrong physicals, Scale->Walk pushes the Clonk too high etc.). Plus the lack of proper landscape shaders is really apparent now.
> Sure, it makes you "feel" pixels a lot more, but that's not necessarily a bad thing in my opinion, as it also makes it easier to predict what the Clonk will be doing.
Only if you can actually see the pixels as well. I haven't tried it, but imho making the player aware of the pixel based nature of the landscape is not on the list of things the player should be reminded of.
Well, most CR players are aware of it after some point - so all we're doing is making the learning process easier. If there are inadequacies to the model (which I guess you are suggesting?) we should try to address them instead of hiding them by throwing complexity at the player.
We could, for example, interpolate sub-pixel Clonk movement by just looking a step farther for the current attached vertex. That would fix the whole stuttering problem. Hq3x or friends are more than capable of making the landscape look equally smooth.
I do think we could pull this off if we want to - and I'm pretty sure we will need it anyway for the zoom to look good in all circumstances.
We could, for example, interpolate sub-pixel Clonk movement by just looking a step farther for the current attached vertex. That would fix the whole stuttering problem. Hq3x or friends are more than capable of making the landscape look equally smooth.
I do think we could pull this off if we want to - and I'm pretty sure we will need it anyway for the zoom to look good in all circumstances.
>Hq3x or friends
I didnt follow your discussion but regarding the landscape I need to add that I created all the textures which are now in Materials.c4g in the assumption that they will be displayed at full resolution when zoomed in 3x times. So the size of the features and details in the textures are tailored for being displayed fullres at 3x and zoomed to 33% when viewed at the standard CR zoom factor.
I don't think this would be a problem. If I'm not mistaken about how shaders work, having a per-texture scaling factor would be the least of our worries.
And they already are with the highres landscape option. I guess we should implement downsampling for the computers which cannot use that option.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
