my first activity
Ties Stuij
I just made my first Etoys activity and it was a cool experience.
Download it from http://stuij.se/etoys/MoneyBrother.008.pr
I just forwarded the domain to another server, so it might not
resolve. But then again, the change was in effect immediately, so i
think my hosting provider is playing tricks.
notes on the activity:
- It's all etoys-coded, like Luke suggested. Epaati is needed though,
but only for the correct/incorrect girls voice.
- level layout:
- three rounds
- A right choice is rewarded with a point extra, a wrong choice
results in one point subtraction. One can't go below zero on whichever
level.
- first round a child is trained on four random notes. per turn it
is presented with an animal and should choose between three of that
four. after ten points she/he elevates to the second.
- the second round the child is trained on the 5 leftover notes.
after 15 points she/he goes to round three
- in round three the child is trained on all nine notes. Round
three goes on indefinetly cause i don't really know what our policy
is. See the question below.
- the blue text there says 'globals'. It's just a holder for global
variables, cause the world variables got to be so many, that they
threatened to walk offscreen.
- it's not optimized for speed yet. That is, all object always try to
go to their targets all the time. Their 'move towards' script should
really be turned off. But a) I'll do that later, b) I think it's more
elegant this way, c) I'll loose that jolly
the-right-note-hops-a-bit-in-the-air-wiggle, d) there's a question
attached to the inefficiency. See below, in the questions section.
- I'm no graphic designer and I don't have access yet to the epaati
repository so i didn't waste time on graphics.
I wonder if people could give me a response to the following questions:
- how well is this activity running on a real XO? As I said above, the
activity needs to be speed-optimized a bit, but it seems to me that
it's not doing incredibly taxing things. Is it just my mac setup or is
etoys kinda processor hungry?
- modularization seems impossible in plain etoys, down from the
projects level. Is this so?
- what's the proper way to hide stuff you want to put offscreen? just
drag them offscreen?
- the 'move towards' another player with the 'moving component' will
only bring you to the borders of your target. this mean it will stop
at different points relative to the target depending on the direction
it's coming from. I can see how this property can be useful with
collision detection, but for a lot of other uses, where you want to
position your object absolute-relative, if you get my drift, it's a
pain in the neck. Is there something I overlooked?
- and of course I'd like to hear general critique on the activity.
- I guess this activity needs pretty graphics, but I'm not the man for
that. How do we go about this?
- what now?
Some observations. Might be helpful for future new etoysers. If I'm
wrong about them, please tell me.
- there's no and grouping or not logic. This ticks me off.
- can't set a variable of a variable
- etoys doesn't do smooth motion
- set scripts to mouse down, can't do it programmatically/have to set
it for every instance
- comments are impossible, without being hackerish. Unfortunately
going to text mode in a script, and leaving a comment didn't work.
- write a recursive function which doesn't terminate and you're
fucked. If it would only blow the stack or something.
- if variable is a player, and you change it in a script, the viewer
which shows the variable isn't always updated.
- one CAN in fact specify the script of an arbitrary player variable.
Was a surprise to me. Just make a script with a direct Player, take a
variable icon, and hover it over the player-name tile.
- you can set the speed of a 'move towards', by manually adding a
variable to the relevant player which you should call 'speed'. I guess
this works also with other relevant motion scripts, but I didn't come
that far. I was just lucky a google-query returned the right answer,
cause this is in my opinion quite hackerish. Usually programmers are
not psychic you see.
- etoys seems a bit buggy. Like they wanted to simulate the real world
or something. Some examples:
- sometimes a player gets out of whack. That means you're
basically fucked, if you assigned it a lot of logic.
- the viewing glitch mentioned above
- a few things i forgot
- never thought i'd try to keep my functions small because i was
running out of screen real-estate
- the 'world' player misses a number of script categories, scripting
for example, that is standard on (some) of the others. Why the
artificial distinction? It's kind of annoying to open another player,
just to pull out for example the test module.
- etoys script arguments can't be altered from within the script like
you can with player variables, which reduces their use quite a bit I
feel, and it forces me to juggle with global vars.
- I hope not that etoys was secretly designed with the goal of letting
childred around the world suffer from RSI before they are 12. I'm
gonna delve up my tracker ball. On the plus side I can now eat popcorn
with one hand while developing with the other.
/Ties
Luke Gorrie
Greetings from Kathmandu :-) I'm stopping in to drop off the office
unicycle (beginner size) before shooting on to the C5 conference in
france for a bit.
> I just made my first Etoys activity and it was a cool experience.
Really well done!
We haven't seen anyone reach this level of Etoys proficiency through
self-study before. How did you do it -- what resources were most
useful?
I have played with the activity a little bit before my MacBook died
some couple of hours ago. I'll try to give feedback based on that
taste:
> notes on the activity:
> - It's all etoys-coded, like Luke suggested.
And the 'All Scripts' morph shows that it's impressively little code too :-)
> Epaati is needed though, but only for the correct/incorrect girls voice.
Sounds that you use are normally saved with the project.
> I wonder if people could give me a response to the following questions:
> - how well is this activity running on a real XO?
(Answer to follow)
> - modularization seems impossible in plain etoys, down from the
> projects level. Is this so?
Short answer seems to be yes, but it depends what you mean a bit. You
can copy objects from one project to another (scripts and all) via
e.g. a shared flap, but of course then you end up with two 'forks' of
that object for the future.
> - what's the proper way to hide stuff you want to put offscreen? just
> drag them offscreen?
I either put them in a flap or use 'hide' from the 'miscellaneous'
viewer category.
> - the 'move towards' another player with the 'moving component' will
> only bring you to the borders of your target. this mean it will stop
> at different points relative to the target depending on the direction
> it's coming from. I can see how this property can be useful with
> collision detection, but for a lot of other uses, where you want to
> position your object absolute-relative, if you get my drift, it's a
> pain in the neck. Is there something I overlooked?
> - and of course I'd like to hear general critique on the activity.
> - I guess this activity needs pretty graphics, but I'm not the man for
> that. How do we go about this?
> - what now?
[No answers from me right now]
> Some observations. Might be helpful for future new etoysers. If I'm
> wrong about them, please tell me.
> - there's no and grouping or not logic. This ticks me off.
Agree.
> - can't set a variable of a variable
You found the trick for this and mentioned it in another mail, right?
i.e. to first change a variable of a constant, and then drop a
(player) variable over the constant.
In fact this could probably collapse a lot of the logic in this
example project -- I can't remember the details before my computer
crashed, but I recall a series of test blocks checking if a variable
was 1, 2, 3, 4 -- but the variable could probably be switched to a
player instead of an integer and use indirection instead of tests.
> - etoys doesn't do smooth motion
You could probably be forgiven for doing this at Smalltalk level with
a textual script.
> - set scripts to mouse down, can't do it programmatically/have to set
> it for every instance
I failed a Trac bug that changing status of a script doesn't propagate
to siblings, not sure of the status (you can search OLPC trac for
'lukego' to see)
> - comments are impossible, without being hackerish. Unfortunately
> going to text mode in a script, and leaving a comment didn't work.
This is annoying. I've filed a trac bug about the lack of nice support
for textual scripts and I hope it will improve. Yoshiki was optimistic
about getting local variables preserved but I don't know about exact
sources. I can imagine tricks like self comment: "'This is a comment'"
if it really came to it.
I urge you to file bug reports on OLPC's bugtracker for all the bad
behaviour that you find. They are motoring through and fixing lots of
stuff (great progress in fact) and they're very helpful/sympathetic to
us.
Cheers!
-Luke
Ties Stuij
> self-study before. How did you do it -- what resources were most
> useful?
I watched all the waveplace videos you recommended on this list (
http://www.waveplace.com/movies/ ). They give a nice overall view of
the development process. That's it really. And then that google search
to find the speed settings of the 'move towards' thing.
> Sounds that you use are normally saved with the project.
Yes after i wrote this I thought that might be the case.
> > I wonder if people could give me a response to the following questions:
> > - how well is this activity running on a real XO?
>
> (Answer to follow)
Well I should get my G1G1 XO today with a bit of luck, so I can
probably test it myself. If I can figure out how to open the damn
thing of course.
> > - modularization seems impossible in plain etoys, down from the
> > projects level. Is this so?
>
> Short answer seems to be yes, but it depends what you mean a bit. You
> can copy objects from one project to another (scripts and all) via
> e.g. a shared flap, but of course then you end up with two 'forks' of
> that object for the future.
To me it feels we should just code reusable stuff in Smalltalk then.
To me the benifits of having reusable code for developers outweighs
the possibility for children to explore the code of the projects. But
I guess you guys have talked already quite a bit about this. It would
be interesting to hear
> > - can't set a variable of a variable
>
> You found the trick for this and mentioned it in another mail, right?
> i.e. to first change a variable of a constant, and then drop a
> (player) variable over the constant.
Ehh.. yes in this one even i think :o) I was making these notes while
hacking. Sorry for the noise.
> I urge you to file bug reports on OLPC's bugtracker for all the bad
> behaviour that you find. They are motoring through and fixing lots of
> stuff (great progress in fact) and they're very helpful/sympathetic to
> us.
Ah, ok. I'll do that. It's just that etoys isn't as cleanly designed
as I'd wish. With the cases i mentioned I wasn't sure if behaviour is
a bug or just against my wishes. But yes, I should widen the group a
bit I guess, and I should also be less lazy :o)
/ Ties
Bryan Berry
I am embarrassed to say that I knew almost none of the animals. You have
advanced quickly young Jedi
--
Bryan W. Berry
External Relations Manager
OLE Nepal, http://www.olenepal.org