Hello, everyone!

After participating in 16 game jams so far, I recognized some bad or questionable practices that had helped me to accomplish good results in really short times. I wanted to share them with you in case you find a good use for them!

But first, one small disclaimer: I am calling these bad or questionable practices because they can lead to many dangers. I will try to list all of them but probably I will miss a few. Also, I wouldn’t use any of these tricks unless I am totally aware of what I am doing, how can I fix it if something breaks and I am in a hurry so I can’t make them in any other way. The goal of these tricks are to produce fast, not necessary good altough some of them can be used correctly and give you great benefits.

Now, lets go for the tricks!

Singleton + Resources.Load

Going to make this one step by step. First, going to start explaning how did I use it. Imagine you have some kind of a manager (probably the code is a bit nasty already), and you want to access it from multiple places (nastier).

One trick you can use, is to use a singleton. This pattern is knowed sometimes as an anti-pattern because it goes against object-oriented design principles and don’t allow TDD. But, if you are in a game jam and need a fast way to reach them. You can do it by doing:

public class SingletonWithResources
{
    private static SingletonWithResources _instance;

    public static SingletonWithResources Instance
    {
        get
        {
            if(_instance == null)
                _instance = new SingletonWithResources();
            return _instance;
        }
    }
}

Basically, now you can call it from anywhere doing SingletonWithResources.Instance... whatever you want to do.

But let’s go further. Maybe you have a MonoBehaviour class and you can’t just use the new operator. Well, something you could do there is to set the value on the Start of the class and have something like this:

public class SingletonWithResources : MonoBehaviour
{
    private static SingletonWithResources _instance;

    public static SingletonWithResources Instance => _instance;

    void Start()
    {
        _instance = this;
    }
}

This way, when the Start is called, it will set the singleton value and everyone will be able to access it. But beware, by doing this you will need to have the script added to an object in the scene before calling this.

In order to avoid this, you could do another trick that is using Resources.Load and get the a prefab that already contains the script and instantiate when required. Something like this:

public class SingletonWithResources : MonoBehaviour
{
    private static SingletonWithResources _instance;

    public static SingletonWithResources Instance
    {
        get
        {
            if (_instance == null)
                _instance = Instantiate(Resources.Load<SingletonWithResources>("PATH TO THE PREFAB"));
            return _instance;
        }
    }
}

Note that now, you don’t need the game object in the scene anymore. It will auto instantiate when needed. Though, you will need to be carefull of what it does when it is instantiated.

Useful situations

One useful use of this trick is when you need something that has the audio controller of the game. You may want an audio source and an audio listener together and call it from many places. One extra would be to use DontDestroyOnLoad after instantiating that GameObject.

• Making a simple and quick audio manager. You want a GameObject with an Audio Source and an Audio Listener together and call it from many places. Just create a prefab with this script and add the audio manager functionality you want.
• You want to link your HUD to your general stats because you found out it will be the quickest way to implement it even it isn’t the most tidy thing to do. You can have your HUD with this script and update it’s stats via some functions and inmediatly update the HUD values.

Dangers

• Think that any class will be able to access this. You will need to be carefull of not modifying it state accidentaly from somewhere else.
• Don’t forget to reset it’s value. If you use DontDestroyOnLoad remember you will probably want to reset some values of it when finishing a level or ending a play run.
• Don’t forget the object will live unless you destroy it somehow. Specially if you use DontDestroyOnLoad
• Beware in case of destroying it, other classes may want to still acess to it. Think how will you manage these cases depending on your needs.
• If you are setting it’s Instance value in the Start, there may be some race conditions. This means some other classes may call it before it has set up.

Make everything (or most) a prefab

One trick we use at my current work and I maybe overdo a bit on the game jams now, is to make a prefab a lot of things.

Usually, when you think of prefabs you think of something that you are going to instantiate in many scenes or you are going to repeat all over the scene. This let’s you have a pre-set of values and when you change the prefab you make sure it auto updates all around the project. Or at least these are the only advices that Unity gives you for now.

The “new” useful situation

One trick, in order to be able to work multiple developers in the same scene is to make everything a prefab. This way, you will lower the ammount of people that actually need to “lock” the use of the scenes and multiple persons will be able to work at the same time.

Of course there are other useful situations like instantiating the same object over and over. But I wanted to focus on this one that is less known are at least it was for me a few years ago.

Dangers

• You will still need a lot of communication. Not touching the same scene doesn’t mean that you will not collide. You will have to ask for prefabs and make sure you are the only one using that prefab. This technique will only give more flexibility to the team but it is not a definitely solution.
• Take in mind that at some point you will need to actually add these at the scene. So you will still have to ask permission to touch the scene. Anyway, you can just ask to have the scene for a few seconds, add the prefab and set it up free for the rest of the team.

Excess of Interfaces

Some may argue there isn’t something like an excess of use for interfaces while others may talk about the Reused Abstraction Principle (R.A.P). For the fanciness of the post, I will leave the title to excess and I will let you decide.

But here is the trick. For Paw Pals, when we had the basic idea of what we wanted to do and the three programmers, including me, where ready to start, we were wondering what was the best approach in order to not collide between us.

So we came up with the following idea: We would start coding together and make only interfaces. One was going to work in the zones, the other one would be working on the kitties and the last one, me, would be working on setting up traits for the kitties. So what we did was to create together the interface of each area and everyone started asking for methods that they though they would need.

What you can accomplish

With this approach, we ended up having three interfaces with some methods inside and we were ready to split up and start working on our respective areas.

Each one of us created a new class, inherit from the interface we made together and started replacing the not implemented exceptions with the content we needed in order to make it work. Once we finished filling those methods, we only had to push it and we had something decent working as expected.

Were those interfaces needed?

Here some could argue that they weren’t needed because there was no real substitution. You would only use the same concrete class. Wich is true. But, for the sake of the speed and to improve the code communication within the three members in a really small spawn of time while giving us flexibility, this trick helped us at least to start. Even more, we used it through the whole project when we needed new functionality but we were focusing in another part of the code.

I think the real downside of this approach is that we had some no implemented exceptions till someone grabbed that part and filled with the stuff we needed.

Play with physics

Like, a lot, really. Just forget about the performance and give it a shot. Go to the physics manager of Unity, add more iterations and touch every value you see.

The goal of this practice is to touch everything of the Unity default physics and, if you are brave ago, go even further and use configurable joints or combine different joint types.

Goals

The goals of doing these are multiple but my favourites are:

• You can make procedural animations based only in physics. Also, making wonky and funny animations its relatively easy. For example, in Ostrich Run the necks were using this technique.
• Changing every parameter in the physics manager makes it feel more custom and removes that feel of simple Unity game.
• Adding a lot of rigidbodies in the scene, as in Ostrich Run when breaking glasses, gives a lot of life to the enviroment at a low production cost.

Perils

Nobody would say this is a bad practice per se in big projects but it is kinda a bet during a game jam. You need to be aware of at least the following things:

• Take in mind you can get a performance issue. Nowadays you have a good bandwith to work with but beware that the more rigidbodies you use in the scene or the more physics iteration you use, the more resources the physics will need.
• Using configurable joints, or even the common joint types, will need a basic level of understanding. You still be able to experiment but have in mind this takes time.

Conclusion

These are four tricks I usually use on game jams. They have proven to be very useful when needed but all of them have their dangers and you will need to be careful if you try it.

Thank you for reading and hope you found at something new and useful!