james7132's DanmakU Development Kit for Unity Alpha v0.6.0

[james7132]

Sup y'all. Been working on a lot of Touhou stuff, but never bothered to post them here:

This information is OUTDATED. It will be updated soon. Please wait warmly!

DanmakU Alpha v0.6.0
DanmakU is an open source, generalized, high performance, and lightweight development kit and library for 2D danmaku games in Unity based on Danmakufu.

I thought that Danmakufu was a bit restrictive in some of it's uses, and since it's not completely open source, I couldn't make changes to parts that were irking me, so I made my own danmaku dev kit.

Features:

• Has access to all other Unity features: deploy to multiple platforms, GPU acceleration, etc.
• Interacts well with all 2D Unity objects.
• Written in Momo C#, entirely object oriented.
• Very high performance - was able to get 20,000 bullets moving and rendering at near 60fps on my desktop.
• Lightweight - 20,000 bullets added only 30-50MB of allocated RAM. Runs decent on mobile devices.
• Open source: anyone is open to edit the code, push changes as they wish.

Planned Features (in order by priority):

• More documentation and video tutorials
• Lasers (yeah, haven't implemented them yet.)
• More Extension packages to make other parts of Danmaku game dev easier

Currently in an alpha state. There are a number of large bugs that I need to squash. If you find any bugs, don't post them here, list them under the github issue tracker: found here.

This project is open source under the MIT license. It used to be GPL, but now you don't need to open source your works using it, so it can be used easily, even in commercial applications, if you are so inclined.

At it's core DanmakU is a simple package that allows for creating and manipulating large numbers of similar objects that need to rendered, moved, and have collision checks made. The traditional Unity way of creating a GameObject and adding functionality via attached scripts/components carries far too much overhead since they were more intended for general purpose systems. DanmakU provides an interface for quickly and efficiently creating and controlling hundreds of generic objects. These objects, while less dynamic than traditional GameObjects, are very lightweight, yet still contains support for rendering, bullet collision, and basic physics. These generic objects, for lack of a better name, are simply referred to as Danmaku, Since there is no specific function other than to work as generic manipulable objects, they can be used for a variety of purposes: be it bullets, item pickups, special effects, etc.

Each Danmaku has several parts:

• Sprite - This is the sprite used to display the Danmaku object.*
• Color - the vertex color of the bullet. This allows a single grayscale sprite to create a variety
• Material - this is used to affect exactly how the bullets of a certain type are rendered. Contains shader information.*
• Position - a 2D Vector position in absolute world coordinates of where the Danmaku object currently is.
• Rotation - a floating point value to describe which way the bullet is currently facing. Measured in degrees.
• Scale - allows the bullet to be scaled to different sizes.
• Speed - linear speed.  The number of units traveled in the direction the object is currently facing over the period of one second. **
• Angular Speed - The number of degrees the object will rotate in one second. Setting this to positive = turn to the right, negative = to the left. **
• Collider Information - different collider types can be applied to each bullet, and used to handle collision detection.

* - shared information, changing this value will change it for all bullets of that type.
** - One "game second" which can vary depending on a number of settings.

DanmakU's core package is purely focused providing a usable code interface for spawning, controlling, and handling collisions with these Danmaku objects. There are several key components:

Danmaku Prefabs


This is the way to create bullet/object types in DanmakU. This part requires zero coding, but will be required to spawn any bullets/objects, instead these prefabs are easily made in the Unity Editor. They are your standard Unity Prefabs, but have a renderer and the Danmaku Prefab script attached. From here it is easy to manipulate how the object looks and behaves. The way the object looks in the scene view is exactly as how they will look when spawned using DanmakU functions. Tweaking the renderer functions will act exactly as one would normally expect.

On the actual Danmaku Prefab script, the dev can tweak several options:

• Danmaku System Prefab - the underlying Shuriken Particle System used to spawn bullets created from this prefab. For the most part, the default value provided works just fine and doesn't need to be changed.
• Collision Type, Collider Size, Collider Offset - Information pertaining to how collisions are handled. The collider for the bullet can be seen drawn in a green line in the scene view. In the above example, it is the green circle superimposed on top of the sprite.
• Fixed Angle - when moving objects spawned from this prefab, will they rotate visually? Can be useful for item drops or other similar object types.
• Extra Controllers  - additional Danmaku Controllers (see below) that affect the behavior of the objects spawned by the prefab

If the scale is adjusted on the prefab's Transform, the resultant spawned objects will also inherit the same scale changes.

Lastly, make sure to save this object as a prefab in the project, not a object in the scene. I only made these GameObjects and not ScriptableObjects because it is easier to visualize in both the scene view and in the project view. Danmaku Prefabs are for data use only!

Danmaku Controllers

Danmaku Controllers are a parametric, compositable, and high performance way of expanding bullet functionality. Each Danmaku can have multiple controllers, and each Danmaku Controller can control multiple Danmaku objects. To apply the behavior associated with a controller to Danmaku object(s), use the AddController functions, to remove them, use the RemoveController. Alternatively one can create a concrete class that implement the IDanmakuController interface which ensures compatibilty with Danmaku Controller functionality.

Examples of Danmaku Controllers:

• Acceleration Controller - Speeds up or slows down objects affected by it by a specified acceleration value.
• Speed Limit Controller - limits the speed of objects affected by it. Preventing them from moving faster or slower than a specified limit
• Color Change Controller - changes the color of the objects affected by it. Some examples of use include creating bullets that undergo a gradient color change
• Homing Controller - forces the object to always face and move toward a specified GameObject
• Speed Curve Controller - changes the speed of the object based on an Animation Curve. Allows for fairly complex control over the movement affected objects.

More information can be found on the Github repo/wiki, found here.
For Danmakufu Users:

• A quick rundown of the basic differences between Danmakufu and DanmakuU
• Function mapping (similar functions)

Example Images:


Public video tutorials will come as soon as the beta is ready for public release. 

TouhouBots
Just a bunch of bots for the Touhou subreddits on Reddit. Does random things around there.
Github link[/list]

[gtbot]

• Built in support for Phantasmagoria style games.

Sweet, I'm definitely going to check this out 

[james7132]

Sweet, I'm definitely going to check this out 

Take it with a grain of salt. It's still really buggy, since I haven't tested all the use-cases out yet.

[Jonath]

Okay, I tried to use it a bit. There are good ideas (projectile groups, pooling for instance) but it's a bit hard to understand everything as there are a lot of interfaces and abstract classes. Also, several of your implementations (such as LinearProjectile, CurvedProjectile) could be summed up by a unique class.

Also, I see you are only considering CircleCollider2D for projectiles which is a bit minimalist. For several cases, I would like to use BoxCollider2D (or even PolygonCollider2D). For what I see, they are only used as a way to manipulate a prefab (because I assume they are too heavy for a danmaku game ?). What if I want to use Yumemi's cross ? Or Sakuya's knife ? My main problem with your work actually is here : I have trouble understanding the Update loop of the Projectile class (I admit I'm not an Unity pro myself though).

Your coroutines are interesting, but I would change MainLoop to be a coroutine, as it is in danmakufu, so that you can have more control over the flow. Also, I see you are using clocks in some of your examples. The danmakufu way to "wait for a bit" I have seen in scripts is to call a yield (until next frame) in a for loop (Which might end up being ugly as you don't have extensive macros in C# to replace a for loop with a wait instruction). The unit of time used is likely to be the frame.

Also, I usually end up using the same "structure" for my ennemies or even the player that I use to move bullets around (speed, angle, angular velocity, acceleration, cap), because it allows me to avoid having to write code for each case, and I can transform an enemy into a bullet / a bullet into an item easily. That's a preference I guess.... In a perfect world, you might even need a pool for enemies or at least items (as bullet cancel can lead to them converting into points).

I'm happy to see someone finally doing stuff on Unity though. I feel Danmakufu is a bit restricting as it is a bit hard to implement 3D backgrounds properly. I hope that my remarks will help you. Also, I think you should make tutorials in order for everyone here to understand how to set up the project properly in Unity, and make some examples (If you have the time for it, obviously).

Have a good day sir.

[james7132]

Thanks for trying it out! A side question to this, did you find the documentation hard to use? I tried my best to keep the documentation nice and neat.

Okay, I tried to use it a bit. There are good ideas (projectile groups, pooling for instance) but it's a bit hard to understand everything as there are a lot of interfaces and abstract classes.

There are indeed a lot of interfaces and abstract classes. I wanted to minimalize the number of restrictions applied to other scripters/developers when working with the kit, so the indeed the heavy use of polymorphism and inheritance is a design choice of mine. It's also a habit of mine: coming from a primarily software engineering oriented background. The large number of already implemented subclasses should provide a sufficient choice for developers to choose from, but should the option they are looking for not exist, they can make their own by implementing the aforementioned interfaces/abstract classes.

Also, several of your implementations (such as LinearProjectile, CurvedProjectile) could be summed up by a unique class.

Angular velocity calculations are expensive when you have 5,000+ objects doing it each frame. So if bullets that are intended to go straight throughout it's entire lifetime, it's best not to do the calculations, even the check to see if angular velocity is 0, if it is not needed. Only use CurvedProjectile if you know there's a possibility if it will curve in the future. Of course, you can always just use CurvedProjectiles and not need to worry about it later, but LinearProjectile serves as a nice way to optimize a laggy spellcard/attack pattern.

Also, I see you are only considering CircleCollider2D for projectiles which is a bit minimalist. For several cases, I would like to use BoxCollider2D (or even PolygonCollider2D). For what I see, they are only used as a way to manipulate a prefab (because I assume they are too heavy for a danmaku game ?). What if I want to use Yumemi's cross ? Or Sakuya's knife ? My main problem with your work actually is here : I have trouble understanding the Update loop of the Projectile class (I admit I'm not an Unity pro myself though).

Attaching colliders/rigidbodies to Projectiles has an unbelievable overhead in both computation time and memory usage. I tried it as a method and subsequently lagged out to 15fps at only 300 bullets. The CircleCollider2D is only added to ProjectilePrefabs as a way to define the hitbox visually for the developer (it's easier than hand doing it). The data is hand-copied to the Projectile, which manually does collision detection via function calls in it's Update function. I'll add BoxColliders to the task list to incorporate. PolygonColliders are out of the question unless I put a hard cap on how many it can spawn. The development kit does not stop the developer from making their own objects of their own. You could make a custom object that isn't a Projectile that handles collisions by looking for the player's death hitbox. The main issue would be constructing/destructing the GameObject at the appropriate time and quantity. Something of enormous size and limited quantity, like the Master Spark or Utsuho's massive shots, can be handled easily in such a fashion, as opposed to using a huge laser or bullet.

Your coroutines are interesting, but I would change MainLoop to be a coroutine, as it is in danmakufu, so that you can have more control over the flow. Also, I see you are using clocks in some of your examples. The danmakufu way to "wait for a bit" I have seen in scripts is to call a yield (until next frame) in a for loop (Which might end up being ugly as you don't have extensive macros in C# to replace a for loop with a wait instruction). The unit of time used is likely to be the frame.

Good point. I could definitely change MainLoop to a coroutine. I'll even add a "WaitForXFrames" call to make calls look a bit nicer. The one caveat is that "WaitForEndOfFrame" (the standard yield for one frame call) allows the coroutine to run, even when the game is paused (since the engine is still rendering frames to the screen while paused), which is why I didn't initially make MainLoop a coroutine, but I think with the proper availability of better calls, it shouldn't be too much of a problem.  The final issue is the overhead of starting coroutines in Unity is quite large, so I should probably caution against the excessive use of nested tasks.

Also, I usually end up using the same "structure" for my ennemies or even the player that I use to move bullets around (speed, angle, angular velocity, acceleration, cap), because it allows me to avoid having to write code for each case, and I can transform an enemy into a bullet / a bullet into an item easily. That's a preference I guess.... In a perfect world, you might even need a pool for enemies or at least items (as bullet cancel can lead to them converting into points).

Enemies, so long as they aren't spawning in hordes of 100 per frame, shouldn't be all too much of an issue. Projectiles and Items are planned to be interchangeable (they'll have the same underlying data structure). To which, I still need to implement items.

I'm happy to see someone finally doing stuff on Unity though. I feel Danmakufu is a bit restricting as it is a bit hard to implement 3D backgrounds properly. I hope that my remarks will help you. Also, I think you should make tutorials in order for everyone here to understand how to set up the project properly in Unity, and make some examples (If you have the time for it, obviously).

It it's for similar reasons why I decided to make this: Danmakufu is a bit restricting in a number of ways, the 3D camera being one of the lesser items that felt too restrictive. Regarding the 3D camera, I already have support for custom scriptable 3D cameras in one of the unstable branches in my local repo. Since the engine was originally oriented toward making 3D games, making 3D backgrounds is rather easy with Unity and a few mesh editing tools.

Currently, the dev kit is in completely unstable early alpha. When I at least enter a stable beta or fully release the dev kit, I'll add full documentation. I'll also be using it to develop "Phantasmagoria All Stars" (tentative name), a PoFV clone/expansion with more characters than before, and I plan on making a "Let's Develop" series which will serve as a functional tutorial on how to make a full danmaku game using the kit.

[GhoulMage]

Whoa,

There are more people than me creating danmaku engines for Unity 3D :O.

I didn't try this because I'm busy making my own , but I could give it a try someday.
But I inspected the git repo a little and I saw that you're rendering the bullets one by one, using a SpriteRenderer. Unity can batch those for you automatically, but not always. I suggest you to "batch" the sprites manually to a mesh renderer by material (normal bullets, additive bullets, etc)... It has a pretty nice perfomance (a bit tricky, though). Also you can edit the vertices of the "manual batched" objects for special effects, like curvy lasers, easily.

[james7132]

The one good thing about using SpriteRenderers is the ability to change the color of a bullet on the spot without needing to incur any allocation for the creation of new Materials. If there's a way to circumvent that with something like MaterialPropertyBlocks instead, I may try it.  It would get rid of the overhead of using GameObjects, Transforms, and SpriteRenderers as the underlying backend behind each bullet, but I'm wary of needing to manually manage them individually, especially considering I would need to use dynamic data structures to handle them: I would need to switch to either some generic Enumerable collection instead of a standard array, which incurs a lot of overhead when iterating over thousands of bullets.

The current setup is a single array with all bullets pooled (both inactive and active alike). Each Danmaku is essentially a wrapper object around an underlying GameObject with a Transform and SpriteRenderer. All the collision and all other behavior is defined using dependency injection via interfaces and delegates. When a bullet is deleted, I just turn off the renderer.

Some profiling shows that a lot of the  time spent is used setting the Transform position and rotation and a large number of other functions, so that's one reason why I may consider making such a change.

In other news, I'm nearing a full beta release state. I'm actively working on a very powerful script-free way to make danmaku patterns that integrates well with scripting. My hopes is that this system can get more people into making Touhou/danmaku games, as well as make it much easier for existing scripters to create very complex patterns without needing to touch even a single line of code: so that you can focus on working on the more unique parts of your spell cards/projects.

A quick rundown of the current basic object structure:

• Danmaku Triggers - these are event driven triggers for when to fire bullets.  Inheritable/Polymorphic: you can define your own.
• Danmaku Sources - these are where the bullets are fired. Inheritable/Polymorphic: you can define your own. Each time a Danmaku Emitter fires one bullet, All subsources of a Danmaku source fires one bullet.
• Danmaku Emitters - defines general behavior/shape of the bullets fired at each source.
• Fire Modifiers - By default Danmaku Emitters fires only one bullet per trigger, Fire Modifiers modularly expand the pattern of bullets fired in a single fire.
• Danmaku Controllers - Dynamic parametric behavior modifiers that affect bullets after they are fired.

[GhoulMage]

The one good thing about using SpriteRenderers is the ability to change the color of a bullet on the spot without needing to incur any allocation for the creation of new Materials. If there's a way to circumvent that with something like MaterialPropertyBlocks instead, I may try it.  It would get rid of the overhead of using GameObjects, Transforms, and SpriteRenderers as the underlying backend behind each bullet, but I'm wary of needing to manually manage them individually, especially considering I would need to use dynamic data structures to handle them: I would need to switch to either some generic Enumerable collection instead of a standard array, which incurs a lot of overhead when iterating over thousands of bullets.

The current setup is a single array with all bullets pooled (both inactive and active alike). Each Danmaku is essentially a wrapper object around an underlying GameObject with a Transform and SpriteRenderer. All the collision and all other behavior is defined using dependency injection via interfaces and delegates. When a bullet is deleted, I just turn off the renderer.

Some profiling shows that a lot of the  time spent is used setting the Transform position and rotation and a large number of other functions, so that's one reason why I may consider making such a change.

In other news, I'm nearing a full beta release state. I'm actively working on a very powerful script-free way to make danmaku patterns that integrates well with scripting. My hopes is that this system can get more people into making Touhou/danmaku games, as well as make it much easier for existing scripters to create very complex patterns without needing to touch even a single line of code: so that you can focus on working on the more unique parts of your spell cards/projects.

A quick rundown of the current basic object structure:

• Danmaku Triggers - these are event driven triggers for when to fire bullets.  Inheritable/Polymorphic: you can define your own.
• Danmaku Sources - these are where the bullets are fired. Inheritable/Polymorphic: you can define your own. Each time a Danmaku Emitter fires one bullet, All subsources of a Danmaku source fires one bullet.
• Danmaku Emitters - defines general behavior/shape of the bullets fired at each source.
• Fire Modifiers - By default Danmaku Emitters fires only one bullet per trigger, Fire Modifiers modularly expand the pattern of bullets fired in a single fire.
• Danmaku Controllers - Dynamic parametric behavior modifiers that affect bullets after they are fired.

Yay, I am also making a danmaku engine because I want the people to get into making danmaku games more easily .

About the change color of a sprite, I have a "RenderObject" for each type of sprite in the game. When some sprite needs tinting, I set "enableTinting = true;" for the equivalent RenderObject and the next frame the RenderObject will have tinting enabled. To tint individual sprites I set the necesary vertex colors to the necesary tint color. It works and I don't instantiate any Material! But it does require a shader that has Vertex Color enabled.

The Transform-property-change cost is because a underlying Matrix4x4 struct needs to be updated on each Sprite every time a property of it changes. It lags on me very badly (on a netbook), but in my RenderObject I call a Matrix4x4.SetTRS function for each required sprite every frame and it doesn't lag :/.

And, I'd love to see a "script-free way to make danmaku patterns". I did try to make a similar thing on my own a few months ago but it quickly got too complex to continue working on...

Btw... can I borrow some of your ideas?

[james7132]

Btw... can I borrow some of your ideas?

NO, YOU MAY ABSOLUTELY NOT. MY IDEAS ARE MINE AND MINE ONLY!! HMMMPFFF!

Nah, seriously, it's open source GNU Public Licensed code: you can do (almost) anything you want with it, including directly copying the code itself, with a few caveats, of course.

[GhoulMage]

NO, YOU MAY ABSOLUTELY NOT. MY IDEAS ARE MINE AND MINE ONLY!! HMMMPFFF!

Nah, seriously, it's open source GNU Public Licensed code: you can do (almost) anything you want with it, including directly copying the code itself, with a few caveats, of course.

Well, I want my code to have a Creative Commons BY-SA License... Don't really know if it's compatible

[Jonath]

Okay, I have been trying again your library after some of the recent changes. The enemy movement motion works fine but you may want to remove the call to movementPattern.DestroyOnEnd = true; in your BasicEnemy class.

For the collision between several bullets, you could use a Quadtree working with the danmaku projectile AABB but they are a bit expensive. One could also use your ProjectileBoundary class as a roundabout, and try limiting the concerned bullets as much as possible. You are still using Unity2D colliders for most of your objects (bullets excepted), but what about writing your own classes for that ? I know it's tough, but you might end up with another part for UnityUtilLib. I'm not talking about weird colliders, but rather reusable ones (and the code for Circle collision is almost ready isn't it ?).

I'm very interested in the way you've made all your optimisations. I have been trying to get rid of any bottlenecks in my own projects for a while and usually my performances would become bad quickly. I still feel enemies should be handled as bullets though. Think about it,  I had this idea of a boss firing objects that would turn into tsukumogamis firing stuff of their own. For that an enemy pools, and enemies with colliders of the same nature than bullets would be perfect, isn't it ? (I hope genericity is possible while still achieving your performances).

I see you're using delegates now, good ! We're still missing items, lasers and some other stuff but they are improvements. I think you have a solid backbone for a danmaku right now, I hope to see a demo very soon.

Congrats ^^

[james7132]

Well, I want my code to have a Creative Commons BY-SA License... Don't really know if it's compatible

Ummmm... I have never heard of code being licensed under Creative Commons, maybe the assets for a game, but not the code. CC generally does not handle the logistics of handling code very well. The GPL terms are simple as this: if you redistribute anything made with GPL software, you must also make your code available under the GPL license. Note this says "make available", not "release", so long as people can get to your source code by some manner, it's fine. Outside of that, free use and distribution is allowed so long as you keep the original's License Agreement and Copyright Notice included with anything created with it.

Some research into it shows that the two are supposedly mixable to a degree. I would advise looking up some more information on the topic.

Okay, I have been trying again your library after some of the recent changes. The enemy movement motion works fine but you may want to remove the call to movementPattern.DestroyOnEnd = true; in your BasicEnemy class.

For the collision between several bullets, you could use a Quadtree working with the danmaku projectile AABB but they are a bit expensive. One could also use your ProjectileBoundary class as a roundabout, and try limiting the concerned bullets as much as possible. You are still using Unity2D colliders for most of your objects (bullets excepted), but what about writing your own classes for that ? I know it's tough, but you might end up with another part for UnityUtilLib. I'm not talking about weird colliders, but rather reusable ones (and the code for Circle collision is almost ready isn't it ?).

I'm very interested in the way you've made all your optimisations. I have been trying to get rid of any bottlenecks in my own projects for a while and usually my performances would become bad quickly. I still feel enemies should be handled as bullets though. Think about it,  I had this idea of a boss firing objects that would turn into tsukumogamis firing stuff of their own. For that an enemy pools, and enemies with colliders of the same nature than bullets would be perfect, isn't it ? (I hope genericity is possible while still achieving your performances).

I see you're using delegates now, good ! We're still missing items, lasers and some other stuff but they are improvements. I think you have a solid backbone for a danmaku right now, I hope to see a demo very soon.

Congrats ^^

As for Bullet to Bullet collision detection, I am working under the assumption that no sane danmaku developer would allow rapidly created and fast moving bullets created by the player to need to collide with enemy bullets: the runtime for such collision detection is absurd to keep under 60fps. For example, Reimu's Fantasy Seal can be created with moving colliders with ProjectileBoundary attached, instantiated via Instantiate().

I'm not actually using colliders for bullets (it's too much overhead). I just used Circle Colliders on Danmaku Prefabs to make it easier to define a bullet visually in the Editor, but the actual backend manually uses Physics calls based on the stored data to check for collisions with bullets. This reduces the memory footprint by several orders of magnitude, and is in general very efficient. No actual colliders are attached to any of the bullets. Each bullet, with respect to the Unity system itself, is a GameObject with a Sprite Renderer and Transform. All collision handling and movement is handled via a Danmaku object which is updated via the DanmakuGameController.

Good suggestion on the Quadtree + AABB though, I could use it to further reduce the number of collision detections checks made per frame.

You are right with regards to the enemy handling.  I'll be rewriting most of that code, since most of it was hacked together to get it to work spontaneously for another project using it. I won't go as far as to make pools for enemies. Items and Danmaku may be pooled due to the high spawn rate of them and overall simplicity and general similarity with each other, but enemies generally don't spawn in 10s-100s at a time and many of them have large amounts of unshared behavior and support for attaching standard MonoBehaviors and custom scripts is very useful with regard to them.

The use of delegates only slightly impacted performance. It works wonderful when it's a single delegate, but when you move to multicast delegates there's a decent amount of overhead incurred, which is OK since more complex compound behavior should require a bit more computational overhead to manage it all.

I'll probably make a demo once I've added lasers and refined enemies, which will probably be in the initial beta release.

[GhoulMage]

Ummmm... I have never heard of code being licensed under Creative Commons, maybe the assets for a game, but not the code. CC generally does not handle the logistics of handling code very well. The GPL terms are simple as this: if you redistribute anything made with GPL software, you must also make your code available under the GPL license. Note this says "make available", not "release", so long as people can get to your source code by some manner, it's fine. Outside of that, free use and distribution is allowed so long as you keep the original's License Agreement and Copyright Notice included with anything created with it.

Some research into it shows that the two are supposedly mixable to a degree. I would advise looking up some more information on the topic.

Hm... in a certain way, BY-SA and GPL are the same? Months ago I searched info about this topic but it's so complicated to understand... Maybe I will change the license for my code...
Also, I don't understand in your code how you do collisions :/

_{Shhh, this is a secret: We are not the only ones that are making danmaku code for Unity...}

[Jonath]

You know, I know very well you are not using Unity Colliders for projectiles and only using them on prefabs ^^
I was just saying you could do the same with quite a lot of other stuff, and put the code for the physics code inside classes !

[james7132]

Hm... in a certain way, BY-SA and GPL are the same? Months ago I searched info about this topic but it's so complicated to understand... Maybe I will change the license for my code...
Also, I don't understand in your code how you do collisions :/

_{Shhh, this is a secret: We are not the only ones that are making danmaku code for Unity...}

If you are talking about how there already exists Danmaku Engine and BulletML assets on the Unity Store, I'm well aware, as well as darkfall's DanmakuX project which is currently open source under MIT (his project is actually where I got the idea for Fire Modifiers from).

The commercial Danmaku Engine and BulletML asset store ones cannot use DanmakuUnity2D's code written under GPL as the Unity Store bans all GPL released code from being released, free or not, on the store.

The CC-BY-SA is more for artistic content, GPL is more for raw code,  and for the most part the terms they describe are more or less the same. When it comes to games, the two tend to come hand in hand.

As for the collision detection, I check for collision with normal 2D Unity coliders with Physics.OverlapCircle, and Physics.CircleCast, they're functionally equivalent to Danmakufu's SetIntersectionCircle and SetIntersectionLine. Each bullet that needs collision checking will check if they moved more than 50% of their collider's size. If they don't OverlapCircle is used. If they do, CircleCast is used. To reduce the memory footprint, I used the NoAlloc version of the collision checking ones, which basically puts the returned results in a pre-allocated array. This reduces the need to allocate memory each frame for collision detection. I then loop through the array and look for implementers of IDanmakuCollider and call the appropriate function call to handle the collision.  I used to use SendMessage as a way to call the functions, but for most cases, the current implementation was over 50 times faster.

You know, I know very well you are not using Unity Colliders for projectiles and only using them on prefabs ^^
I was just saying you could do the same with quite a lot of other stuff, and put the code for the physics code inside classes !

The goal was to keep it integrated well into Unity. Outside of instantiating hundreds/thousands of bullets and items (and a few other small caveats), Unity is fairly well designed for generic game logic.

[james7132]

It's been a while, and I've been hard at work on this project, but I finally am satisfied with this new version.

Alpha v0.5.0 is ready. It simultaneously improved lots of things and broke a lot of things as well. Here's the changelog.

The biggest of the changes that bullets/items no longer use GameObjects to move/render. I successfully was able to mimic SpriteRenderers using Particle Systems, and was able to make it so that individual particles could be controlled.

What does this mean? Performance, absolute ridiculous performance: I got close to 20,000 bullets to both render and move in 60fps on my desktop, and over 10,000 on a mobile phone at 30fps. The Particle System improvement drastically reduced the amount of time Unity used to batch and render most of the bullet geometry, as well as reducing the number of draw calls.



In this image, we have over 20,000 bullets traveling in circular bursts. Approximately 750 are fired every tenth of a second. From the profiler, it is possible to see that, for the most part, we're around 60fps or so. Now note, that the profiler has a large overhead on both computation time and memory usage. In the final build, this scene ran smoothly under 60fps. Also note that the memory allocated statistic there also includes the editor, the profiler itself, and a number of other things to help with purely editing. Over 220 of those 359MB comes from the profiler, ~50MB from the editor. The actual game's usage of memory is under 50MB or so. Fairly lightweight for something that just spawned that many bullets.

What does this mean? This means you can go absolutely crazy with this dev kit. I really doubt you will ever use 20,000 bullets in an actual danmaku game, and I am sure you are going to be running more complex patterns than just this, but this goes to show that this kit is very very high performance without much cost at all.

Unfortunately, I haven't had much time to work on the NoScript system. It will have to wait until the next minor release.

If anyone knows how to handle rendering lasers, please contact me, I am struggling with figuring out how to properly batch large numbers of them.

[Jonath]

Ah, it's nice to see you making progress. Good idea for the particle system. When trying to work on my own engine, I saw about using OpenGL particle system in order to emulate bullets, for performance. I hope this doesn't fell off too fast when you add complex behaviors like angular velocity or change in speed.

Also, looking at your screen captures, are you sorting your sprites ? It looks a bit weird.
For lasers, I would take a look at tries in Danmakufu script (even if when I tried, I couldn't get the logic most of the time). From what I've seen, you can emulate (curvy) lasers with a stream of particles (thus bullets) where the top would have a few frames of advance over the tail (a linked list like structure might help ?). I'm not sure at all though and this is just speculation, also, it might not be very helpful. For straight lasers or growing over time, scaling the sprite should work ? Even if from what I see, you still only have circle colliders though ? (hope I'm not too insistent with this one ^^;). You could also reuse smaller particules instead, and use a "line collider" ?

[james7132]

Ah, it's nice to see you making progress. Good idea for the particle system. When trying to work on my own engine, I saw about using OpenGL particle system in order to emulate bullets, for performance. I hope this doesn't fell off too fast when you add complex behaviors like angular velocity or change in speed.

Switching to particle systems introduced a number of sort of negligible constraints:

• Scaling at runtime is now only one dimensional (i.e. you can no longer stretch the bullet in separate x/y directions, scaling scales all dimensions equally now), but before this update I didn't even expose the scaling of bullets, under the assumption it was static, so that's actually an improvement. You can still scale the bullet in all 3 dimensions (I'm planning on having 3D mesh support for bullets soon) at edit time, and it will retain it's scale ratio on runtime.
• Changing the Material of one bullet, changes the material of all bullets created from that one prefab. Note you can still change the color on individual bullets without affecting the whole.
• You can no longer add Unity components to the bullets, which I actually had in mid-way through this update, but subsequently removed after making this switch. If I decide to re-add option to use the old system, it will be reintroduced.

Other than that, it works wonderfully. The angular velocity and velocity calculations are entirely done by DanmakU scripts, not by Unity itself. The switch to particle systems is merely a change in the processes of rendering the bullets, nothing more. So other than the above constraints, everything is either running as smoothly as it did before, or almost several orders of magnitude more smoother. The fact that Unity naturally multithreads its particle system rendering saves me the trouble of needing to hand do it myself.

Also, looking at your screen captures, are you sorting your sprites ? It looks a bit weird.

Yeah, that's an issue I need to deal with.
It's largely because of the funky way I'm handling particle systems. Unity's sorting mechanic for 2D objects (sorting layers and sorting order) works wonderfully between objects, but it seems that internally, within a single particle system, the ordering algorithm is really funky, and since it's not really documented well, I will simply need to fiddle with it until I can get something that works.

For lasers, I would take a look at tries in Danmakufu script (even if when I tried, I couldn't get the logic most of the time). From what I've seen, you can emulate (curvy) lasers with a stream of particles (thus bullets) where the top would have a few frames of advance over the tail (a linked list like structure might help ?). I'm not sure at all though and this is just speculation, also, it might not be very helpful. For straight lasers or growing over time, scaling the sprite should work ?

Good idea, I'm comparing both Danmakufu's and ZUN's sprites and their actual in-game lasers, and most of what you said sounds pretty close to what I'm seeing. I originally was going to make a custom mesh-renderer (since Unity works best with 3D objects), that extruded extra vertexes each time the direction of the laser changed, but if particle systems work like that, I could probably quickly repurpose my current code to work with lasers.

Even if from what I see, you still only have circle colliders though ? (hope I'm not too insistent with this one ^^;). You could also reuse smaller particules instead, and use a "line collider" ?

It's on my todo list, and like I said before, it's probably only going to be box colliders. The two other colliders can have geometry that can become way too complex for frame to frame calculations on the quantity of bullets being fired. The dev will have to create custom objects for those, special cases, which, all in all, shouldn't be the majority of the bullets fired.

[james7132]

Because it was so easy to do with the existing code base, I also got 3D bullets rendering. All the dev needs to do now is swap out the Sprite Renderer on the prefab with a Mesh Renderer + Mesh Filter, and each bullet it makes will take the form of the mesh used. In this case, I just  used the Unity standard capsule mesh and the standard shader, tinted a nice purple color. 

Note that I am still only using 2D collision detection though. The 3D part is merely for rendering, nothing more.

[james7132]

At the insistent request of Jonath, I've incorporated several new collision options: Box, Line, and Point, and incorporated the hitbox choice inside the Danmaku Prefab itself, so there's no reliance on an actual collider component (this will speed up the instantiation of new bullet types.

I've also made the decision to make no hard distinction for items. The current system is general enough that it should be possible for developers to create their own item types using normal danmaku. (Danmaku in DanmakU doesn't inherently kill players, they are simply high performance ways of spawning and controlling large numbers of objects that have a built in rendering and collision detection functions). By creating custom danmaku controllers and colliders to handle collision. I'll make a seperate tutorial on how to do this when I finalize the core system.

I'll leave lasers for later since I currently can't find a good solution that would work well within the current framework, and instead focus on other standard parts of Touhou games like score handling, improving the enemy spawning mechanics, and actually fleshing out that script-free attack pattern editor.

[Jonath]

At the insistent request of Jonath, I've incorporated several new collision options: Box, Line, and Point, and incorporated the hitbox choice inside the Danmaku Prefab itself, so there's no reliance on an actual collider component (this will speed up the instantiation of new bullet types.

Cool ! I'm definitely going to check this out. I don't have much time these days so I think I'm going to wait for the next release or tutorials ?

I've also made the decision to make no hard distinction for items.

Yay genericity !

Still sad you're hitting a wall with lasers. I'd like to see a kind person giving a generic way to handle the problem, most examples I've seen are pretty hard to understand an people want to keep their ideas for themselves I guess. I hope more people become interested in your project once you start making tutorials. Good luck =)

[GhoulMage]

Lasers, hum.

This is the way I've implemented them. Arrange it for your system.

http://pastebin.com/Kfzq15MN

Dunno if it's the best way tough, but it works .

[james7132]

Been a long long time now. I'm glad to announce that Alpha v0.6.0 is "stable". Here are the basic release notes. There's so much changed I think I probably missed a lot in the notes.

Oh boy are there a lot of changes since Alpha v0.5.0. It almost doesn't look like the same.

I am really REALLY close to a beta/stable release.  I decided to cut out a lot of the extraneous features to focus on a system that makes it easy to fire lots and similar bullets, since virtually everything else is relatively easy to implement in Unity. I seperated out a lot of the old stuff for players/enemies/stages into separate packages being maintained in separate repos. The idea is that if someone is not satisfied with my Player package, for example, they can implement it themselves without needing unnecessary coupling within the DanmakU package itself that would prevent them from using DanmakU. As such, DanmakU's core package is to be super-minimalistic: it will provide functionality to create high performance bullet/laser patterns with built in rendering/collision detection, but nothing more. Adding player characters, enemies, scoring systems, items, etc. can be done by virtually anyone in the manner they choose, or they can choose to use one of the extension packages I will be releasing alongside the core package: your choice.

One of the biggest changes I added is a fluent interface Fire Builder. This is my way of creating easily coded, easily changed, and easy to read code for making complex bullet patterns. For example:

Code: [Select]

public class SourceTest : MonoBehaviour {

[SerializeField]
private FrameCounter delay;

[SerializeField]
private DanmakuPrefab prefab;

[SerializeField]
private CircularBurstModifier circleBurst;

[SerializeField]
private LinearBurstModifier lineBurst;

void Update() {
if(delay.Tick()) {
Danmaku.ConstructFire(prefab)
   .WithModifier(circleBurst)
   .WithModifier(lineBurst)
   .From(this)
   .WithRotation(this)
   .Fire();
}
}

}

Creates these settings:


Which can be tweaked to create this pattern:


I'm going to finish up lasers and call it a finished alpha and put it into beta release. I'll start making video/written tutorials when that is finished.

[james7132]

It's been almost 3 months since I've updated this thread, and only recently got back into working on DanmakU.

The beta version is ALMOST ready. Here's what I've finished so far:

• Danmakufu-esque tasking/coroutine like system.
• Finalized optimizations.
• Debug Features:
  
  • In Scene-View display of the collision boxes for active bullets. In some ways, it's more powerful than Danmakufu's tasking system.
  • A separate inspector window for viewing the at runtime properties of bullets.
• A functional programming based way of constructing bullet patterns.
  
  • A lot of Danmakufu scripts, and game development in general asks how the developer/scripter wants to make something (loops, direct change). The methodology created is more about  what you want to make, instead.

Planned features before release:

• Lasers: I have finally found a good way to make lasers that is relatively high performance. I just need to implement it.
• Emitter Model System: I promised a way to make bullet patterns without coding.  That I will deliver.
• A fullly fleshed out demo project. Was thinking of recreating MoF Stages 2 and 3 for this.

Small demonstration of exactly how the new fluent way of creating bullet patterns is. It is remarkably similar to the way the FireBuilder of previous versions worked, but much less restrained.

Code: [Select]

public class BasicFireTest : MonoBehaviour {

[SerializeField]
private DanmakuPrefab prefab;

    private void Start()
    {
        prefab.Infinite(Modifier.Rotate(5f))  // Create for me an infinite series of bullets, and rotate their firing direction by 5 degrees between each one
              .From(this)                     // Fire all of these bullets from this object's position
              .WithSpeed(5f)                 // I want these bullets to travel at 5 units every second
              .Delay(0.1f)                    // Add a 0.1 second delay between each fire
              .RadialBurst(20)                // Turn each bullet fire into a 20 bullet circle
              .Execute();                     // Execute everything that I said above.
    }
}

The code above creates this pattern:


 As I said above, it's more about what you want, not how. Notice how the code is entirely devoid of any kind of looping, yet it was still able to create a structured pattern of bullets composed of an entire array of different properties.

A sample of the tasking system.

Code: [Select]


void Start()  {
      Hello().Execute();   // Executes the Hello() task.
}

IEnumerable Hello() {  // This is simply the syntax. Create a function that returns IEnumerable and it works.
      int i = 5 + 3;             // Regular code works just fine
      yield return null;    // Yielding a null object will yield the task for one frame
      yield return 20;      // Yielding an integer value will make the task wait for that many frames, in this case, 20 frames.
      yield return 0.5f;   // Yielding a floating point value will make the task wait that many seconds. In this case 0.5 seconds, or 30 frames.
      yield return Helper1();  // YIelding another task will nest the other task inside, waiting for the new task to finish before continuing.
      Helper2(20).Execute();    // This starts a separate Helper() task that this task does not wait on.
       yield return new FireData(); // Yielding FireData objects will bullets created using the parameters set in the FireData object (i.e. position, rotation, speed, angular speed, color, etc.)
}

IEnumerable Helper() {
     FireData fireData = new FireData();
     fireData.Position = new Vector2(20, 30);
     fireData.Speed = 30;
     yield return fireData; // Fires the FireData
     fireData.Rotation += 20; //Edits the FireData object.
     yield return fireData // Fires the edited bullet
     yield return null; // Waits a  frame
     yield return fireData; // Fires it again, a frame later
}

IEnumerable Helper2(int count) {  // Tasks/coroutines can take arguments too
    FireData fireData = new FireData();
    fireData.Color = Color.red;
    for(int i = 0; i < count; i++) {
        fireData.AngularSpeed += 2;
        yield return fireData;                        // Fire "count" bullets with increasing angular speed every time
     }
}


What is cool about this, as opposed to normal Danmakufu tasks or Unity coroutines, is that they can be composed with the above mentioned fluent syntax. For example, changing out Hello().Execute(); with Hello().WithSpeed(20f).Execute(), every bullet fired from the Hello() task will have a speed of 20.

[Failure McFailFace]

I have no idea what's going on.

I don't know C#, only JavaScript, so I don't know how this code works.

... I need to learn C#

[james7132]

It should work with JavaScript too (or in this case UnityScript). Here's the task from before in JavaScript:

(The syntax is much simpler, though the project is currently not setup to support JavaScript or Boo (If you somehow want to work in Boo for whatever reason))

Code: [Select]

#pragma strict

function Start() {
      Hello().Execute();
}

function Hello() {         // This is the syntax. It looks like any old function.
      var i = 5 + 3;             // Regular code works just fine
      yield;                        // Yielding without specifying an object will yield the task for one frame
      yield 20;                  // Yielding an integer value will make the task wait for that many frames, in this case, 20 frames.
      yield 0.5f;               // Yielding a floating point value will make the task wait that many seconds. In this case 0.5 seconds, or 30 frames.
      yield Helper1();      // YIelding another task will nest the other task inside, waiting for the new task to finish before continuing.
      Helper2(20).Execute();    // This starts a separate Helper() task that this task does not wait on.
       yield new FireData(); // Yielding FireData objects will bullets created using the parameters set in the FireData object (i.e. position, rotation, speed, angular speed, color, etc.)
}

function Helper1() {
     var fireData = new FireData();
     fireData.Position = new Vector2(20, 30);
     fireData.Speed = 30;
     yield fireData; // Fires the FireData
     fireData.Rotation += 20; //Edits the FireData object.
     yield fireData // Fires the edited bullet
     yield; // Waits a  frame
     yieldfireData; // Fires it again, a frame later
}

function Helper2(count) {  // Tasks/coroutines can take arguments too
    var fireData = new FireData();
    fireData.Color = Color.red;
    for(var i = 0; i < count; i++) {
        fireData.AngularSpeed += 2;
        yield return fireData;                        // Fire "count" bullets with increasing angular speed every time
     }
}


[Uruwi]

You know what? If this keeps improving I might just scrap my attempt at an engine and just learn C#.

[james7132]

Fluffy, to be fair, I did steal some ideas from your setup, namely use of functional programming in danmaku games. It works very well for setting up complex bullet patterns, but isn't that great for updating fired bullets.

Syntactically C# is not too different from Java. In most senses, if you can do Java, you can do just fine with C#. Though there are a few differences:

• Implicit typing
• Structs
• Delegates
• Iterator blocks
• Properties

It's a small thing that makes code slightly more readable, but otherwise doesn't affect performance or anything: C# has support of implicit typing (not weak typing,, the compiler just infers the type) via the "var" keyword. For example, var i = 0.25; is the same as double i = 0.25;. It works with objects too. var f = new FileStream(); is the same as FileStream f = new FileStream();. Again this isn't like JavaScript's "var" keyword which allows any object of any type to be assigned to it. If we tried, f = "Hello"; after the previous lines, we would get a compiler error saying that we cannot assign/convert a string object into a FileStream object.
Structs are basically the same as C/C++ structs and are passed by value instead of by reference, and are declared with member values and functions.
Delegates are just like C/C++ function pointers, or Python/JavaScript's ability to pass functions as objects, but unlike the aforementioned functional methods, these function pointers are strongly typed. Unlike Java, where lambdas create anonymous classes, lambdas in C# (virtually the same syntax) create anonymous delegates instead.
Iterator blocks are exactly what you see above: functions that don't execute all of their code at once, and can yield execution to some other process before continuing. More info.

Properties are just syntactical sugar. This:

Code: [Select]

...
private int speed;

public void SetSpeed(int speed) { ... }
public int GetSpeed () { ... }
...
is the same as

Code: [Select]

public int Speed {
     get {
        ....
     }
     set {
        ...
     }
}
.
Also the latter can be invoked just like you would a normal variable (i.e. obj.Speed = 5 is the same thing as obj.SetSpeed(5).

Other than that, the same concepts of object oriented programming in Java apply to C# as well.

Under the hood, the main difference is C# is JIT compiled and not run on a VM, so instead of running through a virtual machine methods and classes are compiled literally right before they are used into native code that runs on the physical processsor.

I also recently realized that recent makes it a lot easier to make a Danmakufu to DanmakU converter. I'll add this to my to-do list.

[Failure McFailFace]

It should work with JavaScript too (or in this case UnityScript). Here's the task from before in JavaScript:

(The syntax is much simpler, though the project is currently not setup to support JavaScript or Boo (If you somehow want to work in Boo for whatever reason))

--snip--

Ah, yes. Much better. It's a shame that UnityScript isn't pure JavaScript, though.

Boo (If you somehow want to work in Boo for whatever reason))

From what I can see, Boo is just Python with objects.

...I'll just go learn C#.

[Sage Ω (Ultima)]

Does Unity still use an extremely outdated version of C#? Last I checked it was using an implementation similar to .NET 2.0. (I see a mention of the FileStream class which is weird to use since .NET 4.5 implement the File class that handles streams for you. )

Can danmaku patterns be made post compilation, via a script engine of some kind? (I see Java Script was mentioned) Or does it all require recompilation of source code to work?

I have a complete damaku engine in C# as well via the use of XNA/Mono. Making patterns as apart of the source code is not fun at all, I ended up implementing Lua to cut down on redundant rebuilds.

This looks very interesting though. Also, it says that this engine can handle 20,000 bullets at 60fps. Is this with or without game code? Collision and general logic for heavy stuff. I ask because I was able to pull off 20,000+ as well when I first started, but as more game related code and collision detection logic came into play, that 20,000 quickly became 2500 or so. Significantly less than what I had with just movements and rendering and bullets being probably the only logic being checked.