X
XirmiX
Guest
I've been working on a physics-based, 2D top-down tank shooter game for quite some time now. I've implemented various mechanics through my journey and although the game is nowhere near finished, it's pretty fun as a debug currently.
Just now, I came accross a possible issue that can determine both how much content my game potentially can actually have, how much work I'll need to invest in this and how much latency it might cause whilst being played as well as how much overall space it will take up. I am faced currently with two choices because of reasons I'll explain in a bit:
1) I can leave my playable-object based... objects as they are and go through the route of the initial idea I had, which is using alarms. Basically, the game will have multiple weapons. My plan was to have the game check which sprite the weapon object actually has in order to determine which weapon mechanics it should actually have. I have planned about 9 - 11 weapons to be added to the game. The thing is, a lot, if not all of these weapons will need alarms for each one of them to determine the delay of shooting. If each weapon uses up an alarm in the object, then I am limited in the amount of weapons in the far future I can actually create for the game as a whole. This might not be a problem at the moment, but could be a potential problem if I ever come up with a huge variety of great weapons (currently I only have 1 great idea of my own, the other being weapons I'm replicating from another game, which is basically what I'm creating, but in 3D format).
2) I can change the name of my weapon/turret hull objects to be the names of those weapon's/turret's and hull's/corpus's names (e.g. changing obj_hull to obj_viking) and do this through all of the code I have them set within. Then, create new objects for all other hulls and weapons and copy and paste all of the/most of the existing code to these other objects and then edit them one by one over time to make the weapons and hulls functional. This would increase the overall hard space that the game takes up, however it would decrease the lag as the game wouldn't need to go through checking all of the sprites and if statements for all other weapons/hulls until it gets to the right thing every single frame and time the hull and the turret are created. It would also not limit me to just 12 weapons maximum. However, this would mean that I would need to un-sync the two objects from being a child and a parent, which they currently are set to, which could bring about multitude of problems along the way and like right now.
Actually, I could implement it so that the whole weapon object requires only one alarm (I think I can), though this would require more if statements within if statements and if statements within alarms, all of which would need to be checked, which would increase lag and agh!
So, what do you guys think? Perhaps there's some other way to do this entirely? Or which do you think would be the better idea? Rework the code and strategy and have a bit more hard space required or deal with the potential tad bit higher lag, but keeping things the same?
Just now, I came accross a possible issue that can determine both how much content my game potentially can actually have, how much work I'll need to invest in this and how much latency it might cause whilst being played as well as how much overall space it will take up. I am faced currently with two choices because of reasons I'll explain in a bit:
1) I can leave my playable-object based... objects as they are and go through the route of the initial idea I had, which is using alarms. Basically, the game will have multiple weapons. My plan was to have the game check which sprite the weapon object actually has in order to determine which weapon mechanics it should actually have. I have planned about 9 - 11 weapons to be added to the game. The thing is, a lot, if not all of these weapons will need alarms for each one of them to determine the delay of shooting. If each weapon uses up an alarm in the object, then I am limited in the amount of weapons in the far future I can actually create for the game as a whole. This might not be a problem at the moment, but could be a potential problem if I ever come up with a huge variety of great weapons (currently I only have 1 great idea of my own, the other being weapons I'm replicating from another game, which is basically what I'm creating, but in 3D format).
2) I can change the name of my weapon/turret hull objects to be the names of those weapon's/turret's and hull's/corpus's names (e.g. changing obj_hull to obj_viking) and do this through all of the code I have them set within. Then, create new objects for all other hulls and weapons and copy and paste all of the/most of the existing code to these other objects and then edit them one by one over time to make the weapons and hulls functional. This would increase the overall hard space that the game takes up, however it would decrease the lag as the game wouldn't need to go through checking all of the sprites and if statements for all other weapons/hulls until it gets to the right thing every single frame and time the hull and the turret are created. It would also not limit me to just 12 weapons maximum. However, this would mean that I would need to un-sync the two objects from being a child and a parent, which they currently are set to, which could bring about multitude of problems along the way and like right now.
Actually, I could implement it so that the whole weapon object requires only one alarm (I think I can), though this would require more if statements within if statements and if statements within alarms, all of which would need to be checked, which would increase lag and agh!
So, what do you guys think? Perhaps there's some other way to do this entirely? Or which do you think would be the better idea? Rework the code and strategy and have a bit more hard space required or deal with the potential tad bit higher lag, but keeping things the same?
