New to Smilebasic need challenge suggestions

I must begin by saying that we just got this in the Australian Eshop and it looked cool so I grabbed it. I got no programming experience whatsoever but games like TIS-100 and Human resource machine made me want to learn a language and showed me that solving puzzles using something like a programming language is fun. I have been messing around with the app since getting it and I was wondering if people can help me by suggesting some challenges for me to aim for. What I meant by this is that I want suggestions from people who know more about this app and the language it uses and I want to try and achieve those. For example I have been messing around with trying to count from 1 to infinity, then try to reverse count and learn to stop counting at specific numbers and whatnot. I need some suggestions on what basic tasks to achieve and moved to more advanced challenges then maybe dabble in creating something entirely new. Your help will be fully appreciated.

You probably won't know what you want to make or even what you can make for a good while. But at some point, you will come up with an idea. Something you would like to see made more than anything. At that point, just start programming. Your first few projects won't be pretty, but nobody ever starts perfect. A lot of projects won't get done either, whether it be lack of drive or shoddy, unreadable coding. This, again, is perfectly natural. You learn a lot of new things with every project, and the next thing you make will be even better than the last. Once you get the hang of things, the only way is up! As for suggestions for where to start...

• The built-in help menus are your best friend. There's a question mark button on the top right of the keyboard. Whenever you type out a command, it gives you documentation on how it works.
• DEF blocks are crucial to making a project that is easy to read. They make coding modular, which is a major plus for larger projects. I recommend learning them early.
• Arrays are also one of those crucial elements to learn. They let you store lots of data in an index, and have more uses than you'll ever realize.
• Try to avoid using GOTO. We're past that. It makes coding a headache.
• That being said, @labels have other uses outside of simple GOTOs and GOSUBs. The ON GOTO/GOSUB function is very similar to a switch case (if you're familiar with it)
• camelCase is veeeery handy. Don't just type everything in ALL CAPS because you don't feel like pressing the tiny caps lock/shift key on the ever so tiny keyboard. Your future self will thank you for the readability.
• Be consistent! I have a personal ruleset for typing where I use all caps for built-in commands (also called reserved words), camelCase for all variables and arrays, and CapitalizeFirstLetters for DEF block calls. Find what suits you, and stick to it!

And finally, don't forget us! I'm pretty sure we can provide better advice than Miiverse, and it sounds like Nintendo is gonna shut that down sometime soon anyway. Lots of other people have had the same questions you will have, and the forums might have the answers already. They're just a quick search away.

You probably won't know what you want to make or even what you can make for a good while. But at some point, you will come up with an idea. Something you would like to see made more than anything. At that point, just start programming. Your first few projects won't be pretty, but nobody ever starts perfect. A lot of projects won't get done either, whether it be lack of drive or shoddy, unreadable coding. This, again, is perfectly natural. You learn a lot of new things with every project, and the next thing you make will be even better than the last. Once you get the hang of things, the only way is up! As for suggestions for where to start...

• The built-in help menus are your best friend. There's a question mark button on the top right of the keyboard. Whenever you type out a command, it gives you documentation on how it works.
• DEF blocks are crucial to making a project that is easy to read. They make coding modular, which is a major plus for larger projects. I recommend learning them early.
• Arrays are also one of those crucial elements to learn. They let you store lots of data in an index, and have more uses than you'll ever realize.
• Try to avoid using GOTO. We're past that. It makes coding a headache.
• That being said, @labels have other uses outside of simple GOTOs and GOSUBs. The ON GOTO/GOSUB function is very similar to a switch case (if you're familiar with it)
• camelCase is veeeery handy. Don't just type everything in ALL CAPS because you don't feel like pressing the tiny caps lock/shift key on the ever so tiny keyboard. Your future self will thank you for the readability.
• Be consistent! I have a personal ruleset for typing where I use all caps for built-in commands (also called reserved words), camelCase for all variables and arrays, and CapitalizeFirstLetters for DEF block calls. Find what suits you, and stick to it!

And finally, don't forget us! I'm pretty sure we can provide better advice than Miiverse, and it sounds like Nintendo is gonna shut that down sometime soon anyway. Lots of other people have had the same questions you will have, and the forums might have the answers already. They're just a quick search away.

Thank you so much for all the very useful tips. I don't have a clue about the capabilities of the program. I was wondering what exactly does array do? Also without spoiling anything, are there ways to make tables and list in this program?

When I was learning the basics of programming I'd often use what I learned to make a simple a program and then keep building onto it. For instance I would:

• Build a number generator, or make two dice
• Then try to keep track of the amount of times that the number appeared in millions of simulations.
• Next try to display that data first with text, then lines, then drawing my own menus and learning to call them to the screen.
• Lastly I found myself cleaning up code, trying to make it more efficient, and modularizing repeated code into DEF functions for clarity.

The program itself would have no practical implications other than to satisfy my curiosity, but would help me familiarize with the syntax of the given language. An approach like this, especially when things like puzzles and statistics already hold my attention, had me practicing for hours an hours. I would essentially build from one skill into the next depending on what I felt was needed for the program but I had yet to learn. P.S. Useful Tip: If you want to switch to lower case without hitting the caps lock you can just hold down the Right or Left Shoulder button.

Simple programs could be: a number guessing game, tip/or percentage calculator, paper rock scissors These could be useful to practice coding because they require user input, and you'll need to learn that. You can also practice with the logic and control structure that is involved, i.e. Getting input, Evaluate input, Perform task... I found myself also wanting to make these things look pretty on screen as well. So go ahead and try to format your outputs to display nicely (maybe ASCII art). If you need to perform some sort of task but don't know how then try looking it up in the forums or in smilebasics' e-manual; a function probably exists for said task... BUT it's sometimes helpful to make the function yourself just for practice.

I was wondering what exactly does array do? Also without spoiling anything, are there ways to make tables and list in this program?

"Array" is another word for "list", basically. Unfortunately, there is no literal syntax for them (you can't write, say, FOO=[1,2,3,4] like in some languages), but it is still possible to make them. Tables (also known as dictionaries) aren't built into SmileBASIC, but there are ways to approximate it. For instance, a simple way is by having two arrays, one for keys and one for values.

I was wondering what exactly does array do? Also without spoiling anything, are there ways to make tables and list in this program?

Basically, arrays are an index of values held under one name. SmileBASIC has support for 1 dimensional, 2 dimensional, 3 dimensional, and even 4 dimensional arrays. Imagine the game of Battleship, where you call out "A9." This means you are looking to know the contents of the 1st column and 9th row. This analogy reflects the function of a 2D array. A good way to visualize higher dimensional arrays is to think of each dimension as an array containing arrays within it. After all, we live in a 3D universe, and visualizing a 4D array as anything but a collection of 3D arrays would be very difficult. In SmileBASIC, arrays must be declared. This is accomplished by typing DIM arrayName[arraylength] anywhere before the array is to be used. Let's look at an example: DIM oneDimensional[8] oneDimensional is the array name. [8] is the array size declaration. The real catch here is remembering that arrays start counting from 0. 0, 1, 2, 3, 4, 5, 6, 7. That's 8 indexes, which is what you declared. Let's look at another example: Dim threeDimensional[2,15,20] You might notice there are more numbers in brackets. This is how you declare multiple dimensions. Visualize a rectangular prism that is 2 units wide, 15 units tall, and 20 units deep. These are your arrays, and you cannot go outside of their bounds. Reading from an array and writing to an array is extremely similar to variables. Let's say we have already declared an array with DIM ourList[2,5]. For demonstration purposes, we are interested in the 2nd column and the 3rd row. If we wanted this array element to store the value 27, we'd do so by typing ourList[1,2]=27. Reading from that index is equally simple. Something like PRINT ourList[1,2] would output 27 to the screen. (on a side note, using PRINT is pretty ameteur and consumes a lot of space. SmileBASIC has a shortcut function to it. ? ourList[1,2] performs the exact same function as PRINT ourList[1,2]) Filling in arrays manually is very time consuming. Thus, I recommend you investigate FOR loops. The built in documentation should tell you everything you need.

Don't worry TOO much about avoiding GOTO. As long as you use it right, it's fine. For example, in this case you should NOT use it:

'bad:
@L
 PRINT "HI"
GOTO @L
'good:
WHILE 1
 PRINT "HI"
WEND

But here it's probably the better option:

'good:
FOR X=0 TO 10
 FOR Y=0 TO 10
  IF CHKCHR(X,Y) THEN GOTO @BREAK
 NEXT
NEXT
@BREAK
'bad:
B=0
FOR X=0 TO 10
 FOR Y=0 TO 10
  IF CHKCHR(X,Y) THEN B=1:BREAK
 NEXT
 IF B THEN BREAK
NEXT

Generally, you should avoid using it instead of WHILE or REPEAT, and avoid jumping long distances. If you're just skipping a few lines, like to break out of multiple nested FOR loops, it's OK.

'good:
FOR X=0 TO 10
 FOR Y=0 TO 10
  IF CHKCHR(X,Y) THEN GOTO @BREAK
 NEXT
NEXT
@BREAK
'bad:
B=0
FOR X=0 TO 10
 FOR Y=0 TO 10
  IF CHKCHR(X,Y) THEN B=1:BREAK
 NEXT
 IF B THEN BREAK
NEXT

Better:

B=FALSE
X=0
WHILE (X<=10) && !B
 Y=0
 WHILE (Y<=10) && !B
  IF CHKCHR(X,Y) THEN B=TRUE
  Y=Y+1
 WEND
 X=X+1
WEND

If the exit condition for the loop is X exceeding 10, then FOR is a good way to indicate that. If the exit condition for the loop is more involved, then FOR is a poor way of expressing that. It makes for cleaner code for the exit condition to be apparent at the beginning of the loop (or perhaps the end, if you use REPEAT).

I have been playing around with the exercises at exercism.io for a little while. Would it help if I translated some of them into SmileBasic? Would anyone want that? You are largely just writing functions to pass test cases. Not really having sprites run around or being interactive. The first on is just writing a function that returns "Hello, World!"

Better:

B=FALSE
X=0
WHILE (X<=10) && !B
 Y=0
 WHILE (Y<=10) && !B
  IF CHKCHR(X,Y) THEN B=TRUE
  Y=Y+1
 WEND
 X=X+1
WEND

If the exit condition for the loop is X exceeding 10, then FOR is a good way to indicate that. If the exit condition for the loop is more involved, then FOR is a poor way of expressing that. It makes for cleaner code for the exit condition to be apparent at the beginning of the loop (or perhaps the end, if you use REPEAT).

That's a great example of what NOT to do. Unlike the simpler version using FOR, it isn't immediately obvious what your code does. Using flag variables makes your code a lot messier, and replacing the FOR loops with WHILE loops removes the obvious hint that you're iterating over all the locations in a 2D grid. Avoiding GOTO at all costs can greatly decrease your code quality, and it's very easy to restructure the code to not use GOTO in a slightly different situation. For example, it can be easily converted to work inside a function:

DEF CHECK()
 FOR X=0 TO 10
  FOR Y=0 TO 10
   IF CHKCHR(X,Y) THEN RETURN FALSE
  NEXT
 NEXT
 RETURN TRUE
END

When you discover that something like GOTO is often bad, it's just human nature to overcompensate and avoid it entirely, even though there are a few situations where it's still useful. You shouldn't always worry about whether you're using "bad" features; the real goal is to write clean, readable, and efficient code, not just to follow a strict set of rules on what features should and should not be used.

To put it bluntly, using GOTO or GOSUB frequently in the global environment is unwise, since you cannot re-use the same label twice, and you must memorize what you've already used elsewhere. On the other hand, using GOTO and GOSUB within DEF blocks is an example of "good" usage, as those are more akin to local environments, and labels between seperate local environments aren't shared. But that's not really a beginner tip

To get an update loop I have to use a @Label and a GOTO. If you say that I should avoid GOTO at all costs, what's an alternative way to get the main loop in your game? I apologise if this is a stupid question!

To get an update loop I have to use a @Label and a GOTO. If you say that I should avoid GOTO at all costs, what's an alternative way to get the main loop in your game? I apologise if this is a stupid question!

Replace the GOTO with WEND Replace the @Label with WHILE TRUE WHILE loops are a combination of conditionals and basic loops. If you wanted to, you could replace TRUE with any conditional, such as var==19. This would make the loop only perform its contents if the conditional is true. Though, 12Me21 has a point. The only real restriction you should set for yourself is to strive for clean, readable, and efficient code. If a GOTO loop suits your program, use it.

That's a great example of what NOT to do.

BREAK is a great example of what NOT to do, if there is a way to avoid it. One feature of quality, maintainable code is the ability to skim it. It should not require a more close reading of the code, to understand its features, than is necessary. Indentation of source code is clearly for this purpose. The flow of control is always - From one line to the next line down - From one line to the next line at the same level of indentation, either up or down (made clear by the keywords used) - From one line to another line specified by an identifier on that line (a label, or function name) Except when you use BREAK. Then, the flow control is to some line further down at shallower indentation - and it's not clear how many levels that is, except by close reading, by examining each line that's the first one shallower than the last one you examined. It gets harder to skim code and get a sense of its shape when the flow control gets needlessly more complicated like that. And it's brittle - if you need to search within a string, and write code that uses INSTR, for instance, and later it turns out that it's better to implement that search with a loop, then that one BREAK can completely change how the program runs.

Unlike the simpler version using FOR, it isn't immediately obvious what your code does.

In the simpler FOR version, it isn't immediately obvious what the code does and doesn't do - it doesn't always iterate 11 times. In the WHILE version, it is immediately obvious that the exit condition of the loop is not simply 'X exceeds 10'.

replacing the FOR loops with WHILE loops removes the obvious hint that you're iterating over all the locations in a 2D grid.

You mean, the hint that the code does something it doesn't always do? Good. Misleading hints should be removed. The CHECK function is the best code so far, good to show that approach too. I'll finish by saying: when you think that something like using flags is often bad, it's just human nature to overcompensate and avoid it entirely.

I'll finish by saying: when you think that something like using flags is often bad, it's just human nature to overcompensate and avoid it entirely.

Is it just me, or is it getting heated in here?

I'll finish by saying: when you think that something like using flags is often bad, it's just human nature to overcompensate and avoid it entirely.

Is it just me, or is it getting heated in here?

Looks to me like an argument over advanced coding practices in a beginner's help thread.

While i have your attention. I am using TOUCH to get the position of the touch screen. I then print the position on the screen. For some reason, the Y value freaks out and displays the wrong number. Especially when I'm touching nearer the top of the screen. 7R7QN3QJ Do you know what's happening here?

Looks to me like an argument over advanced coding practices in a beginner's help thread.

At the beginning is the best place to develop good habits, and avoid bad ones. After the beginning, it gets quite a bit harder to do that.