Programming Class Week 8 and Ending Thoughts
2013-Dec-13, Friday 16:17![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dorchadas
Well, that's finished, then. You can play my final project in the form I submitted it here--click the arrow in the upper left to start the game.
In some ways, the fears I expressed in previous posts were correct. A lot of the syntax we learned dealt with the specific implementation of Python that was used for the class that is not going to be the same anywhere else. Ways to load images, and take in mouse clicks and keyboard commands, and implement elements of the GUI, and so on. It's possible that they're similar to some kind of standard interpretation, but if so, I have no idea because we didn't learn about that. But programming isn't all just memorizing specific commands. It's more about learning ways of thinking and problem-solving skills that you can transfer over into any other programming language other than the one you started learning on, though this is obviously more or less difficult depending on the construction of the particular language.
I did run into some fun moments when I was developing this:
That was how it looked after I implemented multiple asteroids spawning and multiple missiles firing, but before I included anything about collisions. I messed around with it not just for the picture, but also to see if it was possible to have so many objects on the screen at one time that the game crashed, which it didn't. It did suffer from a lot of slowdown, which you'll also see if you try to play the finished version, but fixing that is one of the things I want to mess with now that the actual course is done. Right now it checks for collisions 60 times a second and it doesn't take position into account at all so it checks the entire screen every time even if there's only two objects on opposite ends of the screen. Hacking that down to maybe 4 times a second would probably make it work a lot better. See, an increasing number of objects becomes geometrically more intensive, because each object has to check for collision with everything already there, and everything already there has to check collision with it. Doing that when there's 12 asteroids and a ship and a few missiles and it's all being done through a browser-based code implementation which already slows everything down anyway is overkill.
On a further subject, look at the explosions in the game above. They weren't required as part of the assignment, but they were listed as a bonus step if we felt like we would be able to implement them, and I figured I'd give it a try. It only took about 15 minutes and was pretty easy. It was just loading the game, shooting things, getting an error message, fixing that, repeat until I finally didn't get any error messages. It was pretty much the perfect ideal of what bug-fixing should be like. Though once it worked, the explosion graphic was cycling through the various frames way too quickly and in the wrong location for the sprites, so that had to be fixed, but that just required checking how big the sprite was to make sure that I would cycle through to the next frame properly.
There's still more I want to do now, for my own personal improvement. Make the playing area bigger and the ship and missiles smaller. Maybe add powerups, that make missiles go further, or that shoot out two or three missiles with each press of the fire button, or a shield that blocks a single hit. A limited teleport that moves the ship elsewhere. Make the asteroids only spawn near the edge of the screen and drift toward the center instead of randomly appearing out of nowhere. Porting it over to regular Python instead of Codeskulptor's version of it.
Would I recommend this class? Not really. Even for a free class, I think it focused far too much on the idiosyncrasies of the class's specific implementation of Python and had several lazy practices, like the use of global variables because the GUI can't handle input any other way. That's not to say that I thought it was worthless, because it wasn't, but there are a bunch of other free sources for learning programming if, like me, you'recheapassunwilling to spend money.
In some ways, the fears I expressed in previous posts were correct. A lot of the syntax we learned dealt with the specific implementation of Python that was used for the class that is not going to be the same anywhere else. Ways to load images, and take in mouse clicks and keyboard commands, and implement elements of the GUI, and so on. It's possible that they're similar to some kind of standard interpretation, but if so, I have no idea because we didn't learn about that. But programming isn't all just memorizing specific commands. It's more about learning ways of thinking and problem-solving skills that you can transfer over into any other programming language other than the one you started learning on, though this is obviously more or less difficult depending on the construction of the particular language.
I did run into some fun moments when I was developing this:
That was how it looked after I implemented multiple asteroids spawning and multiple missiles firing, but before I included anything about collisions. I messed around with it not just for the picture, but also to see if it was possible to have so many objects on the screen at one time that the game crashed, which it didn't. It did suffer from a lot of slowdown, which you'll also see if you try to play the finished version, but fixing that is one of the things I want to mess with now that the actual course is done. Right now it checks for collisions 60 times a second and it doesn't take position into account at all so it checks the entire screen every time even if there's only two objects on opposite ends of the screen. Hacking that down to maybe 4 times a second would probably make it work a lot better. See, an increasing number of objects becomes geometrically more intensive, because each object has to check for collision with everything already there, and everything already there has to check collision with it. Doing that when there's 12 asteroids and a ship and a few missiles and it's all being done through a browser-based code implementation which already slows everything down anyway is overkill.
On a further subject, look at the explosions in the game above. They weren't required as part of the assignment, but they were listed as a bonus step if we felt like we would be able to implement them, and I figured I'd give it a try. It only took about 15 minutes and was pretty easy. It was just loading the game, shooting things, getting an error message, fixing that, repeat until I finally didn't get any error messages. It was pretty much the perfect ideal of what bug-fixing should be like. Though once it worked, the explosion graphic was cycling through the various frames way too quickly and in the wrong location for the sprites, so that had to be fixed, but that just required checking how big the sprite was to make sure that I would cycle through to the next frame properly.
There's still more I want to do now, for my own personal improvement. Make the playing area bigger and the ship and missiles smaller. Maybe add powerups, that make missiles go further, or that shoot out two or three missiles with each press of the fire button, or a shield that blocks a single hit. A limited teleport that moves the ship elsewhere. Make the asteroids only spawn near the edge of the screen and drift toward the center instead of randomly appearing out of nowhere. Porting it over to regular Python instead of Codeskulptor's version of it.
Would I recommend this class? Not really. Even for a free class, I think it focused far too much on the idiosyncrasies of the class's specific implementation of Python and had several lazy practices, like the use of global variables because the GUI can't handle input any other way. That's not to say that I thought it was worthless, because it wasn't, but there are a bunch of other free sources for learning programming if, like me, you're
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-Dec-15, Sunday 17:48 (UTC)In addition to the improvements you already mentioned, I'd suggest some kind of visual representation of when you lose a life. Right now, without checking the counter, I found it very difficult to tell the difference between getting hit and shooting an asteroid at close range.
Sorry to hear the class wasn't very good.
no subject
Date: 2013-Dec-15, Sunday 20:03 (UTC)Right now, without checking the counter, I found it very difficult to tell the difference between getting hit and shooting an asteroid at close range.
Yeah,