While reading “Foundation Flash Game Design” recently, I came across a tip that has helped me tremendously and I wish I had known about it before (at the technical college I went to, they don’t teach this stuff, hell, they didn’t really teach you algorithms, either). Some of you may know it, some may think of it differently, some may say it’s a waste of time - one way to think of coding is to see it as being in separate “stages” or “statuses” or states as coding goes along.
And yes, I realize that using the Flash debugger is probably the same as my explanation, but…I’ll expand a bit…
At different intervals in the programming/coding cycle, you will want the program to react to different kinds of statuses. So, ask yourself - what is my program doing at line xx or at this particular point and is it going to need a specific status or does it have a current state/status at this time?
You have the option of displaying the state/status of your program, you have the option of looking at it and going - “Where is my program taking me? What would be the current status of my program?” (Like the playhead moving in an MP3 player program.)
In a number guessing game, or a word guessing game, a state/status could be “3 guesses remaining; DISPLAYING 3 guesses; WAITING on user input”.
You can also include optional states/statuses such as “User has made 8 guesses since function x was first called.” If you don’t know the above information (and if you’ve ever asked yourself - “Well, I want the status here to be X (or number of guesses remaining)”), you’ll come to a point in your status where you will need more info. And to get more info, you need to initialize a variable or two. Usually, when I’m thinking in terms of “Well, I am at Part A of the input stage (out of many different parts, or steps) and I need to know the status of X before I can accept input and manipulate any data.”
You can also set the status of your program. Ask yourself - “What status or change of state can I “force” the program to do?” Sometimes, one status depends on a change of state or status from another area of code. So, you have status A and status B. Let’s say that status B is a text field awaiting user input. But state B’s text field is grayed out or out of focus. Status B is depending on a variable change (or simply just the change of state) from state/status A. And we can call status A the “parent state” that directly influences child states (ok, now I’m really on my high horse about this but just go with it for now).
And even a child state can be the parent of a state C (if there is one and if state C depends on a status change from status B.) Keep your eyes peeled and really watch and observe what you’re doing, what code is doing, and asking yourself if there could be a possible state change going on (and yes, probably every line of code is a state change - but really think about what that state is when moving through your code).
Sorry if that was long winded. My bloodstream was swimming in coffee/caffeine at the time I wrote it and I just thought it was the greatest thing ever when I wrote it, but it’s helped me a lot and hope it helps you, too.
:shifty:
