This is a read-only archive of the old Scratch 1.x Forums.
Try searching the current Scratch discussion forums.

#1 2007-04-10 21:26:59

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Two very very important "features"

There are two important features missing that I think are crucial to any language:
1. Comments. You really should be encouraging people to add inline comments. A comment block you can drop anywhere with an area to type text is all that is needed.
2. A proper while loop. The "forever if" is an oddity unlike anything I have seen. It is a thread rather than a sequence in that it does not ever end. A repeat equivalent which tests would be the ideal.

There are also two other important problems:
1. Broadcast-wait does not work if the same sprite! I want to use broadcast as a function call equivalent, so the same sprite can have a receive function which completes and then allows the "caller" to go on. This does not work.
2. The single step is awful. You need to allow a mouse click step (button or whatever). I know you can decompose scripts to make them work in parts, but this is very clumsy. When things go wrong, the step is just too fast to see what is happening and diagnose problems.

Otherwise, it is a great teaching language for kids. Regards, Paul

Offline

 

#2 2007-04-11 16:23:43

andresmh
Scratch Team at MIT
Registered: 2007-03-05
Posts: 1000+

Re: Two very very important "features"

Very good points! Thanks a lot for your feedback.


Andres Monroy-Hernandez | Scratch Team at the MIT Media Lab
on identi.ca and  twitter

Offline

 

#3 2007-04-11 17:51:58

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Re: Two very very important "features"

By the way,  I think this a great teaching language. If you need any help, let me know (I am a very experienced programmer). I will note that I think it would be worth de-emphasizing threading (multiple scripts per sprite) because (a) you do not provide mx protection and so they have no variable or state protection, (b) they would not generally get to use this in any other language, (c) they will develop some bad habits, (d) related to a, they will end up with very hard to debug problems related to timing issues. The RTOS like threading of one main-script per sprite is reasonable given that you have thread-local variables, but I suspect few understand the implications of global variables. I am a bit concerned about how to get people to move from this threading model to action loops or interrupt driven. I am personally planning on moving the kids I am teaching from forever loops to broadcast-wait/receive models, such that the broadcast is from one central point (the main() would be the stage). This would then allow for a set of standard "functions"/"methods" per sprite, such as Update(), Init(), Term(), and so on (these would be receive "hats"). The only issue I see is that it would be preferred to narrowcast (one msg per sprite) rather than broadcast (one msg for all sprites that listen). But, the object oriented nature of the broadcast commonality (common underlying method) is a worthwhile concept. Have you given any thoughts to this?

Offline

 

#4 2007-04-11 17:59:07

Cholo71796
Scratcher
Registered: 2007-04-07
Posts: 9

Re: Two very very important "features"

Hey Pkimelma, would you bother trying out the start of my game, and either
1) Implement a save engine
2) Describe how I can
Oh, also, you can suggest things about the game itself: http://scratch.mit.edu/projects/Cholo71796/1336
Please help! TIA.

Offline

 

#5 2007-04-11 18:26:44

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Re: Two very very important "features"

