On the off chance that you have a genuine interest in knowing the answers to your questions, and are not grandstanding, I will answer.
First differentiate between the syntax and the tool. This isn't a tool that supports every possible game. It is designed for creating movement-based puzzle games. Though it can support many others, that is its focus. You can certainly stretch it to do Tetris or Threes, but probably not Mario.
If you are involved in game technology, it is a masterclass in supporting a very large (but still restricted) class of games in a very small tool set.
So, specifics:
> if I wanted something to turn into a different item
[> Player | Box] -> [Player | Contents]
assuming you open your box by moving into it, or
[Action Player | Box] -> [Player | Contents]
if you want to press the action button.
> What if I want something to slide over multiple tile spaces
[ > Player | Crate ] -> [ > Player | > Crate ]
[ > Crate | no Wall ] -> [ | > Crate ]
The first line says moving into a crate sets the crate in motion. The second line says it keeps going until it hits a wall.
> if I want the item to progressively become more difficult to move
What does it mean to become more difficult, given that moves are atomic actions? (Back to the restricted domain of this tool.) But, for one possible design, we can do:
Regular players can move only light objects, strong players can move either.
The ethos of the system is that to change state, you change object type. This is less restrictive than it sounds, because it is possible to layer objects. But it is still restrictive. And deliberately so.
> it doesn't do it well.
Based on the calibre of people who have used this, including for the rule development and level design for decently successful commercial indie games, it might be worth entertaining the notion that it might just be you. A more constructive and educational alternative might be to try and specify the same sophistication of rules in a more succinct syntax.
First differentiate between the syntax and the tool. This isn't a tool that supports every possible game. It is designed for creating movement-based puzzle games. Though it can support many others, that is its focus. You can certainly stretch it to do Tetris or Threes, but probably not Mario.
If you are involved in game technology, it is a masterclass in supporting a very large (but still restricted) class of games in a very small tool set.
So, specifics:
> if I wanted something to turn into a different item
assuming you open your box by moving into it, or if you want to press the action button.> What if I want something to slide over multiple tile spaces
The first line says moving into a crate sets the crate in motion. The second line says it keeps going until it hits a wall.> if I want the item to progressively become more difficult to move
What does it mean to become more difficult, given that moves are atomic actions? (Back to the restricted domain of this tool.) But, for one possible design, we can do:
Regular players can move only light objects, strong players can move either.The ethos of the system is that to change state, you change object type. This is less restrictive than it sounds, because it is possible to layer objects. But it is still restrictive. And deliberately so.
> it doesn't do it well.
Based on the calibre of people who have used this, including for the rule development and level design for decently successful commercial indie games, it might be worth entertaining the notion that it might just be you. A more constructive and educational alternative might be to try and specify the same sophistication of rules in a more succinct syntax.