[Free] DanmakU: A 2D Bullet Hell Development Kit

NOTE: A newer version of the asset, based on the new C# Jobs system has been started on. A new thread has been started for it here: https://forum.unity.com/threads/free-open-source-danmaku-bullet-hell-development-kit.519181/

Please see the following for more information:

• https://forum.unity3d.com/threads/free-danmaku-a-2d-bullet-hell-development-kit.320940/#post-3186083 - Latest post about this project
  
• https://github.com/james7132/DanmakU/issues/28 - Github issue regarding the project.
• https://discord.gg/e9G43m2 - Development Discord server. I'm gauging public interest, and by proxy development effort to invest in the project based on the number of people that join.

Danmaku (弾幕, lit: "barrage" or "bullet curtain"), called "bullet hell" in the western world, is a subset of shoot 'em ups in which the majority of the screen is occupied by bullets. Good examples are Ikaruga, Jamestown, Gundemonium, DoDonPachi, and the Touhou Project games.

DanmakU is a open source, high performance development kit for 2D danmaku games. At it's core, DanmakU is about highly controllable and scriptable particle systems that are able to collide with Unity's 2D colliders.

Largely based on Touhou Danmakufu, a powerful scripting engine for danmaku games, the commonly used functions mirror many of the functions seen in Danmakufu ph3.

I've seen a lot of questions on how to deal with performance issues of bullet hell games made in Unity, and sadly most solutions I've seen have been rather subpar. Most solutions devs try involve individual GameObjects as bullets, each with their own MonoBehaviour, renderer, and collider. Most of these solutions quickly grind to a laggy mess when more than 500 or so bullets are active, even on powerful gaming rigs. I didn't think that was enough (more bullets = more fun), so I've optimized DanmakU to the absolute limit: I recently got 21,000 bullets moving independently at 60fps on a standard gaming desktop, and ~6,500 on a Samsung Galaxy S3.

The project's Github can be seen here: https://github.com/Rhythmia/DanmakU
The Github wiki has a bit of documentation, but currently needs to be updated.
There's also a bit of scripting documentation, but it too hasn't been update in a long while: ttp://danmaku.rhythmia.org/Docs/html/annotated.html
Features:

• 2D Particle Systems: defined through Sprites, interacts with 2D physics
  
• Bullets defined through simple GameObjects and Prefabs.
• Complex bullet patterns are easily created using only the Editor
  
• Open Source: it's 100% free! Licensed under the MIT license.

I'll add more information as more stuff is implemented completely.

DanmakU is currently in an early alpha stage, but the core system of controlling particle systems is more or less in place, and is more or less usable now. Just be warned that there is currently not much up-to-date documentation, and there may be bugs.

Screenshots:

 

Pretty great work and free to boot, awesome, thank you!

PS What's the Phantasmagoria version about?

 

I'm going to be up front about this: I am a hobbyist game developer, nothing more, and one subset of my pet projects are Touhou Project fangames.

The Phantasmagoria package is a (currently half-finished) set of scripts to make it easier to make games similar to that of Touhou Phantasmagoria of Flower View and Touhou Phantasmagoria of Dim Dream. They're essentially 2P versus bullet hells.

The second screenshot above is from a project I was working on that utilized it heavily.

Some gameplay examples from said games:

 

Intense!

 

I have not actually tried the system yet (I will when I reach home).
I am really excited for this system, and can't wait to know a lot of things!

The hit box of the bullet is sprite-based correct?
Can the system have a different hit box from its sprite? (I notice some Touhou bullet hit boxes are smaller than their actual sprites, or have a different actual shape than the actual sprite.)

I am also thinking of invisible bullets, to use 3D special effects that actually hits the players.

Does the system readily supports lasers?

Will the 2P system be entirely based on Phantasmagoria of Flower View?

Because the system from that game does not actually compensate any de-syncronizations between clients.
(Sometimes the client experience other things than the other clients, even on LAN.)
(It is much worse through the internet)

So I am thinking there should be a way to both do Client-Client and Client-Server-Client model for multiplayer support.

 

Keep in mind this is still an alpha. There are a lot of things broken right now.

The way to currently define bullets is using Danmaku Prefabs, which are exactly what they sound like: Prefabs for Bullets. You attach the script for it to the Prefab, then provide a 2D Collider (Currently only Circle Colliders are supported, Box Colliders are planned, Edge and Polygon Colliders probably are a no go, purely for the sake of performance), and a Renderer (currently only Sprite Renderers and Mesh Renderers are supported), and then you give the Danmaku Prefab as a reference to the Fire functions, and the system will handle the rest. This way, other than the constraints on the collider types available, you can customize everything about how a bullet looks and behaves.

