What if Scripting was like using Lego Bricks?

What do people think of making a level of scripting ability that would be easier for more people to get a handle on? (aka Lego Bricks of Script )

I used to use a authoring tool called mTropolis. Fab tool (killed by Quark) that allowed you to drag n drop behaviours onto objects so you could get a huge amount of programming/scripting done without having to dive down into code writing. OSX Tiger has new Automator that is the same concept and there are a handful of other tools that use this metaphor.

Basically...
1. You have a task that you wish to script.
2. You mentally break it down into steps/behaviours/classes.
3. Then you rummage through a big bucket of "SL Script Legos" and look for bricks that resemble the steps that you have in mind.
4. Snap 'em together in a stack and TaDaa! You have your finished script/program.


I have already posted this as a proposition on the Vote forum but I would aslo like to hear if others think this would be a good thing.

I believe scripting as it is will be one of the factors that make the SL economy putter along sporadically because it really limits the creative ability of those who are good with graphics/textures/3D.. which is a Right brain activity while writing scripts and code is a Left brain acitivity. These Lego bricks would go a long way to making it easier for "creative types" to do some decent scripting... leaving really complex scripting to those who are "more logical" and inclined to attack the learning curve of raw scripting/programming.


-------
Vote for Prop 312
Scripting like Lego Bricks

http://secondlife.com/vote/index.php?get_id=312

Honestly, this sounds more like a coding style to me than it does an iron-clad feature. You can fairly easily code in this manner if you know what you're doing - "requiring it" is not exactly a good idea.

Furthermore, it's been mentioned that LL wants to open the coding doors to other languages in the future. This allows further development of tools like this without dealing with LSL itself - nice tools like the python interpreter.

Move along.

These are always great ideas.

Unfortunately, I often have a nagging suspicion that LL is reserving the right to own the development tool world and is purposely making it hard for us to contribute anything in this space.

There is nothing stopping you from creating an editor, or addapting an editor to work how you want, and then have it dump out LSL. A while back we built ESL, which is just LSL passed through a C precompiler. Course you have still have to copy and paste the code into SL.

Yeah, but if SL doesn't give up the keys to that they will always be able to build a better development tool.

One of the problems with creating things for SL is that you don't know what they're going to just come along and co-opt.

So you have to stay small and penty-anty because it's improbable they won't tackle those issues.

speaking of lego bricks, have you seen the programming method used in the lego mindstorm computerised sets? now that makes programming childs play for anyone. quite literally.

(first example I could find. you get the idea)

And anyone remember hypercard? That's what we need in SL!

This type of programming model (using building blocks) is a form of Object Oriented Programming. Not OOP in the common sense, but as in literal Objects - building blocks assembled in a 3D modelling environment. There's a few of those 3D modelling languages around, but last I heard they were still mostly being used in a research/experimental stage.

I'd love to see one actually reach maturity though.


- Newfie

You might check out these docs on Quartz Composer. It's one of the new developer tools from Apple for creating graphical "compositions".

I think a tool like this would be pretty good, there's no reason people should have to go mucking about with LSL just to make a door open, or windows turn shaded, or lights come on and off. It could range the gamut from a Mindstorms/Automator style "do this, then this, then this" all the way up to something like Quartz Composer or the promised (but never really materialized) usage of Java Beans.

I love this idea as a way not only of enabling non-scripters to build, but also making scripts more efficient, thus creating less lag!

Me! I remember!

Heck, it's not as dead as you might think. Probably it would be fairly easy to create an LSL generation tool in Runtime Revolution/Dreamcard.

neko

Umm.. typical code monkey to miss the point. The point is this would be scripting for people who don't know what they are doing and don't want to learn a scripting language.





Move along?

Well actually I was thinking of OOP but I forgot the stupid acronym. The several examples of which I could quote do not use actual 3D objects. They are just little icons or pictograms that, with colour coding, help you identify what the blocks do. Fully 3D would be overkill.

Been thinking a bit more. I think you could make a dialog-driven script-maker that would do a chunk of this, if we had the ability to #include existing scripts. (You could do it anyway, but it would require dropping a huge script into everything, and would be limited by the script size limit.) This would let people select from among existing behaviors, with simple configuration commands that the dialog would help with as needed, which would then tie in pre-existing script components.

Conveniently, the ability to #include scripts is available for vote: prop 101.

neko

You get the idea!

Simple! ...and more or less Efficient to use. No idea if it would do anything for exectuion improvements and that kind of spped efficiency.

Again... would be suitable for 90% of simple things a user might want to do like indeed... opening a door or causing a simple sound to be triggered. Something that might be 4 or 5 "SL lego Bricks" in size.

