During the process of creating my video game, I came across a few points so far in which I had to problem solve a bit. The first came in the drawing of one of my sprites. I wanted my characters to have an upwards attack they could perform during their jump animation. However, the problem that I came across was that my character's arms were too short to go above their heads while staying true to their form. The solution I found was to add a sort of barrier which extends the sprite slightly higher. This simple solution was an example of not thinking too hard about the problem.
As for some coding struggles I had to overcome, there have been several so far. The previous "gravity" code I created for my Kirby project was not able to be compatible with this project as this time I would be using a stage including platforms which I would want the character's to land on. I studied ways in which other Scratch users created a gravity effect. The most common, which I accomplished in the second down from the top left block, was to set an "if ___, then ___" block relating to a certain color. This block sequence was set so that when the characters landed on the stage sprite, which was set to a certain purple color, they would cease their falling animation. This solution comes as the direct result of studying the way others have faced this problem and learning to understand their solutions before implementing them myself. After all, how could I use a block of code without fully understanding it? If it failed, I wouldn't have a way of finding the cause of the failure. The understanding of the code is the key here.
While my jumping animation came easily to me, my walking left and right animations felt choppy. My original block sequence was simply "When D is pressed - glide". My issue was that there was no repeat and no hold option. My characters were simply moving 10 pixels at a time. I added in a "Repeat until" block, in addition to a sensing and operator block combo, seen in the top right block. These blocks allowed me to be able to continually move my characters right or left as long as I was holding my directional keys. For this predicament, it was the idea of thinking about what my coding was missing before adding it in and testing it.
An inquiry I had while constructing my coding was if and how I would be able to create directional attacks and how many I would be able to include. While playing similar Scratch games I saw that others made it an option to have directional moves so I sought out to create my own code for them. I knew I would need the start block of "When __ is pressed", but the key to my sequences located at the bottom of the photo was the sensing block recognizing "key __ pressed?". I only found this block while searching through all of the optional blocks in Scratch looking for anything that looked helpful. The way these block sequences are set up, if the attack button is pressed while a directional button is pressed, the sprite will change to their specific attack costume. In order for this to affect the other sprite however, I needed to add in a broadcast block. Each specific directional block needs it's own broadcast block as they each will have a different effect on the opponent. More on this later. If it weren't for closely examining the tools available to me in the block options, I would not have been able to make these sequences work.
Along with the broadcast sending blocks, I would also need to include on each sprite a "When I receive ___" block, as seen on the top sequences of blocks in the photo. With these blocks is where I really was able to control what the attacks would do. This is where guessing and checking came in. I would set the points at which the sprites move toward after being attacked and then play around in the game to see how impactful they were. I went so far as to even play my game with a classmate to see how easy or hard it was to knock the opponent off the stage. This helped find the sweet spots to which I would set the sequence.
The bottom sequences of texts were my result from trying to create an ending to the game. The key block here which I also found by scouring through the options of blocks, was the "touching edge" block. This block coupled with a new broadcast block, I was able to make a simple, yet quaint, end screen to the game in which the winner would appear on the top of the stage while a new sprite displaying the words "Game Over" would show. This is yet another example of not thinking too hard about the struggle to create an ending screen. By utilizing the tools available to me, I was able to make an ending screen that suits the game well.
In the end, although my video game isn't finished, I've already understood and accomplished much. What I have so far is playable, and I wouldn't have been able to do it without understanding the tools at my disposal, studying other Scratcher's projects, not thinking too hard, and experimenting with my code. In teaching, these are lessons which students should learn in order to grow as artists, whether they are using Scratch or any other material such as paint.
