increpare
commented
10 years ago Aha, that's neat. I hadn't thought about this combo before (I think the random keyword I put in at the very end after rigid had been added). This is far more straight forward/easier to understand than rigid, for sure.
Minor problem with your example, which is fixable, is that you probably don't want stuff to move twice in one turn - so you put a 'Moved' counter on something that you've actually moved, and don't move it again. Easily solved.
There must be some example that it doesn't cover. This stuff is really really tricky, and I convinced myself a thousand times before that there were easier ways to do it, to find a counter-example several hours after. If I could convert every example in the rigidbody doc, and also consult with people on the mailing list, then I'd possibly consider it good, mark the old use of rigid as deprecated.
Breaking backwards compatibility is in general to be crazy frowned upon - as a mostly-online game engine, people need to be able to rely on stuff not breaking. OTOH basically nobody has used rigid. OTOH basically nobody would use this either (though probably still an order of magnitude more), probably, so it might not be worth the destabilizing? The advantage would be that new people coming to puzzlescript could have a lot more fun and not think there was this crazy esoteric stuff they should be trying to master (though I think I do an ok job of hiding the rigidbody stuff already). Even in the case that it's cool (which it might be), it's still quite low priority/something of a luxury task.
Q: is there a game that you're trying to make that would make good use of this feature?
On Fri, Apr 4, 2014 at 7:24 AM, Ryan Hitchman notifications@github.comwrote:
Explicit backup & restore commands could be more intuitive than rigid, while allowing similar (greater?) power.
Here's an example, which is a simple extension of Scott Hughes "Iterated Extended Rigid Body Test", and uses random to apply a rule at most once:
LEGEND
Box = Box1 or Box2 or Box3 or Box4 Blocker = Player or Box or Wall
RULES
startloop
(pick one player to handle) random [ > Player | Box ] -> [ > Player | > Box ] backup
( propagate movements ) [ > Box | Box ] -> [ > Box | > Box ]
- [ moving Box1 | Box1 ] -> [ moving Box1 | Box1 ]
- [ moving Box2 | Box2 ] -> [ moving Box2 | Box2 ]
- [ moving Box3 | Box3 ] -> [ moving Box3 | Box3 ]
- [ moving Box4 | Box4 ] -> [ moving Box4 | Box4 ]
( try moving everything ) [ > Blocker | no Blocker ] -> [ | Blocker ]
( back out if anything was blocked ) [ > Blocker | Blocker ] -> restore
( cancel player's movement if it was blocked (we just restored) ) [> Player | > Box ] -> [ Player | Box ]
endloop
Backup makes a copy of the game state when it runs (after the rule it's attached to applies), restore sets the game state back to that copy. Restore without a preceding backup goes back to the beginning of the turn.
This seems more straightforward than the spookiness of rigid reverting and re-executing with a rule disabled, and fits nicely with mental models of cancel/checkpoint/restart.
Name possibilities: {backup,save,try,remember}/{restore,load,undo,revert}
Reply to this email directly or view it on GitHubhttps://github.com/increpare/PuzzleScript/issues/80 .
rmmh
Explicit backup & restore commands could be more intuitive than rigid, while allowing similar (greater?) power.
Here's an example, which is a simple extension of Scott Hughes "Iterated Extended Rigid Body Test", and uses random to apply a rule at most once:
Backup makes a copy of the game state when it runs (after the rule it's attached to applies), restore sets the game state back to that copy. Restore without a preceding backup goes back to the beginning of the turn.
This seems more straightforward than the spookiness of rigid reverting and re-executing with a rule disabled, and fits nicely with mental models of cancel/checkpoint/restart.
Name possibilities: {backup,save,try,remember}/{restore,load,undo,revert}