Blog

GAME TO GAME-MAKER:

First, the requirements. We’ll get a bit more in-depth later, but by the time I had gotten through multiple prototypes, it turns out that my original conception for a bullet hell game had slipped, and in its place had risen the idea for a bullet hell maker. Why go through a bunch of similar coding troubles every time I wanted to make another danmaku when I could just add my desired features to a fully-built maker and have development of the actual game/patterns/story/etc. be orders of magnitude faster down the line?

Not only that, but wouldn’t it be cool to have something where any player could create, play, and share their own bullet hell levels and games? I’ve always been impressed with the fun and staying power of games that provide the option for community creations, so that’s what I aimed for with this.

MVP REQUIREMENTS:

• Complete Builder: Create full bullet hell levels by composing bullets -> patterns -> enemies -> waves.
• Bullets: Accommodate “enough” bullets i.e. thousands 🙂
• Fast: Run at 60 fps on my computer (specs at bottom)
• Intuitive: Easy to use. Provide graphical and search options where possible.
• Flexible: TONS of flexibility.

PRIOR ATTEMPTS:

Classic Attempt:

Being more used to Unity for development by this point, I chose to work on some prototypes in my free time using the classic Object Oriented Programming (OOP) approach upon which Unity traditionally operates. My best attempt ended up pretty nice, but this is also before I decided on a danmaku-maker.

It has a bunch of stuff that isn’t currently on the menu for my new maker, and suffers from one significant drawback that was the downfall of most tests, but it does start to have that “flavor” that these games should consider (y’know like lighting and bullet trails and stuff). It also has bullet grazes, which I just really like and think I could do some cool stuff with in the future.

As you can see, it’s pretty cool looking, but the framerate sucks with only a few hundred bullets, so it’s NO GOOD. If I really tried, I could probably push it even further. I think I was already doing things like batching to reduce the number of bullets I needed to instantiate, but even so, the thousand-bullet wall felt insurmountable with this approach.

ECS Attempt:

Interestingly, I also made a prototype using Unity’s ECS framework before my current attempt circa Dec 2022-Jan 2023. The only issue was that the ECS package was still in its experimental phase. Looking back, it was a decent attempt, but the ECS concepts were too new to me, the forum posts were almost all for an old version of the package before a big API change, and it didn’t even support sprite rendering (still doesn’t, but I found a solution online which I will talk a LONG time about in the future). It DID give me the bullet counts I was looking for, though.

WHY CARE?:

Now, you might be thinking: games have thousands of things on screen all the time, like in some city sims or for particle effects. Yes, this is true, but I’m also not smart, so for me, getting this many things on screen at once is quite an achievement.

With the way new games are also forcing higher-powered setups just to play them, I also wanted to pander a bit to the potato-PC crowd. Instead of building a bigger rig, I wanted to ensure that the lower-quality builds had something that was playable and fun while still allowing thousands of bullets.

COMPUTER SPECS:

For reference, my laptop specs are:

• CPU: Intel i7-7700HQ
• Mem: 16GB DDR4
• GPU: GTX 1050Ti