Programming Advice
・Related to the above: always leave specifications for data models and functions, even if it's only an explanation of the parameters.
・Be wary of scope. Always use as local scope as possible. Something I was reminded of harshly recently in a loop variable collision because I decided to be lazy and predefine the iterator at the global scope.
・The first step to using someone else's code is to not use someone else's code. Or however 12Me21 worded it.
I can't find the quote in the chat logs for some reason. The closest I got was
12Me21[03:00]g: When you're writing a program (especially if it's a game) and the code is just too long and complicated
It's usually a good idea to start over
except you're not really starting over since you've learned from your mistakes
Lumage[03:01]g: does this one go along with "the first step of using another person's code is to not use other people's code"
Anyway, my advice:
-If you make the title screen before the actual game, you've already failed.
-Don't use GOTO or GOSUB please.
-Actually pick good function/variable names that aren't one letter long.
-Don't use WAIT or have unskippable delays.
-Never trust the SmileBASIC manual.
-If you make the title screen before the actual game, you've already failed.What if you built the game on the title screen? As in the title was the game? The title itself is a stage/level? These are probably too much for beginners but I'll put them here anyways. ‣If possible, have the world update code or whatever have run with the other code. (for example, idle animations can happen during dialogue or the butterfly AI runs while you're fishing) ‣Try to keep the world update and the graphics drawing code separate. You get cleaner code. ‣Please, don't have WAITs that take too long. At least have them be skippable/fast-forwardable. Avoid using WAIT in general. ‣Avoid hard-coding everything. Who knows if you want to add a new color of fish in your game?
Ultimately, you should code in the manner that makes the most sense to you. A lot of this advice is good and will apply to most people, but if you take it as a hard and fast rule, you might find that it's just not working for you.
There are things that will almost always be helpful though, and a lot of what is mentioned here is just that. Here's some explanation for why though:
- Using GOTO can make your code very hard to follow, even for yourself. When your code starts to get up to hundreds of lines and the code is bouncing all over the place, it becomes very difficult to follow the line of logic through all the GOTOs because you never know what's dependent on something else. It's like unraveling all your sewing thread and dropping it all on the ground. If you use functions instead (DEF), the function can be "isolated" so it's not dependent on anything else, which is more like dropping spools of thread on the ground without unraveling everything.
- Starting on the title screen rather than the game itself can cause you to lose steam quickly. The title screen might be easy, but it's usually dull and tedious, and you spend all this time making it look good and you still don't have a game. It's very easy to become disheartened at how long it took just to make the title and not even bother making the game. If you start with the GAME first, you can get something playable right off the bat, and it's usually much more fun to write and come up with ideas for your GAME than for the title screen.
- Adding unnecessary WAITs (like for fake loading times) is usually seen as self-important and is a waste of time. If your game doesn't take time to load, the ONLY reason you would want to make it look like it's loading is to make it seem like there's more to your game than there actually is. Don't waste the player's time, and don't make yourself look like a fool. Nobody likes waiting.
- Organization and comments help you figure out what's going on. It's like keeping your room organized: you might think you know where everything is NOW, but someday in the future you'll be looking for a memory card for HOURS because you have no idea where you put it. You might be super smart and have an excellent memory, but write a big enough program and eventually even you won't be able to visualize the entire program in your head. That's when breaking the program down into pieces and commenting those pieces really helps; you only have to remember how the easy pieces fit together rather than how the whole program flows around.
Use the reference material. Even if it doesn't directly answer your question, even if it is flawed, it will at least give you an idea what the issues are and give you concepts and vocabulary such that you can ask a useful question.
Some tips to make your editing life easier. These aren't really programming tips, but SB productivity tips (maybe rename the thread.) Other people did it, I can too.
- Keep functions you'll probably use often in files that are easy to find. For example, I have a file of misc math functions. If I need, for example, the distance function, I load MATHFUNC into a spare slot, copy it to my code, and I'm done.
- Use the SHIFT+F1/F2 buttons for saving and loading. A nice GUI is better than typing a command (on a PC it wouldn't be, since you have a real keyboard.)
- Speaking of nice UIs, know the button controls in the file list to get around faster. X jumps immediately to SYS wherever you are. Y backs out of a folder, and works the same as A on the folder list. A selects an item. B closes the menu. D-pad up and down scrolls by one, Shoulder+D-pad or Stick scrolls by a page. Shoulder+Stick jumps to top or bottom.
- If it helps you to split your code into multiple files, do so. Just be sure you know what you're doing.