Stack manipulation: more options? (& physics & a bug)

Help
1

Hello!

What a nice suprise the Manjaro pakcage manager came up with!

I’ve been searching high and low for ages for a FOSS light game prototyping option. The third dimension matters, which made Vassal impracticable.

So I’ve been toying with singleplayer TC a bit now. It’s awesome, so bravissimo to drwhut and every other contributor :smiley:

===

I have hit a few snags, particularly for the stack manipulation I’m looking for. A rewrite is ongoing, but this may remain relevant.

What I need: stacks of game pieces (think wooden cubes, magnets etc.) that:

  1. can be easily moved around as a whole, without toppling or breaking up
  2. can conveniently be split into smaller stacks
  3. can have pieces added or removed at/from any location in the stack, not just the top

The current token stacks do (1), but (2) and (3) seems limited to removing the top x tokens. I imagine more options would be convenient for cards too, not just tokens.

EDIT: I realised just after posting that (2) and (3) are in fact quite easily proxied by a few remove-top-x and drop operations, particularly for unmarked tokens where you don’t need to inspect their upper face. For marked tokens and cards, a more involved interface (e.g. fan of cards, or just a list with selectable items) might still be worth the effort? So you can e.g. easily find all the aces in a deck and put them on top.

I tried the alternative of ‘DIY stacks’ by just piling up those cuboid number dice, but this is far too finicky to work. (It’s hard to stack them to begin with; and stacked dice keep jittering around and toppling. I noticed an issue on Github where the poster felt the physics are ‘too realistic’ and should be toned down for gaming convenience. They do feel very high-strung and bouncy and, to me, hyperrealistic… For instance, it’s really hard to gently lift the chessboard without all pieces flying off wildly. And fallen pawns seem to keep rolling like a perpetuum mobile. Must be a universe with different fundamental constants ;-))

Even if the physics were toned down a notch, toppling would probably remain an issue for DIY stacks. I reckon ‘magically’ sticky game-defined stacks are the way to go.

So for concrete questions:

  1. Is a stack manipulation interface with more possibilities (as above) planned, or might it be considered?
  2. Has anyone created stacking cubes/cylinders/etc. assets yet? If not I’ll have a gander, but no need to do double work.

===

Finally, a ‘weird’ stack-related bug:

  • add a chessboard to the table
  • add 10 square tokens to the table to form a single stack, one of each colour (colour may or may not matter)
  • lift the stack and scrollwheel it down ‘into’ the chessboard
  • voilà, your stack is now shuffled :-?

I imagine that’s not the intention. Stacks with other numbers of tokens seem resistant to this forced shuffling, but I haven’t tested systematically.

===

Thanks for all your efforts! (^_^)b

2

Hey there! Thank you for the kind words, it means a lot! :grin:

For marked tokens and cards, a more involved interface (e.g. fan of cards, or just a list with selectable items) might still be worth the effort? So you can e.g. easily find all the aces in a deck and put them on top.

This could be doable, since container objects have this functionality already. One of my plans for the re-write was to make containers and stacks more streamlined, so that they have the same, or very similar, functionality, since stacks are essentially just containers whose visuals are the objects stacked on top of each other. I’ll keep this in mind when I get round to re-writing containers!

I tried the alternative of ‘DIY stacks’ by just piling up those cuboid number dice, but this is far too finicky to work.

Agreed - I really, really want something like Jenga to work properly in TTC, but the physics engine just won’t allow it currently, since as you’ve seen the objects will jitter ever so slightly and it will inevitably fall over no matter what.

I can’t guarantee this will be fixed for v0.2.0, since the game will still be using the Bullet physics engine, but my hope is that once the project is eventually migrated to Godot 4, I can try and use the Jolt physics engine, which is supposedly a lot more robust.

For instance, it’s really hard to gently lift the chessboard without all pieces flying off wildly.

Yeah, that’s why I have it locked by default when you load up a Chess game :rofl: I’m working on ways to reduce these kinds of annoyances, so for example, when you grab an object that has other objects on top of it, the force of the object being lifted launches the other objects into orbit. One way I plan to stop this is by having the lifted object temporarily enter a different physics layer, so it does not collide with any other objects as it is being picked up.

I hadn’t considered pieces on top of boards being dragged along with the board before… it makes a lot of sense though, I’ll see if there’s a way to implement this. For now though, probably the best way to do it would be to select all objects (both the board and the pieces), and drag them all at the same time.

And fallen pawns seem to keep rolling like a perpetuum mobile.

I still have no idea what causes this :neutral_face: I’ve tried messing with friction constants, and they don’t make a difference in this regard. Physics engines being physics engines I guess!

Is a stack manipulation interface with more possibilities (as above) planned, or might it be considered?

Yeah like I said above, I would like for stacks and containers to have similar functional parity with each other in v0.2.0. I’m also thinking of ways to make them more intuitive, so for example, when you add a card on top of a deck, you have to use the card’s shadow to line it up with the deck. Instead, I want to make it so you just need to have the mouse over the deck as you’re holding the card, and once you let go of left click the card will fly onto the top of the deck.

Has anyone created stacking cubes/cylinders/etc. assets yet? If not I’ll have a gander, but no need to do double work.

Not that I have seen yet, no.

Finally, a ‘weird’ stack-related bug:

Yeah, this is due to the way the game determines if a stack is being “shuffled” or not - currently it is done by seeing if the acceleration of the stack changes from positive to negative, or negative to positive. Although, there are edge cases like you’ve spotted here where it ideally shouldn’t shuffle. I’ll try and see if I can either make the conditions for shuffling more strict, or come up with a better check altogether, e.g. having to drag the stack left and right multiple times before it is detected as being “shuffled”.

3

Hi again :slight_smile:

Interesting; I’m glad this functionality might be within not-too-distant reach!

And Mikado as the ultimate test?

Yes, that seems an eminently sensible solution for now.

I suppose you have already considered some sort of snapping system? E.g. where each asset can optionally define snap points or surfaces on the object (64 on a chessboard, 1 per piece), and if a selected object with such a snap zone is released close enough to another snap zone, they’re forced to collide very gently, or just juxtaposed right away? With lighter moving to heavier, or higher to lower, or …? Perhaps it gets way more complex than I imagine though.

Right :-\ As the owner of an ageing laptop, I do wonder how much CPU and RAM gets burned by those overzealous computations…

I find the ‘way of the shadow’ pretty elegant actually, but agreed, what you propose sounds even better.

Oh okay, I didn’t realise one can shuffle that way. Neat :slight_smile: Maybe monitor mouse movement rather than the object’s acceleration?

4

I suppose you have already considered some sort of snapping system?

Yeah, that is planned for v0.2.0, where boards can have configurable snapping points for specific pieces.