バクラウBloodless | Reusable Code
Hey folks. Hope you're having fun with all the games! I wanted to share a bit about our development process for バクラウBloodless, specially code stuff. Here ya go!

I thought it would be cool to go over the libraries we used, as well as the modules we developed during the jam. I want to tidy up the stuff we built as separate git projects so anyone can use/contribute to them, but for now they’re all in the(not too tidy) jam repo. Let's go over all this stuff
3rd Party stuff
Unity
I guess I should include this, right? We used Unity 2019.2 . One weird thing about Unity is that it often requires you to build your own systems for stuff like audio, because it's basic audio system is weird. More on that later!
DOTween
For those who don't know DOTween, it's an amazing and easy to use code-driven animation library with a free version. Ever since I've known DOTween, I don't think I've ever had a project where I didn't use it. It's also especially great for jams because of how it allows for a lot of complex behaviours to be implemented super quickly by code, and it allows you to make all of that stuff be event-driven, which I found often leads to better code!
Code from previous projects
We used some code from previous projects, with tweaks to some of them
State Machines
State Machines are super useful(here's a really good text about them if you don’t know them )! I really like our specific implementation. It's pretty straightforward. Here’s what one of its states looks like ``` public class IdleState : PlayerStateBase {
protected override void Begin()
{
}
public override void FixedUpdate()
{
Player.defaultMover.DoFixedUpdate(Player, Player.DirectionInput);
}
public override void OnDashPressed()
{
ExitTo(new DashState(Player.FacingDirection));
}
}
And the base class for player states looks like this
public class PlayerStateBase : State
{
protected PlayerController Player { get => Context; }
public virtual void Update() { }
public virtual void FixedUpdate() { }
public virtual void OnDashPressed() { }
public virtual void OnNoHealth()
{
ExitTo(new DeadState());
}
... ``` One nice thing about how we implemented the state machines is that it doesn't allow you to change, or even access states from outside. This leads you to isolate the state machine logic and communicate through events, which I find to be a good way to make the machine cleaner and easier to debug.
Character Movement
We used a rigidbody-based top-down movement code we had from previous projects. The movement is pretty simple, just a few weird forces that made the movement feel right to me, especially when changing direction. What I really liked was how the movement class is structured:
You create and configure a mover as following. Think of these as movements presets
Then you Implement a simple interface
public interface IMovingChar
{
public Rigibody2D Rigidbody { get; }
public Vector2 FacingDirection { get; }
}
And you just call the mover every frame
mover.DoFixedUpdate(this, input);
This makes it really easy to change the movement style of characters in different modes. We used this a lot with enemies to tweak their walk and attack movement speeds
Object Triggers
Because it's really common for you to have objects that trigger when they collide with an object of a specific type, we had code from previous projects for easy object triggers. You use it by extending this ObjectTrigger generic class and implement the OnTriggered function:
public class SimpleHazard : ObjectTrigger<PlayerController>
{
protected override void OnTrigger(PlayerController player)
{
player.OnHit(transform);
}
}
There's also this functionality with the triggers where you can create "proxies", so that you can add "external" hitboxes that are detected as the class they proxy for. I really want to use this one day for a boss where it just has lots of spots where you can hit!!!
``` public class PlayerExtraHitbox: IProxyFor { [SerializeField] private PlayerController player;
public PlayerController Owner { get { return owner; } } } ```
Jam Made Systems
Audio
I always have a hard time using unity's audio system. I just find it super hard to do even simple behaviours with it, and there are a lot of recurring problems, like a sound effect increasing in sound if it's triggered multiple times in the same frame. For all of those reasons, this jam I finally built a little sound system. It's far from perfect, and not very optimized for a big scale game, but it worked pretty well for the jam!
Here's how it’s used:
For each individual sound effect in the game, you create a sound effect asset like this. You can configure some stuff in it like what audiomixer group it outputs to, and a minimum play interval so you can stop it from triggering multiple times in a frame
Then you add it to the audio database
And you can play it in your game either by id or by the asset reference
AudioManager.Instance.Play("transition_end");
Then in the game it just creates the needed audiosources

Events
We built a nice event system for this game. It uses strings for event ids. I was a bit skeptical about using a system with strings for the events instead of just adding c# events to the each of the game's modules. In the end, I really liked how the string events allowed you to build stuff just through the inspector. I guess in the end both c# events and string-based events can coexist serving different functions!
TriggerManager.StartListening(EventName.OnBossSpawn, OnBossSpawn);
Final Thoughts
So those are the systems we used for building our game. Again, the whole code is available at the project’s repo on GitHub, so if you think any of these could be helpful, feel free to use them!
For more on our jam process, here's some other posts by our team, as well as our game