More complex things... would be doable with the Lego Brick tools but as you got bigger and more complicated.. they might be faster or more elegant if you code them the raw script way.

Again, to my experiences with tools that use this metaphor, you can do pretty decent stuff so long as it is "little steps" and/or well thought out compilations (i.e. Want to preload these 5 sound elements before I do anythiing else or my little creation will hic-up and die).

When the going got tough.. I might do a prototype with my OOP tool but then passed it off to a pro to code it from scratch in appropriate language for improved speed/stability etc.

No..nothing except.. time, effort, and ability to write code.

Oh yah.. and the fact that this would be a benefit for SL and Linden Labs if this was a built in aspect of the tools and of little benefit to a developer unless he/she could get SL'rs to buy the thing it quantitiy in actual dollars... for the effort. Somehoe I doubt the effort, although not daunting, would be a breaqk even activity for someone outside of LL.

Again, your suggestion appeals to a small % of real people and SL people in terms of skills availalbe to write software and to.. I would guess.. more than 50% of SL'rs you post is so much gobbly-gook greek.

I am appealing on behalf of the masses who do not want to learn a scripting language. I mean.. I am muddling through PHP for web sites and that is already more than I really want to do. I am a designer kind of guy more right brain than left.

I like using tools.. not building them!

And this is where you ask a scripter to make this for you. There's no reason this can't be done already with LSL - scripter makes series of scripts doing what you want; others use them by drag-and-dropping them into the object of choice. Done!

I thought that was clear. "Move along" is pure sarcasm, but if it upset you, I apologize.

If you'd like this done, I suggest you take this over to Scripting Tips and list the behaviors you want.

Oh. And it might be wise to be polite to this "typical code monkey" there.

Includes would be nice, but I don't think we're going to see that until Lindens hammer out "static" storage. It'll be interesting to see what happens with that.

As for a dialog-driven scriptmaker, that's not a bad idea. Basic functionality along these lines would be easy to accomplish using link messages or script names to execute each script with what you want to do. Very interesting...

And again, something to be asking in Tips or coders directly to design. Don't be shy - just think up a few behaviors you'd want.

I loved hypercard! I once wrote an inventory control program for a small business with hypercard. They actually used that program for more than 5 years! What a blast from the past.

The advantage to Hypercard was it's easy learning curve and very logical set of rules. My right side brain was in heaven writing small programs with it!

So you dont want to do any work, but still reap the benefits?

Why is that the only option? I started the thread thinking LL could include this as part of basic tools in future version for everyone. Off hand i didn't think users would make this tool.

I could help in some ways but no, ...I don't want to learn SL scripting.... but yes, if a user built this and it worked and was decent I'd pay $L or $R or both if i had too... but would rather it was availalbe to all.

Correct me if I'm wrong, but I'm still not seeing why LL needs to do this when a resident can make this sort of script for you.

Again, forward a list of what you'd like to see to Scripting Tips so we can take a shot at it. Idle debate really won't go anywhere.

The basic rule of efficient feature requests: if users can create the desired functionality, find a user who's willing to do it, rather than distracting LL from the critical tasks, like fixing the asset server/login database.

This is one users can make. For an example of what can be done, see Crystalshard Foo's outstanding video controller, Freeview.

I think the relevant question at this point (regardless of who would implement the functionality) is, what functionality should be in the simple script package?

neko

The starter of this thread just spent the last five minutes flaming the living crap out of me over my posts to this thread. I'm not going to post a chatlog, nor even slips of conversation, other than to say that much and leave it at that.

So they say, the road to hell is paved with good intentions.

At any rate, I am going to request any further comments to this thread be moved to another conversation. It is clear to me that this poster is not after solving the problem, and has taken to a personal vendetta against scripters in general.

It seriously pains me to see that opinion so widespread here, but such is not the point of this forum. I'm just adding this here because it happened, it's relevant, and I seriously will not stand for that kind of treatment without it being known to further posters here.

Thanks.

I've seen such simple graphically-based programming environments before... And they are not that great.

For example, the Mindstorms programming stuff is very limited. Extremely basic programs look nice in it, but anything more complex becomes extremely tedious. Besides, if you're going to be doing any serious programming, learning to script is a must. I can't even imagine how horrible a vehicle script would be in this language.

Someone mentioned efficiency in this sort of thing. Really, it would be less efficient, because the closer a program is to machine code, the faster it runs. Such a high level of programming is extremely inefficient.

We are not attempting to make a programming language that is understandable for ten year olds, as Mindstorms did, but rather we are attempting to build one advanced enough to accomplish very complex tasks.

Besides, the Lindens would have to do a very large chunk of programming, which would include a new compiler and some new graphical functions for such types of programming.

If the serious scripters have anything to do with it, this won't happen.