Scratch

It's easy to be a good programmer, all you have to do is know what you want to accomplish, and you can do it. A lot of people aren't sure how to be a good programmer, so I'll show you how. There are example questions, the answers to which are at the end of the post, if you are interested in them.

1. A good programmer knows his/her resources.

If you want to be effective, you need to know what your resources are, and how to use them. Go through the scratch blocks, click the help button to learn what they are, and remember which division they are in. Even more experienced scratchers are still learning how to effectively use some of these blocks, and may never learn their true potential. Programming requires constant learning, why not get a head start? If you don't do this, effective programming is difficult.

A1. A good programmer has a plan.

A plan is always a helpful thing to have when programming. Think through your game and its components. Determine what makes sense to script first, and what should be saved till last. An example would be a game with three major components, the game, achievements as an extra feature, and a menu. Try to put these in logical order.

2. A good programmer uses logic.

All you need to figure out a tough scripting problem is to think it through logically. Think about the components of what you want to accomplish. Let's say I want to make Sprite A hide when it touches Sprite B, a simple task. I will think through the components I need for Sprite A, I need a hide block to make it hide, obviously. But what about the other components? They aren't quite as obvious. But if I think logically, I remember that an if block checks whether or not a condition is true, and know that I can use it to aid me. I'll let you try and finish this problem, but hopefully you get the point.

3. A good programmer knows what to use when.

A good programmer will know, or try to find out, which method of doing something is more efficient, and will use that method, even if it's different than what they're used to. An example would be broadcast vs. variables. There are advantages to both, but which you should use is dependent on the situation. Thinking logically comes into play here too, so see if you can figure it out. An example situation to solve would be a game that is running slowly. Do we use the variable checker trigger method, or a simple broadcast? Remember though, don't be afraid to try whichever one works best! I'll let you decide which one works best for this scenario.

4. A good programmer knows when to look for help.

A good programmer knows when he/she needs help. Getting other people's opinions and knowledge can be a real time saver on a tough question. That's what these forums are for, after all.

4b. A good programmer also knows when to just do it themselves.

A good programmer also will know when relying on others is not the thing to do. Although others can be a real help on a tough question, some questions are better off answered by the one asking the questions. Normally, getting through a tough one by yourself will provide you with more knowledge than asking for help. In all of your failed attempts, you have given yourself more insight into the language of your choice. You not only now know many ways to not do something, but ways to do other things as well. That can only help you in the future.

5. A good programmer will help others.

A good programmer will sometimes need help. But other times, he/she can help others. If you see someone with a problem you know how to fix, share your knowledge! Who knows, maybe they'll help you out one day too!

Answers:
Question 1, from guideline A1. Thinking logically, the menu will come first. If it doesn't, you may have some rescripting to do after you make the game, to make the game start when the appropriate button is pressed, instead of when the green flag is clicked.
Second will be the game itself. You can't very well test achievements if you can't do the things you need to do to get them can you?
Last will be the achievements, as they are the only thing left to do.

Question 2, from guideline 2. Continuing logically, we know we need a sensor block to make the if block function, and a forever loop to keep it checking constantly. We also need a hat block to start the script. Eventually, we come up with this.

when gf clicked
forever
if <touching [Sprite B v]?>
hide
end

Nothing fancy, just logic. This script could be improved upon, but for our purposes, it's fine.

Question 3, from Guideline 3. The answer is broadcasts. The more experienced scratchers who see this will mock, but it's true. Variable checker triggers are generally less responsive than broadcasts, and they can slow down your game dramatically if used in excessive quantities. With broadcasts, which does use variables by the way, only the scripts that need to be running will be running at any given time, as opposed to all scripts running at the same time. Although use of the variable checker method is highly vaunted, and broadcasts looked down upon, broadcasts are usually the way to go.

That's the end of my brief guide, I hope it helps you in the future! If you have suggestions for more steps, let me know, I'll consider adding them.

Last edited by sonicfan12p (2013-02-01 12:45:05)