Bullets can be moved with a multitude of DanmakuControllers, which are delegates used to parametrically control the behavior of groups of bullets. Each bullet can have more than one controller, and each controller can control multiple bullets if need be. Thanks to the Vexe Framework, which DanmakU depends on, there exists a way to serialize these delegates and its interface equivalent IDanmakuController.

An example would be the AccelerationController, which gradually speeds up or slows down a bullet over time. AccelerationController implements IDanmakuController and has it's own serialized parameters which are used to determine the actual change in velocity. Or HomingController, which makes bullets constantly home in on the player. You can put both on a bullet and make it speed up as it follows the player(s) around.

Example of 3D bullets (only in the latest few commits of in the repo, the latest release does not have these yet):


You can create invisible bullets by simply providing a Renderer that has nothing to render (i.e. no mesh or no sprite).

Lasers are currently the biggest item on my issues/todo list. I'll add them in when I can find an elegant solution that works well with the dev kit.

The Phantasmagoria package will largely be based on PoFV and PoDD, yes. However, that does not mean you cannot make your own 2P bullet hell. I purposely made this dev kit VERY extendable. I have a large number of abstract classes and interfaces that are widely used thoughout the system, and you can definitely script your own components: down to the game controller script itself. Virtually everything is customizable: the only thing that I am "sealing away" is the core bullet processing system, and, even then, there are ways of adding functionality to that as well.

Networking support for Phantasmagoria style games is planned, but is really far down the line. For now everything is local.

All of this will be thoroughly documented, I just haven't had the time yet. (I'm a college student currently in finals season.)

 

This looks great! And its free. I have looked into other packages on the Asset Store for this type of system, but as this is free its being pushed to the top of my list

 

This looks awesomesauce. I will definitely have to download/play with it when I get a chance. Keep it up!

 

Currently, please note that the only way to fire bullets is through scripting. There used to be a way to easily get these set up with only pre-created scripts, but I've since scrapped that in favor of a more versatile system.

I'll be pushing more documentation over the next few days or so to clean up and and make the code more usable.

 

I noticed the documentation page went missing.

 

i find this very fascinating and i have a similar need for a prototype

i personally am looking at abstracting the bullet boxes, tracking a sort of large circle collision, then sub-tracking smaller ones inside the circle

i might ignore the subdivision but i am fairly sure i will have to be using call sphere collision with the physics all the time. Is yours designed similar?


the real thing to think about is the ROTMG netcode , a strategy for sending patterns down the network, a HUGE can of worms

 

sorry to try and resurrect a thread, I have my own framework that I try to encompass all designs in (mostly top down 2.5D style)

as you pointed out for me to do bullet hell style behaviours, I would end up with multiple gameobjects (BUT I do have a successful, GLOBAL, pooling system (not attached to one script but literally passing all units around a cycle as per identity)

When I finally did that I experienced a real massive speedup.


Could I ask, why will my system exactly fall short here, what was the strategy? So I make a guess I need all my bullets to be rigid-bodies, yours are down as sphere casts? Is it something like the units need to be rigidbodies and the collisions is now abstracted as collision checks?

I'd also be open to releasing the source of my framework (non-gameplay design elements), but I fear it's a bit messy

 

I get:

Just another broken Unity Danmaku project.

 

This is really awesome project sir ! Thanks for sharing this
But I have a problem here. The colliders script doesn't detect any bullet that I already attached the collider2D to it.
Can anyone please help me solve this problem please ? Thanks before !

 

I originally designed this package way back when I was a uni student, and due to incompatible changes in Unity's particle system API, it has since fallen into disrepair.

I'm working on a fresh start for the package as of two weeks ago. Please check the "develop" branch on Github for the initial implementation.

Please see here for more information: https://github.com/james7132/DanmakU/issues/28

 

Nice work!
How does this compare to https://www.assetstore.unity3d.com/en/#!/content/19088 ?

 

The package is effectively defunct. The original implementation was created for Unity 5.2 and hasn't been updated.

I've also been busy with other work and haven't had the time to reimplement the package.

The develop branch on Github has a marginally operative package that should work in 2017.x+. However it has neither the breadth nor performance of the original implementation.

 

Hi,
I just created this account to thank you for all your efforts and the work you have put into this project. In the last couple of months, I was really into the idea of making games and especially bullet-hell games. And I wasn't sure if this thread is still active or not, but when I saw the recent posts, I was hoping again. As soon as I get to play around with it, I can hopefully give some useful feedback or even contribute a little bit myself.

-Els3

 

So, is this project dead ? Can it be used for other games ? I mean, is it in any working state right now ? Thanks.

 

I'm pretty inexperienced but wanted to have a play around with it, but I'm having some issues importing the assets. Gives me some errors about code no longer being valid because C# updated or something.

 

Your excellent work just save my life bro
Respect