Hi Cholo, I tried to look at it, but it hung my browser - kind of odd. Anyway, I do not think you can have a true save or load, as there is no file type. Scratch is the ultimate sandbox. The closest you can have is using variables. You can name some save variables that hold your state and then copy them on load and save. This works as long as the player saves the project after playing it (so the variable's new state is saved). Since no arrays, you cannot make this very flexible, but could have two save/load sets for example (using if/else).
Since I cannot see your game at present, I cannot comment on it. I know that for the kind of thing you are doing, game physics becomes important. Whether you want to simulate some real physics or only pool-table physics (reflection angles) be aware that you have some issues with Scratch in terms of lacking normalized boundary vectors (you cannot tell much about the thing you hit for example). I have had the students move away from using "direction" and move to pure vectors (xdelta and ydelta) which encodes angle and velocity. Since x/y can be fractional, you do not need a collected error function. This then makes it easy to add any game physics without cosin/sin or square root (since no arrays, you cannot even have tables). We use one color for vertical edges and another for horizontal. This makes it easy to handle bounces and edge treatment. The x/y model also makes it easy to detect in path of, force of collision, and the like. This all helps if moving on to a text language (whether a step such as Phrogram/KPL or scripting or compiled language).
I will try to look at your app later on. Regards, Paul

Offline

 

#6 2007-04-11 18:35:33

Cholo71796
Scratcher
Registered: 2007-04-07
Posts: 9

Re: Two very very important "features"

Ah, I see, this crossed my mind briefly in school, but it drifted away. Thanks. Try again later, but it seems that scratch is lacking the 'Get' command, in something like this.
When Load Clicked
Get Value of Variable Wood
Get Value of Variable Iron
Get Value of Variable Gold
Get Value of Variable Level
Get Value of Variable Armor

When Save Clicked
Find (and use) Value of Variable Wood
Find (and use) Value of Variable Iron
Find (and use) Value of Variable Gold
Find (and use) Value of Variable Level
Find (and use) Value of Variable Armor

Maybe it will be implemented in next version?  Hopefully, if not earlier.

Last edited by Cholo71796 (2007-04-11 18:35:56)

Offline

 

#7 2007-04-11 18:49:02

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Re: Two very very important "features"

I am not sure why you need "get". If these are global variables (not local to a sprite), then you can just copy them. So, save would be "set save_wood = wood" and load would be "set wood = save_wood". If wood is local to a sprite, then you can send a message to the sprite to save or load its variable to or from a global one. So, the sprite would have a mini-script "when I receive 'load'" and "set wood=save_wood" and so on. Of course, you need one save variable per variable you need to save or load. The equivalent save mini-script would be used. This is more like normal models where you push the save/load to the objects (although usually passing buffers with a length).

Offline

 

#8 2007-04-28 06:02:46

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Two very very important "features"

I agree with the need for comments.  There need to be
   comment blocks in code
   comments attached to every variable
   comments attached to every message

broadcast-and-wait does work in same sprite (at least, it seems to for me)

Offline

 

#9 2007-04-28 12:00:25

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Re: Two very very important "features"

You are saying you see it waiting? That is, you set a subroutine which listens for a receive message. Then you use broadcast-wait to "call" it. You are seeing the caller waiting for the routine to finish? I am not. When I do this between Sprites, I see it wait as expected. I can retry with the update version in case that was fixed in that version.

Offline

 

#10 2007-04-30 12:37:08

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Two very very important "features"

I made a quick test program

Offline

 

#11 2007-04-30 12:39:50

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Two very very important "features"

I made a quick test program,

When flag clicked
   change color effect by 25
   broadcast wait10 and wait
   repeat 10
      next costume
      wait 0.2 sec


when I receive wait10
   wait 10 sec


This did exactly what expected: changed color, waited 10 seconds, and started walking.
Can you make a short sample program that shows the broadcast-and-wait not waiting?

Offline

 

#12 2007-04-30 13:00:57

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Re: Two very very important "features"

OK, upon looking at it more closely, it looks like most things work correct in that case. But, I was having troubles with some things. On the other hand, it looks like the problem may have been mostly that "forever if" is just a strange construct. I am not sure what it is supposed to be modeled on, but it is not like a normal language construct. I took it to be a while loop, that is "loop forever, as long as some condition is true". But, it instead is "loop forever, and if some condition is true, execute the code inside". In other words a shorthand for:
  forever
    if <>
      stuff inside
I think that was a poor choice since it does not seem to add to anything and this collapsing of two fundamental operators into one is not helpful to language expression (there is no "forever if else" for example)., and is certainly confusing to me and to the kids. So, once I got rid of this, the broadcast and wait seem to be OK. The reason I am not sure is that I have seen some race conditions when the receive block has no wait delays in it. So:
  ...
  forever
    set xyz = 0
    broadcast test and wait
    if xyz == 1
     do something

and:
  receive test
    set xyz=1

The something should always happen, but I was not seeing this except when using  single stepping.

Regards, Paul

Offline

 

#13 2007-04-30 17:03:30

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Two very very important "features"

Race conditions are certainly a problem in scratch, and your example is an excellent one.
The broadcast and wait should do the right thing---if it isn't, then you have found a bug.

forever..if is a wierd construct, but is slightly more powerful than the when<condition> block it replaced.  I agree that it doesn't add much to the language.  The correct replacement for it is not
   forever
       if <cond>
          code

but
  forever
     wait <cond>
        code

Offline

 

#14 2007-04-30 17:15:46

pkimelma
Scratcher
Registered: 2007-04-10
Posts: 33

Re: Two very very important "features"

Actually,
  forever
     wait until <cond>
        code

Since wait is timed and wait until is a condition test. AFAIK, there is no difference between the wait until and if except for performance. That is, the if would be executed over and over (polled) where the wait is a kind of event primitive. But, the user could not tell the difference other than perhaps load on the CPU.

Last edited by pkimelma (2007-04-30 17:16:11)

Offline

 

#15 2007-04-30 18:17:48

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: Two very very important "features"

I agree---The difference between busy waiting and daemons is not a semantic difference, but a performance one.  I don't even know for sure that forever-if *is* implemented with daemons, just that it *should* be.

Offline

 

Board footer