DanmakU for Danmakufu Users

This is just a quick rundown of the differences between Danmakufu and DanmakU. For differences in scripting, see the Danmakufu Function Mapping

The goal of DanmakU is to create an beginner friendly Danmakufu-alternative that isn't as heavily geared toward scripting, so a lot of what is done in Danmakufu as scripting functions are displaced to more user-friendly components.

##General Unity Differences

• In Danmakufu most positions are dealt with using direct X, Y, Z coordinates and Roll, Pitch, Yaw for rotation. In Unity, position is represented using 2D and 3D Vectors (Vector2 and Vector3. 3D rotation generally uses Quaternions. The engine supports most vector math functions like dot product, cross product, addition, scaling, etc. ###Objects
• Everything that interacts within the game in Unity (not just DanmakU) is represented as a GameObject. These are similar to PH3's objects, but with a few differences.
• GameObjects by themselves contain nothing but 3D position/orientation data in their Transform Component.
• Functionality is added by attaching additional Components.
• Custom scripted functionality is added by user made components via MonoBehaviors, which is essentially embedded C# code that can interact with other attached Components. Also since it's just C# code, it can interact with any standard .NET/Mono constructs. Can also be written in JavaScript or Boo. Though generally advised just to stick with C#.
• When it comes to scripting; however, there is a distinction between Unity Engine objects (GameObjects, Components, Assets, etc), and standard C# objects. Standard C# objects have no direct representation in the game itself, and is largely for data management only.
• This distinction is important as while most of the objects in a DanmakU game is a Unity Engine object, certain others are only represented as a standard C# object, namely all Projectiles or Items.

####Object Rendering

• Renderers are Components added to render objects in certain ways.
  • Sprite Renderers are probably going to be the most commonly used, as they render 2D sprites.
  • Mesh Renderers are likely to be less used, as they are more for 3D objects
• Other renderers like Line Renderers, Trail Renderers, and other rendering options like Particle Systems can be added for more visual effects.

####Object Animation

• Animators are Components that, when used with Animation assets created inside the Unity Editor, can be used to quickly create dynamic animations over a large range of animatable variables. Adding these animations to scripts is usually no more than 3-5 lines of code, and is generally easier for artists/animators to work with than straight scripting.

####Object Collision Detection/Physics

• Colliders are Components that are added to define hitboxes or general. There are both 2D and 3D colliders. DanmakU uses only 2D physics so 3D colliders are generally not advised to be used. Rotating the GameObject via its Transform also rotates the colliders accordingly.
• Multiple colliders can be added for more complex hitbox geometry.
• 2D Circle Colliders define a circular hitbox. Very high performance. Use whenever possible.
• 2D Box Colliders define a rectangular hitbox. Good performance, but should try to avoid using too many of these.
• 2D Polygon Colliders and Edge Colliders are for free form colliders for more complex geometry. Generally speaking, these are very computationally expensive, try to use as few of these as possible.

###Scripting

• C# and Unity are object-oriented, Danmakufu is largely procedural.
• Tasks in PH3 are equivalent to Coroutines in Unity
• Tasks are defined as normal functions, except with a return type of IEnumerator or IEnumerable
• Start one via StartCoroutine(task(parameters...))
• Yielding is more dynamic in Unity than in PH3. yield return <YieldInstruction> is used to yield, where <YieldInstruction> is a subclass of YieldInstruction
• Unity heavily utilizes value serialization. Instead of defining the value in the script itself like let bulletVelocity = 20;, by adding either a public instance variable or forcibly serialized private variable like public bulletVelocity = 20 allows Unity to expose the variable in the Inspector as an editable value. For example, in the image below, all of the variables serialized can be edited directly without editing the underlying script itself. This allows for easy editing/balancing of scripts without needing to recompile/restart the program.

##DanmakU Specific Differences

• In PH3, a shot or item is just like any other object and can be manipulated as such. In DanmakU, for the sake of optimization, shots (Projectiles) and items are normal .NET/Mono objects and do not have the same capabilities that normal Unity GameObjects do. The only editable parameters for each shot is exposed to scripting in by the respective classes.
• For the most part, this simply means you cannot attach additional components to shots or items.
• Shots and Items are not deleted/destroyed, nor created. They are pooled. Instead of deleting a shot, you deactivate it instead. Instead of directly creating a shot, you get one from the Projectile pool instead.
• In Danmakufu there is a distinction between player shots and enemy shots. In DanmakU, there is no built in distinction, you will need to create your own via custom collision settings.

###Collision Detection

• All DanmakU objects only have one circular hitbox. Additional hitboxes cannot be attached. The radius of the circle used and the offset from the centeroid of the bullet can be edited at runtime.
• All DanmakU objects cannot collide with each other. Projectiles cannot collide with other projectiles, items, or any other custom object made by DanmakU. (This does not include any UnityEngine derived components).
• All DanmakU objects can only collide with 2D UnityEngine colliders with an instance of IProjectileCollider attached.
• Unlike Danmakufu, collision detection for DanmakU Projectiles and Items do not need to be set each frame.
• Both Unity and Danmakufu have options for discrete (SetShotIntersectionCircle) and continuous (SetShotIntersectionLine) collision detection. In Danmakufu, you would need to manually choose which one to use with each bullet. In DanmakU, discrete vs continuous collision detection is automatic. If a DanmakU object (Projectile, Items, etc) moves more than half the size of it's collider in one frame, continuous collision detection will be used, otherwise discrete detection will be used.