Disable sprites moving offscreen

I don't see any way to do this already, so:

It should be possible to make sprites unable to move offscreen without a script that detects the edge and all that. Kind of like the rotation style options, but with offscreen.

The way I look at this is that Scratch is like a bike with stabilisers - its designed so you can't easily fall off :slight_smile:

They got taken off in Snap! :slight_smile:

But it would make a nice project to add a programmable version

Yes. There should be three modes, actually: WINDOW that lets the sprite move around an infinite space and shows it when it's in bounds; FENCE that doesn't let it start a move that would make it bump into the edge of the stage; and WRAP that makes the stage a virtual torus, so a sprite the goes off the right edge comes back at the left edge, still moving, and ditto top and bottom.

Those LOGO settings "fence" and "wrap" only make sense for LOGO turtles that are basically pens, not for sprites. What would they even mean exactly? One programmer wants the sprite to stop as soon as a pixels hits the edge for "fence", another might want it to be able to go a little more offstage. Likewise for "wrap": Do you really want a sprite to be able to be in up to 4 corner of the stage at the same time, and be able to "touch" up to 4 edges at the same time? Maybe some user wants that and another wants it to "wrap" in total as soon as one pixels hits the edge, whereas another... you get the idea. I doubt those "solutions" that open more questions and turn one feature request into a legion of new feature requests and scrollable dropdown menus with a plethora of settings. That's not how I like to design a construction kit for learners but a framework for already-nerds. Not my cup of tea.

Of course you should be able to write those things yourself. Snap! gives you all the information you need - which Scratch doesn't, btw - especially the dimensions of the stage and of the sprite's bounding boxes at every scale. Now you go ahead and build that in Snap! That's what an educational programming environment is for: It lets you build those things that you wish for. Geez.

Logo turtles aren't zero-extent pens. All these issues about when and how to wrap have come up before and been solved. And yes, if a sprite heads directly for a corner in wrap mode there might be a brief time in which it's in all corners when wrapping.

And "a framework for already-nerds" is gratuitously insulting to the developers of Logo, who based their work on quite a lot of working with actual kids. The main use of wrap mode was in fact writing game programs, to solve the same problem that Scratch kids solve with really complicated techniques to scroll the background. With wrap mode you don't have to worry about any of that; the sprite is always on the background, not lost in space. Wrap makes that kind of game really easy to write.

Many of your hypothetical problems come from a hypothetical user choosing a mode that doesn't really fit the kind of program that user is trying to write. If you're building squirals or something, you want window mode. If you're simulating a pinball machine, you want fence mode. Thinking about the actual use cases for these modes answers all your questions about edge cases.

As for writing them yourself: As always, the tradeoff is between letting younger users have the tools they need to make it easy to write the kinds of programs they write and letting older users implement them. It's exactly like the case of higher order functions: We want raw beginners to be able to use those tools, so we provide them.

Oops! I think we have a repetitive issue... something like using a "feature request" block recursively.
And it may not help much to have so many spontaneous considerations of new feature requests. I would rather interpret them as "ideas", not as a request that must always be attended and justified. Because design changes are global and complex issues... with many details and reflections that we can not be doing continuously.

And it is not only a capacity issue (not enough time). They (these discussions) cause to reinforce this trend and move away from what would be desired: enjoy what Snap! is offering right now and the strong ideas it gives us.

Returning to this topic... A feature "idea" about a window-fence-wrap stage mode is written down. It's ok... as idea. At some quieter time (if those moments exist) there will be a design time to consider the ideas collected and consider them with a global view.

And I only write down, that yes, there is a problem because we have not only turtles... and so, it is not only a topic about the movement (to allow it or not). We can change costumes, size, apply graphic effects... and other details like anchored sprites, inheritance properties... current behaviors like "if on edge, bounce" (that has relation with fence mode... but it does allow "final" movements)...

And please, I insist that I'm only writing down details to help if at any time someone wants to consider this topic ...


Joan, I love you, but if we went by that approach we'd still have BYOB3.

Scratch is a wonderful thing, but one thing that we old people all hate about it is the ways in which it moved backward from Logo. The inability to define procedures was the most important example, of course, but second place was reverting to flat text strings instead of Logo's words and sentences. So I wrote a library, way back in BYOB, to get back some of that, but it's not perfect because lists don't look like sentences in Snap!, which is part of a general inability to set the printed representation of an abstract data type.

But, surprisingly, third place goes to the disrespect of turtle graphics. So that's why the "feature ideas" that are the result of five decades of work with kids in Logo matter to me.

Modes are the worst possible user interface design. These are fun, easy, and entirely doable exercises for those who've progressed far enough to feel a need for these features. Instead of lamenting about missing "features", which I feel are sometimes just a call for attention. I'm 100% sure @mrfluffypenguins will be able to write these two scripts themselves:



An example project: https://snap.berkeley.edu/project?user=jens&project=Fence%20And%20Wrap

No rocket science involved. No higher order functions were harmed either :slight_smile:

Jens, you seem very, very insistent on insulting the work of people who were working with actual children around the time you were being born and who continue to work with children today. Those people are not on our forum and are not "calling for attention" as you put it. (Well, except for me, but in the early days I was just an occasional bystander, so it's not me you're insulting.) They just invented the idea of programming for children, and they looked at the kinds of programs kids wanted to write, and provided an environment to support them. Just like you, except for the arrogance.

Sure, an advanced secondary school student could write your two blocks. But unfortunately, those blocks don't help at all, because they don't change the behavior of MOVE n STEPS. And sure, an even more advanced student could write the JSFunction wrapper to replace the native MOVE with one that supported three modes for screen-edge behavior. But, you know, the same is true of MOVE! A sufficiently advanced student could write MOVE and TURN in terms of GO TO X:Y: and trig functions. So, let's just declare anyone who wants to use MOVE an obnoxious attention-seeker, shall we?

You're really being an asshole about this.

It's not "those who've progressed far enough" who need WRAP. It's eight-year-olds who want to write a platformer game quickly.

Brian, this topic is a feature request from @mrfluffypenguins , not a suggestion by you. I've pointed out that this can easily solved within Snap, because - unlike Scratch! - we provide all the geometric information needed, so writing the actual script, e.g. for WRAP is trivial.

I don't know how old the creator of this features request is, but I bet it's not a teacher and I also have a hunch he wasn't around when I was born.

It's true, I get angry about this, because the whole old LOGO gang keeps saying - in public - that missing WRAP is the one thing that "killed" (literally quoting Gary on this) LOGO. An no, no, no! This is not about JS functions or overloading MOVE. Gawd, no!!!

It's as easy, as simple, as trivial as this:

always wrap

this will take care of all the MOVE issues. We have these features in Snap! is what I'm saying, and it's fun to solve whatever you wish for with them. That's the purpose of a construction kit.

Yes, it does make me angry when the old LOGO community declares things such as WRAP to be pivotal, and don't see a bigger picture in a new design. LOGO is a beacon for Snap!, but it's not the bible.

I made one that makes the edges correctly visible. It is https://snap.berkeley.edu/snap/snap.html#present:Username=spaceelephant&ProjectName=wrap&editMode. Is this something that would be useful in a library, even if not in main snap?

Yes, although we have to invent saving sprites with global custom blocks, right Jens? I'd still be happier if it didn't have to have that script, copied into every sprite, though. And also if you drag a clone, that script errors. So yeah, it needs some refinement I think, but I love playing with it!

Actually @jens instead of putting the library in a script in a sprite, how about if we could
wrap script pic
(omitting the actual code for brevity). Would you hate programmatic creation of variables if it worked this way, with upvars?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.