Today, I began my first formal foray into the realm of computer programming with an online educational tool called Scratch. Scratch is a simple drag-and-drop block programming tool used to help build a student’s beginning awareness of programming logic. Through reading the course materials, I learned about the several foundational programming languages, machine language, assembly, and our first higher-level programming language: Python. In this initial post I will be relating my first experience with this website, what I learned through my first exposure to the other programming languages, and how these languages might best be used.
My First Experience using Scratch
My first experience in using the online educational programming platform, Scratch, was an interesting one. I was dropped into the programming environment with very little explanation or example. It began with a basic example program to animate a sprite of a cat to move and play a simple meowing sound once the green flag button was clicked (Scratch, n.d.). However, once I got to exploring the available options for new block instructions, I remembered that one common task programmers use to help learn a new platform is to recreate the classic arcade game ‘Snake’. Once I had a vision of what I wanted my end product to look like, I set about animating a simple circle sprite with the proper controls. I quickly learned that movement commands are dependent on which way the sprite is currently facing, and so as part of any movement commands, I first needed to instruct the sprite to change direction when the corresponding arrow is pressed before moving. Once I could move the dot around the screen, I needed pellets to collect, so I created a new sprite. With this new sprite, I learned that program instructions are tied to the current sprite, and so I needed to create the behavior of this sprite from scratch. Using my current knowledge of how video games typically handle collectibles, I didn’t waste time trying to individually code each pellet as a separate entity, but instead coding my new dot as a spawner, creating and distributing clones of itself across the playing field at random when the game begins and setting a variable called ‘# of balls’ to 10. I then created instructions for the clones to interact with my avatar. When my avatar comes into contact with one of these spawned entities, it’s supposed to disappear with a popping sound and decrease the ‘# of balls’ variable by 1. Additionally, when I press the button to begin the game, I needed them to reset instead of just creating more balls, so I added an instruction telling all cloned balls to despawn once the spacebar is pressed to begin a new game. Once the balls had functionality, I needed to code a win condition for the game; so, I went back to the player sprite to code a win condition specifying that when the ‘# of balls’ variable reaches zero, the game ends and it needs to spawn a word bubble proclaiming ‘You Win!’. I also created an instruction to reset the player to the lower-left-hand corner of the screen when the spacebar is pressed to start a new game.
One of the key features of the game ‘Snake’ is the behavior associated with the player character. As more balls are collected, more segments are added to the snake, and touching one of these segments with the foremost segment results in a fail-state. I ran into trouble properly coding behavior needed to properly spawn and offset the positions of additional segments and have them follow the main character. Additionally, limitations associated with coding behavior of cloned entities do not allow them to condition behaviors associated with interacting with separate instances of the same sprite. It occurs to me only now as I write this that I might be able to overcome this limitation by creating a third entity solely for the tail segments, so that they can be coded to trigger a fail state when coming into contact with the main sprite. On top of that, the game would always spawn precisely one collectible with no collision, resulting in it being unable to be collected. My theory is that this entity is the original sprite, which is for some reason ignoring its routine following the spawning of other objects. Attempting to instruct this instance of ‘Ball’ to delete itself after spawning the others didn’t work, likely because the instruction for doing so specifies ‘delete this clone’, and the program doesn’t recognize the original entity as a clone. I overcame this limitation by adding a command to the beginning of the spawn routine to ensure it’s shown when it begins, so the clones it spawns are set to be visible, then to hide itself at the end of the routine to avoid leaving behind one uncollectable sphere.
One final problem I ran into, but was not able to figure out the cause of, was that when spawning in the collectibles, spawning in only ten would often have less than ten spawn, resulting in me having to settle on spawning 13 in order to guarantee enough balls spawn to allow the game to be won.
During this exercise, I have gotten used to using entities, using instructions and variables to control those entities, and defining basic conditional statements in Scratch. It’s given me an appreciation for the difficulty of game development and whetted my appetite for more. I find myself constantly mulling over the puzzle of how to get these troublesome problems, and instead of exhausting me, they prove to be invigorating, like trying to come up with the answer to a difficult riddle.
This iteration of the game can be found here: https://scratch.mit.edu/projects/931227421/
Machine Language, Assembly, and Python
Machine Language, the most barebones of programming languages, is the binary language that computers actually communicate in. It is literally the 0’s and 1’s that determine the sequence of transistor switches that physically execute a program. All other programming languages are simply this language, translated into a form that is more easily understood by humans and for readability and troubleshooting purposes (Vahid and Lysecky, 2019, Ch 2.8).
One step above Machine Language is Assembly, which is a basic textual representation of the instructions given in Machine Language, which needs to be converted by an Assembler before it can be run. Where Machine Language uses specific bytes to signal what instruction to perform, followed by the exact address in memory to execute to and from, Assembly translates those bytes to instructions that are easier for humans to read and keep track of, and assigns the memory addresses to shorter variables that humans can more easily work with. When the program is complete and ready to run, it’s passed through and assembler program to convert the human-readable program into an executable written in Machine Language which can be run (Vahid and Lysecky, 2019, Ch. 2.9). Prior to higher-level program languages like Fortran in 1957, programs were most commonly written in Assembly, and even after, depending on the application, Assembly was still the go-to language when the task wasn’t well-suited to a high-level language. One such example of relatively modern usage of Assembly is Super Mario World, which was coded in 65c816 Assembly language, a variation of Assembly used to develop for the Super Nintendo (SFC Dev. Wiki, 2021).
Finally, our first higher-level programming language covered is Python, which uses more complex and sophisticated instructions, each of which can represent a sequence of multiple instructions in Assembly/Machine Language. These kinds of programming languages make it far easier for humans to create complex and sophisticated programs by grouping together instructions to conduct more complex calculations and transformations of data into single commands, making the code far shorter and more readable than its equivalent in Assembly or Machine Language. Before the code can be read by a computer, it needs to be converted to Machine Language using a program called a Compiler, which translates the functions and variables of the high-level language into the expanded series of functions and memory addresses of Machine Language (Vahid and Lysecky, 2019, Ch. 2.10). Python is commonly used for data-processing due to it having many specialized instructions for conducting higher-level data-processing operations (Vahid and Lysecky, 2019, Ch. 2.11).
Ease of Use
I found Scratch to be the easiest to use, due to its readability, simplicity, and the ability to easily drag and drop instructions to modify the program. However, once I am more familiar with Python and how to use its more complex array of functions, I suspect that I will find that far easier to use overall due to how it simplifies creating multi-step functions under one command. The most difficult to use, unsurprisingly, was Machine Language. Trying to remember what bytes represent which instructions and what memory addresses to store values to was far more cumbersome, even in the basic exercises in the textbook, than in the equivalent exercises for Assembly. Assembly was sort of a mid-point between Python and Machine Language for ease-of-use.
Conclusion
In conclusion, my first experience with coding using Scratch was overwhelmingly positive. I experienced several challenges in just this first attempt, but finding ways to overcome them has left me feeling this profound sense of accomplishment and an eagerness to tackle another. Reading about different programming languages in this week’s assigned chapters has taught me a lot about how programming has come to be what it is, and I am very eager to learn more about using Assembly, Python, and the other high-level programming languages. I intend to iterate on my efforts this week, and hopefully have a fully functional version of ‘Snake’ running in Scratch for people to play soon.
References
Scratch. (n.d.). https://scratch.mit.edu/.
SFC Development Wiki. (2021, January 27). ASM Tutorial Part 1. https://wiki.superfamicom.org/asm-tutorial-part-1
Vahid, F., & Lysecky, S. (2019). Computing technology for all. zyBooks
No comments:
Post a Comment