The Good Small Game Project is still proceeding, in small steps. I have now implemented a step-sequencer in Unity, which uses the AudioClip.PlayScheduled() method, to allow for proper timing of the notes, regardless of the frame timing. The important thing for the game is being able to dynamically change the BPM, and have the sequencer react with as little lag as possible to those changes. And that i could easily swap out the different sequences. So far so good! I have a simple 16 note (4 bars of 4 quarter notes) setup working, with parallel sequences and linear sequences, each containing a number of tracks.
Next step is to experiment with Markov Chains and not L-systems as i had previously considered. I think the Markov Chain approach is better for on-going continuous changes to the output from the previous output. The L-System seemed like you would run it for a couple generations to create a "sequence", and then play that sequence, and then generate a new sequence. Not so much driving what comes next from what has already played. Anyway, we will see, once i get this working.
Also, while looking for something to test the sequencer out on, i found my Funklet book, a kickstarter from 2011. Oi. Amazing, was able to convert the beats into sequences no problem, and was grooving and funking out! Maybe the first practical use of this since i got it! Only took 12 years!
When displaying a players stats, you sometimes want to line up all the stat names, and also line up all the values. This has typically required two text fields, so you can align both of them. This is a bit of a pain in the ass. I found this forum post which explains a clever way to left and right align text in a single text field. You can also use the <line-indent=xxx> in place of the <align=right> to get multiple left-aligned columns of text. Thus saving yourself an extra text field. Bonus points if you are using some kind of binding system, so you can have all the string-formatting in a single place.
I am going to also paste the rich-text formatting here, in case the forum post goes away.
<align=left>This is the left aligned text<line-height=0>
<align=right>5,000<line-height=1em>
<align=left>This is the left aligned text<line-height=0>
<align=right>2,500<line-height=1em>
Have been looking for this C# attribute for a while. In Chronicle (our timeline log tool), i've wanted an easy way to ensure that all calls to it can be removed and ensure no GC or CPU is being used, without having to decorate every call with #IF UNITY_EDITOR or some ugly horrible construction like that. And so we get [Conditional("")], which i can just put on top of all the Log() methods. Sweet!
Doing a project where we have a fixed camera, and the "gun" is quite high off the ground. Then we have targets on the ground, that we would like the gun to be able to shoot. But we don't want to worry about bullet intersecting with the gun or anything between the gun and the target on the ground. So what i did was, create a tall collider and "billboard" it such that it always faces towards the camera. This way, you can aim at the target on the ground, the gun rotates and points in the right direction, the bullets travel in the right direction, and they collide with the object! Looks good, and was very easy to implement. Could be an issue for cases where the target is behind cover or other stuff that should block the shots, but i'll cross those bridges when i get to them.
An interesting bug when using Unity Events... You have created a class with a method like public void MyMethod(), and have a unity event which targets that method. You later decide that the method should be private rather than public. The unity event does not care about the access change, and happily continues to call your, now private, method. Also, it can be very difficult to find what unity event is actually calling your method, making tracking down this kind bug very difficult. A "fix" is to change the name of the method, thus breaking the unity event reference. But that is not ideal. I do not have a solution, other than that the unity events should respect the access modifiers on the methods they are calling. With the knowledge that that would likely be run-time costly, and so maybe not worth it.