How do I plan a scripting job?

I've been wanting to take a class in script planning but haven't got there yet.
When you need to do something with an end result, how do you plan it? Jumping in and getting something to work then adding another bit and another, leaves the project in bits and pieces, and for me, usually out of order and broken.
What is a decent process to go through? I've read that a flowchart can be used, are there examples for this anywhere?

Maybe some tips from the experts would help to get a script job in order before commencing. Or am I barking up the wrong tree?
Please help.

Hi,

In real-life I work in an environment where a client might spend a couple million dollars for us to just "plan" development activities, creating reference prototypes, promulgating various architectural and technical design standards, etc. That's *before* any "real" development happens!

But for scripting, the best thing IS to jump right in and "just do it"!!

Don't over-think it. Have a "idea" of what to do in your head (or on a napkin) and go at it.

If you get stuck just come and ask here... I'm sure one of us will help out with any problems you might encounter.

It's ok to come back and "re-do" different pieces. Heck in our field that's called "iterative development" and we charge our clients an arm & a leg for it.

-peekay

divide and conquer

Depending on how large and/or complex a project is I'll use a flow chart:

For almost all of my AI experiments, I'll set up the logic gates as a flow chart (if-then statements) so that I can see where potential problems may happen with recursive loops, etc.

I'll also use flow charts for less complex, but large projects, such as a several thousand texture viewer (multiple textures visible at once) I was commissioned on. while the over-all coding was simple enough, laying out the buttons and how they knew when to move to which index took a lot more visualization of the process than actual coding. Unfortunately, all my flow-charts are on paper and I do not have a way to show you an example.


For smaller projects, I'll just dive right in and do them bit by bit; usually starting off with whatever math code I need to write, then going to anything dealing with physics to get a prototype, followed by events to get info from the world, adding in what ever kind of interface is needed to adjust/debug the item, and finally adding in any visual effects.

As other folk have said: divide and conquer. LSL is well structured for this.

In terms of large scale planning, flowcharts help, but pseudocode is also great --- it helps you organise your ideas and plans into something approaching a programming order (and you can write it when not logged into SL).

Divide and Conquer is it.
Stub your code, write out the process that you think you need and translate them to event handlers. Next take each state and decide what it needs to do and stub the methods again...

Eventually you end up with lines of LSL that dont need to be 'functionised'.

For a beginner, step-wise refinement might be good. You have a grand vision for what you want your final script to do, but it seems to big. So, instead, think of a much smaller, simpler version of the same thing, and do that first. The start gradually adding features.

Suppose yo want to create a full-featured jet fighter script. Maybe you should just start with a script that waits for you to sit on it, and then moves to another spot. Once that works, you add some arrow key control so that you can point it the direction you want it to go. Then, maybe you add a sound so that it goes vroomvroom.

At some point, plan to throw it all away and start over, because you will by now have figured out a better way to do it, and it will be easy.