Stupid shooter: So what worked? What failed? What do I regret not finishing?
I started writing this about 12am in the morning of release part in parcel me being an night owl and with the impending dread of releasing a game to a silent audience. Call it a high from releasing the game, or my brain buzzing with the electrons used to keep me awake, I started tearing apart my own game. What I found from it, was some finesse in the madness I had made. A small game that asked the player to improve.
What worked
When I started building Stupid Shooter, within a few hours I had a player model, movement and a test dummy to shoot. That was easy enough. When roughly designing enemies, I wanted it to be on the same field as the player: firing from alternating barrels. How does this work? I used an array of Game Objects in Unity (I believe the term is Actors in Unreal engine). The array had to be manually generated for the player/enemy and the barrel points added manual as well. But what if the player had one barrel? Here is the snippet of code that handled the alternating barrel fire.
if (_firingBarrel < _barrel.Length && _barrel.Length > 1)
{
_firingBarrel++;
if (_firingBarrel == _barrel.Length)
{
_firingBarrel = 0;
}
}
_firingBarrel is an integer that talks to the array of _barrel. Initially, I wanted to make it so that the controller for the player automatically found the barrels and saved me time setting up, but my worry was if it would be an inefficient use of memory. So, forgetting to modify the variable for clarity sake, I left is as is. The code reads easily enough from there. If there is a scenario where the number of assigned barrels was greater then one, it would add 1 to _firingBarrel. When the player would fire the bullets, it would fire from _barrel[_firingBarrel]'s position. This worked with all of my enemies and the two player ships quiet successfully and if there were more player ships in the game for players to try (sorry, you can't use the original ship, it wasn't implemented as a changeable feature). Furthermore, should I have decided to add more enemies to fight, more firing barrells would have been easy to make. However, this could cause some issues when creating a "bullet hell" style boss fight.
What went wrong
One of the key problems I found was having the enemies introduce them selves in line patterns. The initial method I tested involved a colliding system between all the enemies in a row. Long story short, it could have potentially caused a memory issue. Due to the number of enemies on screen, the number of checks each time worried me ever so slightly. None the less, I opted for the "they start in these rows" for the argument of fixing it.
The initial player model also had issues, one being size in more then one way. Both the barrels and the wings were too large, so a quick redesign was pulled together and thus the ship was made so.
Probably the most comical error that occurred was in regards to bullets not colliding correctly with anything (thank you translate function).
Other notes from people who have played the game are:
What did I regret not finishing
putting in charged up weapons would have been interesting if a session length was, at it's core, longer. An example of a charged/super weapon would be a screen high laser beam that maintains for x period of time. This, however, was directly related to the issue mentioned above. The issue with implementing it currently is: Why do so when the length of the play session would be so small? Does it seem reasonable to have a chargeable death laser when the play session is not going for elongated periods of time. But, would it have helped speed up such short sessions?
A note for future development.
And the end of it all, I'm somewhat happy with the way the "Stupid Shooter" prototype was done. Looking back, I know what I could have done, and I hope the next project will be better. The intro post for the next project will be on Friday the 15th. Stay tuned
What worked
When I started building Stupid Shooter, within a few hours I had a player model, movement and a test dummy to shoot. That was easy enough. When roughly designing enemies, I wanted it to be on the same field as the player: firing from alternating barrels. How does this work? I used an array of Game Objects in Unity (I believe the term is Actors in Unreal engine). The array had to be manually generated for the player/enemy and the barrel points added manual as well. But what if the player had one barrel? Here is the snippet of code that handled the alternating barrel fire.
if (_firingBarrel < _barrel.Length && _barrel.Length > 1)
{
_firingBarrel++;
if (_firingBarrel == _barrel.Length)
{
_firingBarrel = 0;
}
}
_firingBarrel is an integer that talks to the array of _barrel. Initially, I wanted to make it so that the controller for the player automatically found the barrels and saved me time setting up, but my worry was if it would be an inefficient use of memory. So, forgetting to modify the variable for clarity sake, I left is as is. The code reads easily enough from there. If there is a scenario where the number of assigned barrels was greater then one, it would add 1 to _firingBarrel. When the player would fire the bullets, it would fire from _barrel[_firingBarrel]'s position. This worked with all of my enemies and the two player ships quiet successfully and if there were more player ships in the game for players to try (sorry, you can't use the original ship, it wasn't implemented as a changeable feature). Furthermore, should I have decided to add more enemies to fight, more firing barrells would have been easy to make. However, this could cause some issues when creating a "bullet hell" style boss fight.
What went wrong
One of the key problems I found was having the enemies introduce them selves in line patterns. The initial method I tested involved a colliding system between all the enemies in a row. Long story short, it could have potentially caused a memory issue. Due to the number of enemies on screen, the number of checks each time worried me ever so slightly. None the less, I opted for the "they start in these rows" for the argument of fixing it.
The initial player model also had issues, one being size in more then one way. Both the barrels and the wings were too large, so a quick redesign was pulled together and thus the ship was made so.
Probably the most comical error that occurred was in regards to bullets not colliding correctly with anything (thank you translate function).
Other notes from people who have played the game are:
- Speed of the player was too slow.
- Shield walls from the original Space Invaders would have made it a bit more impactiful
- And a bug where the game crashes. I'll be fixing this problem up and will re-upload these as a quick bugs fix)
What did I regret not finishing
putting in charged up weapons would have been interesting if a session length was, at it's core, longer. An example of a charged/super weapon would be a screen high laser beam that maintains for x period of time. This, however, was directly related to the issue mentioned above. The issue with implementing it currently is: Why do so when the length of the play session would be so small? Does it seem reasonable to have a chargeable death laser when the play session is not going for elongated periods of time. But, would it have helped speed up such short sessions?
A note for future development.
And the end of it all, I'm somewhat happy with the way the "Stupid Shooter" prototype was done. Looking back, I know what I could have done, and I hope the next project will be better. The intro post for the next project will be on Friday the 15th. Stay tuned
Comments
Post a Comment