# A simplified MoleMash

The MIT MoleMash tutorial for App Inventor introduces several best practices.

But sometimes “best practices” distract novices from what they really need to understand.

MoleMash means to introduce these particular big ideas:

• sprites—which can move around and react to being “touched”
• the random function, and using it to move a sprite by setting its X and Y coordinates
• keeping a score variable, and incrementing it.

But the tutorial obscures these ideas by forcing you to learn other stuff:

Subprocedures. The code to move the mole around is put into a subprocedure.

• But it’s only two lines long. We don’t need a subprocedure for this.

Positioning the mole by querying the canvas for its dimensions, constructing them as a ratio, and scaling it to the full canvas size by multiplying by the “random fraction” primitive. Seriously? I can barely understand this.

• Let’s just hard-code some X and Y limits. It’s easier to explain to kids this way.

Concatenating label text with a numerical value. The approach for keeping score uses both a label to hold the word “Score” and a global for keeping track of the score number. Then, to update the score, the label “Score” plus the number value are concatenated.

• Let’s just put a number only in the text label. Then we don’t need a separate global, and we can increment the label’s text directly.
• Also there’s no need for an UpdateScore procedure.

With this simplified MoleMash, the entire code is this:

This is far, far simpler than the MIT code.

Notice that the bounds of the random X and Y coordinates are 1 to 100. These are the default parameters of the “random integer” block when you pull it out of the palette.

This means that the mole will only jump about in the upper left corner of the canvas. That’s fine! Kids can figure out on their own how to expand the range.

For beginners, it’s better to use concrete values than abstract functions.

## One thought on “A simplified MoleMash”

1. It has always annoyed me about this app that the Android sprite can pop up anywhere on the screen, even though the image file for the canvas clearly shows only nine different potential pop-up positions. By storing the x and y coordinates of the nine locations in two lists, the sprite can easily be constrained to appearing randomly in these nine locations only. (I understand that this introduces more complexity, not less, but I think the improved game play is well worth it!)

Like