Sunset Blaster postmortem: Making a bullet hell without really haven't played one

So, what was that about?

I'm making one game a week for a month, and publishing it whatever the results are. This was the first week's game. The premise was to make a bullet hell. The thing is, I didn't played any bullet hell or shut em' up before (maybe yes, if you count Undertale as a bullet hell), so I didn't really know the genre. Maybe I tried a shmup for 5 minutes in things like Nintendo Switch online's NES without putting much thought into it, so, yeah there's that. But I played ZeroRanger during the development time to get some ideas (and its reaaaally good).

First idea

The project started with a simple premise: the most dangerous zone in a bullet hell/shmup is the upper part of the screen, because the bullets come from there. What if the only way to shoot was move towards that direction? I liked this idea because it seemed to introduce a risk factor. If you saw an opening in the enemy's bullet pattern you could shoot a bunch of bullets but that leaves you exposed for the next attack.

I also thought this may work with mouse controls. As every action was mapped to moving, at first glance the mouse seemed a precise way to control the ship. I also imagined the player could learn to do fast up and down or circular movements to maximize the bullets shot in the minimum space possible.

Implementing mouse controls

I implemented a white cube that shot bullets when moved upwards. And... it wasn't clicking. In retrospective, it may had to do with the implementation and maybe giving it more thought could have worked better, it wasn't feeling right. As the mouse can be moved with virtually uncapped speed, the ships overlapped a lot with the bullets, as it was moving faster,. Didn't feel like it was shooting them.  Looking back, this could have been fixed with a more sophisticated calculation of the ship's current speed, and using it to increase the speed in which the bullets had to fly.

Also, as the bullet's spawning was a maximum of 1 per frame, it felt weird that if the ship was being moved slow, it shot a lot of bullets, but with a fast mouse dash, it "skips" frames and in the end, shoots less bullets. This could have been fixed, but for a first prototype it required too much workaround, so I decided that it wasn't a good idea.

Swapping the control scheme

After discarding mouse controls I tried keeping the idea of "shooting makes you go forward", but with traditional key controls. And, for the most part, it felt nice. I noticed it was rather tedious having to go up and down constantly to shoot; it essentially makes you only shoot half of your time. Was this a sign that the idea wasn't as promising as I initially thought? Maybe! But I said "no, i got this, I'll add a fast backdash to the bottom of the screen to solve this". This clicked reasonably well with me. It creates a loop in which you march forward, and when it gets too dangerous, you dash back to the bottom of the screen. But it felt kinda like a design patch too, so I tried giving the dash another purpose.

The idea went like this: the player has to face one big boss at the top of the screen, which will shoot bullet-hell-like patterns, and at the same time, at the bottom of the screen, smaller enemies appear over time, which you can kill with a mini bomb that executes when you finish your backdash. The dash also gives you invulnerability for the time it is active. At this point, having only the player movement implemented, I thought I had it.

The bitter truth

I implemented the rest of the game the last day I had to finish it. When I got to the point where I had the boss and the ship and could play with it, I realised: it wasn't working. If you have to go constantly forward, it is very difficult to keep your attention on dodging the bullet patterns. "Maybe this could have worked with another patterns, ones specifically thought for this controls"... But it was a lot of engineering, I had little time left (it was around 6pm), and then again, another sign that the premise wasn't good to begin with.

So I had to take a decision. Do I keep this, as a testimony of the failed mechanic? Or do I throw everything to the trash, and make a more generic, but simpler game? I opted for the second. The shooting action was reassigned to the X key, and the backdash was changed to the any-direction dash that you could see in the game. Not to mention, the little enemies that were to appear from the bottom of the screen were never implemented. I rushed the drawings as fast as I could, exported the game to itch.io, and cooked a spinach burger that I bought the day before. It was good, would buy another one.

What went right?

Ok, as you could imagine, I'm not happy with this project but not everything was bad. Im happy with how the code was written, and how the project was structured. I started giving real thought to how I name the variables to make the script easier to read. Also, I started toying with a little of state machine design pattern. I have to read more about it and how it can be best implemented in Godot, but this was a good first approach. I did one or two chapuzas with the code as we say in spanish (no idea how's that en english, Google suggest botched job), but they were really intentional, and made only because I was tired, running out of time, and don't plan to touch this code again. In general, the code was well-structured enough to let me make the last-minute changes with any trouble.

What can be improved for the next game

I think my main problem was, the prototype covered only the ship's controls. I imagined that the rest would fit, but ended up realising  it doesn't. For the next project I think I should make a dirtier prototype, but more complete, and one I'm sure it's fun, throw it to the trash, and start a blank Godot project when I know what I'm doing.

See you next Sunday!