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. )
Yes and no, Unity has been running a custom version of Mono, an open source .NET (and C# implementation) which as of now technically is only compliant, as a whole, with the .NET 2.0 standards; however some parts of the standard library of .NET 3.5 some newer. A good example is LINQ, which wasn't added until 3.5 (I think), works just fine on Unity projects.
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.
Unless I write my own scripting language for it, no. However, manual recompilation time is almost nonexistent in Unity anyway, since the Editor automatically recompiles and updates code every time you hit the "Play" button. Also, a big habit I see in other scripted danmaku systems is to hard-code the values into the text files itself. While you can do that in Unity, there are better ways. Unity's editor is built around editor to runtime serialization of values, so if you declare your instance variables correctly in the C# class, it will be exposed in the Unity editor as a changeable value. For example, the following code:
using UnityEngine;
public class EditorExample : MonoBehaviour {
// Public variables are automatically serialized
public int integerVariable = 42;
// Non-public variables are by default not serialized
private string nonSerializedString;
// Private/Protected/Internal variables annotated with the SerializeField can be forced to be serialized
[SerializeField]
private string stringVariable = "Hello World";
}
Makes this show up in the Editor:
Those fields are editable, and will change the actual initial values stored in those variables for that instance of EditorExample. Editing these values does not require recompilation since it doesn't actually change code, so the focus on coding is more about setting up the structure and general logic than it is about entering in everything from the data to the logic behind it all, which is very nice. Back when I started game dev with XNA, editing values through changing code or creating my data management system was a giant pain. These variables have nothing changed about them, so you can do virtually anything with the variables and values that you could normally do with them in C#.
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.
Yes, and no. It was definitely running with the collision code on and was fired from relatively complex nested coroutine. I didn't have anything like player movement or score counting, but both of those aren't particularly computationally expensive. The main draw on performance isn't checking for collisions, Unity handles that very well, but rather invoking the events for handling how they respond to a collision, which isn't called unless an actual collision occurs. In the scene at the time of testing, I had about 25 colliders (Unity object components that define a collision area for an object) that could interact with DanmakU bullets. The secret is in the fine details: in DanmakU, bullets only consider collisions with Unity based colliders, which basically means that bullet to bullet collision is never calculated or checked. A big difference between DanmakU and other danmaku engines is that rendering is fully multithreaded thanks to Unity's particle system. Also, as weird as it sounds, DanmakU's rendering also works faster since it's based on 3D meshes, not 2D sprites (Unity turns 2D sprites into 3D meshes with vertex UVs mapped to points on the original spritesheet), which alters the workload from rotating entire textures (matrix multiplication on every pixel on the CPU) to rotating meshes (matrix multiplication on every vertex on the GPU), the latter tends to work much better, even on integrated cards, since GPUs have specialized matrix multiplication hardware and are in general highly parallelized to handle large data inputs.
