Hello everyone!
After many many years of simply playing games, I finally decided to see how it feels on the other side of the aisles and try out game developing. I'm still very new to this, so I started with the excellent KidsCanCode tutorial, and after many many hours of why doesn't it work!? I finally got something that works and feels more than just a tutorial.
If you have a few minutes to try it out and maybe leave some feedback, I would appreciate it a lot. Thank you!
My immediate impression is that its fun to play and looks nice and coherent!
However, it quickly becomes repetitive as there are only a couple of enemies and powerups. Also, having no breaks in the action wears you down quickly... just pausing for a moment and saing "Wave X" or something would go a long way. Then start upping the challenge... as it is you can just hold fire and bounce back and forth across the screen, only caring to dodge once in a while. Some stronger enemies, more dangerous/coordinated flight patterns, and more aggressive attacks would balance out the player's rather powerful starting weapon. I like that it isn't a "one hit-point" game, but again that should eventually be met by appropriate opposition.
Slight nit-pick, the animation when the enemies fly in from the top seemed a little overbearing to me. It is quite fast and happening constantly which can be somewhat distracting, or worse (I sometimes get slight dizziness/motion sickness from games, not saying I got dizzy playing this as for me it is usually 3D games with a field of view that I don't like... but sometimes random things you wouldn't expect can trigger a reaction in certain people, for example people who get vertigo or epileptic reactions). Just splitting up the waves more would automatically help with this, or perhaps a slower animation.
Thank you very much for checking out my little game and for you feedback!
I agree with you completely on repetitiveness and lack of enemies/powerups. I was a little bit intimidated with the whole coding process after watching some tutorial videos, as my own coding abilities are at beginner level at best- my only formal training being Pascal back in high school, but that was more than 2 decades ago. I decided to start with something really small and simple that I thought I could actually pull off without getting too confused or burned out, and then just make more small projects incorporating more and more different and more complex aspects to learn just few things at the time. But it's starting to sound like an excuse, so I'll leave it at that. If I do make another top down shooter like this one, I think I would go with different stages instead of waves though, as that would allow me not only to make more diverse enemies, but add different backgrounds and themes altogether. Nevertheless, your observation is right on the money, the game does get repetitive and boring quickly.
On your second point, that actually never occurred to me. I know a lot of people have difficulty playing VR games- especially the ones involving fast running or falling from great hights- and some people get affected by camera motion blurs really badly. My girlfriend for example physically can't play Okami as more than 10 minutes of blurry camera gives her migraines. I never thought similar effect could happen from 2D games, and I will definitely keep that in mind moving forward!
Once again, thank you very much for taking time to try out my game and for all these suggestions how I can improve!
Well keeping it small and simple is definitely the way to go at this stage, and probably the reason why this looks like a complete, if limited, game. Rather than an open pandora's box that has been spilled all over the floor ^.^
One piece of advice I would give you is, try to get the most mileage out of your code. Basically, instead of writing a function to have an enemy shoot one bullet in one direction, write the function so that the enemy can shoot any number of bullets, of any type, in any direction. Having this type of philosophy from the start will usually not add a huge amount of time to your code writing process, while saving you a LOT of time and headaches later on when you want to add variety to the gameplay. Even if you think something can be hard-coded now, down the road you could change your mind and find yourself going back and refactoring things that could have been more open-ended from the start.
I try to catch myself doing the hard-code thing, because it is easy to slip into this habit in the initial stages of development, when you are basically prototyping and just want to slap things together and get it running as fast as possible. And sometimes it is helpful to just quickly scratch something out and see if it works... however, I have found that promptly changing those hard-coded behaviors into more generalized ones really improves on the "iteration" process later on, when you want to be focusing on creating actual content rather than rewriting functions.
That's a great advice, and to be honest I have the same approach on how I try to code things- keep most aspects modular and interchangeable, so instead of rewriting whole blocks of code to see the change, all I need to change is a variable or two. Furthermore, I think that the way Godot engine works, it almost forces you- or at the very least guides you- to working this way =)
