Re: Shooter XT - Open sourced 2D Sidescroller Shooter for BGT beginners
I am going to chime in here as well.
First, if you encourage others to use your code, you should, in all likelihood, attempt to keep it clean. This is not. No matter how you spin this. Let's take several examples:
int x,y; //These are the cordinates that the user will be using. We will be dealing with these later.
timer speedtimer; //The timer for the speed. If the timer has elapsed 450, the user will move.These aren't combined in a class, as they should be for this game. I was very, very confused when I looked at the extras.bgt and saw the reassigning of various variables.
Second, your comments, and this is what I am going to hit the hardest. If you don't really understand what you are doing, then perhaps you should not be providing open source material. Several examples follow:
//Create an array of bullets.
for(uint i=0; i<bullets.length(); i++)This comment is incorrect. When looping through an array, you are doing just that, looping. No extra item creation occurs, unless you do so explicitly. I hate to pick on your vocabulary, but since this is open source and, apparently, something one should learn from, I feel like we need to establish basic terminology here. As I said before, you are not creating a new array every time you loop through an already instantiated one. This also means that the following comments get invalidated:
//Create an array of enemies within the array of bullets to check if an enemy's x equals to that of a bullet's x and the enemy's y equals the bullet's y.Not only is the vocabulary incorrect here, but I also had to re-read your comment multiple times to actually understand what you meant. I could have looked at the code and have spent much less time interpreting what is happening, a fact which both of us know should be the opposite when someone writes their logic.
//Create an array of enemies.You get the picture.
While we are on the topic of comments, let's talk about why would you choose to make one. A comment is typically placed to explain logic in code or to leave a note. Most of your comments do otherwise. Again, examples go below:
//Check the move timers have elapsed.
if(enemies[i].movetimer.elapsed>enemies[i].movetime)
//Make the enemy moved based on where the player is. If the player is to the left of the enemy, the enemy will move to the left. If the players is the right, the enemy will do likewise.
if(enemies[i].emx<x)...
if(enemies[i].emx>x)...
//Now lets declare a few values.
int kills=0,deaths=0; //This will be saved in the data.dat file.
bool jumping=false,landed=true; //These two bools are for jumping and landing. If the user jumps, jumping will become true, and landed will become false. When landed is true, jumping will become false. But more on that way later.
//Now we have to create a few functions. First, lets start out with the savedata functions.I will stop right there, as I am sure that, again, we all get the picture. You explain the purpose of each line of code, rather than how it's all meant to come together. In other words, if I get your game, chances are I already know what the main function does and how to show a window. I do not need you to explain every single thing. I feel like you tried to make a mini BGT tutorial and failed, hard. To put it in perspective, what you are doing is akin to me talking to a cook and saying "We're gonna cook some scrambled eggs, but first, you need this, and this, and this, and this, and you also need to use this to check that and that to check this thing over there" without providing any relevant instructions or information. I give a few building blocks, like "you need eggs", but I think that is implied here since, you know, we are making scrambled eggs.
Third, your logic. I feel like I need to address this especially because there was a point whereI had to boot up a Python interpretor and run some mini examples to see how your mind processed ifs. More examples are coming, do not be afraid.
if(key_pressed(KEY_LEFT) and facing=="left"==false) //Checks to see if the user is facing left. If not, they turn left.I again, though this time unintentionally, demonstrate comment redundancy. My main point, however, is your if statement. You do a lot of unnecessary stuff here, a lot. First, I did not even know that you can even stack two comparisons like this, which is the point. I am not a newbie when it comes to reading code. I may not be the sharpest tool in the shed, but I'm far from dumb. What you are doing required me to boot up my Python console and create several tests to understand what you meant by that line. Needless to say, there is a much, much better way to do this. I'll provide two of them, in fact.
if(key_pressed(KEY_LEFT) and facing!="left")or
if(key_pressed(KEY_LEFT) and !(facing=="left"))The first option is the most strait forward one. It is the easiest to read when glancing through your code. It is also mentioned in section 7.1 of the BGT language tutorial. The second option works, too, but I personally avoid that one since, more parenthesis and clutter for screenreaders. So, again, why did you not use this approach? Where did you even learn this? The Language Tutorial has nothing close to what I've seen being written here. I'm still surprised that this even works, honestly.
I touched on this a little earlier, but let me expand on the lack of classes. I am not asking you to go overboard and create objects for every single thing, but game practice tutorials did create objects when they moved on past Simon. For me, that speaks of something. I mentioned your code being difficult to follow, and I meant it. For a good while I just looked at your draw function and could not understand where were those variables that it was changing located at. I'll touch on that, too, but my main point is the fact that the classes you do have are not truly classes in a sense. They're more like C Structs, that is, glorified boxes of data with no special properties attached to them. It's not your fault, exactly, every open source BGT project does this, but it is something worth mentioning.
Finally, and this is what truly bothers me: I gave you advice on implementing jumping and landing. I told you why you should not use the boolean approach. You did it anyways. If I want to add ducking, I have to change almost half of your walking code. In addition to that, throwing a bunch of booleans around just makes your code harder to read, a lot harder. You could have used an integer instead along with a couple of constants, such as IS_FALLING, but, you know. That can, and probably should, be said about a lot of your hard-coded values.
There is a lot more I could touch on, like the fact that weapons aren't actually weapons, you using two sound pools when one is plenty enough, you mixing sounds and sound pool items, but I think we all, once again, have seen the picture and or understood the point of this post. If you are considering using this, don't. You'll have to rip out most of the code if you want to turn the game into anything decent, so why not do it from scratch? If anything, use this as a cautionary tale, a checklist of sorts, to keep your code cleaner than what we both saw here.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
