In-Depth Blog Post #5: Understanding
With so much time since the last post, I have a lot of new progress to share in this post. Over spring break, I spent some time practicing coding, and learned how to clean up my code and change variables within code to change things when the app runs. I have also raised the difficultly significantly, and the projects are starting to take more time. With more time spent coding means more code, and with this blog being really long already, I did not want to have to add in about 3000 more lines to it. So I will not be adding in the code I used anymore, as it takes up too much data and might exceed the maximum word/line limit of wordpress.
This was the main project, that took me a long time to complete. Using the triangle turning and moving code from the last post, I added buttons to press, some stars in the background (with parallax!), a projectile and some obstacles to make a space shooting game. There is not a goal to win yet, but I learned how to create game boundaries, make parallax like effects in more than one direction, and how to code collision checks.
Overall, this was a tough project to complete, as it combined most of the code and concepts from previous projects. The hardest part was trying to integrate all of the code that I had from mismatched projects into one piece.
Again, I tried to code a classic computer game from scratch. This time, it was the 1978 arcade game Space Invaders.
To create this project from scratch, I needed to use the collision mechanics I had learned to use, apply character controls, and make a moving wall of ‘invaders.’
This was not as hard as the previous project, as I had the freedom to re-code freely without needing to mesh a bunch of old code together.
Moving on with another classic game, I tried to make a breakout game. Using the same code from the space invaders game to program to paddle, I only had to make the bricks and the ball that would bounce off of the walls and bricks. However, after I had been frustrated with a problem with the player’s ship in the Space Invaders game, I decided to fix it. The ship/paddle would often go off screen and would need to be dragged back on stage. So, I made a loop that would reset the x position of the paddle to the edges of the screen if the paddle was farther than it should have been.
Here is the “code” for that (it’s not actual code!):
if paddle’s x-position is lesser than or equal to 0 (the left edge of the screen), then place the paddle at 0
if the paddle’s x-position + 20 (accounting for the length of the paddle) is greater than or equal to 100 (the right edge of the screen), then place the paddle at 100 – 20 (paddle length)
This was not the hardest project, but it demonstrates how I learned to edit code and debug my programs.
How to Have a Beautiful Mind:
The Six Hats:
When I first sat down and took out my laptop, I had a small conversation unrelated to my In-Depth study.
Me: Hello, how are you doing today?
Randy: Oh, I’m doing great.
Me: That’s good to hear. How is your project going?
Randy: I’ve been working on my own project a lot this week. I was having problems with some of the coordinate points of the pipeline contents, but I found out how to place it in a different Java Class to save space and make it more accessible for me.
Me: Nice! So what are we going to work on today?
Randy: Okay, so today we will be doing the Breakout game
Me: Alright, let’s get started
In the conversation, I covered the white hat. I knew that I was there to code the next project, needed to know what I was going to work on for the next week, and asked questions to obtain the information I needed, while still being respectful.
While working on the project later on, I decided to troubleshoot the paddle in the Breakout game.
Me: Alright, so if we add in the math over here, I feel that it should stop it from moving as soon as it hits the side.
Randy: Yes, but why not under the paddle code?
Me: I’m not sure. I just feel like putting it here is appropriate. I think we can just test it for now, just so we can avoid messing it up too much. We can try it there later I guess.
Me: Hey wait. Wouldn’t we need to place it here instead of the paddle code because of the ‘draw’ method? The paddle code only works once to place the paddle on the screen and store the information for the paddle.
Randy: That might be right. Go ahead and test it.
In this part of the conversation, I was unsure of where to place the code that would stop the paddle from moving off-screen. I simply went with gut feeling by placing it in one of the tree places it could go.
In the same conversation above, Randy used the black hat to point out a possible error in the placement of my code, but since we could keep retesting the program, he let me try to learn through experience.
In the same conversation, I used the yellow hat to find value in my own idea, after using the black hat to point out errors and believe it may not work.
I used the green hat throughout my mentor-ship meeting, as the entire premises of my project is to be creative and produce code to make a game. When I ran into a roadblock in the previous conversation, I used the green hat to rethink the way I was coding the paddle, and what parts of the code would change anything about the paddle.
I used the blue hat to cycle through the other hats constantly. When I was coding, I cycled through the green hat to produce code, the black and yellow hats to ration why the code would work or not, and used the white and red hats to ask questions about what I was doing. When I ran into the troubleshooting error previously mentioned, I used the blue hat to use the white hat to ask for information, then used the green hat to make some code, and then used the red, yellow and black hats to reason why the code was right or wrong with Randy.
It has been a fun journey so far, and I am hoping that I can apply the skills I have learned from both leadership and coding to end up with a project I can be proud of!