During the past month we have been working on a new game called MathFu, as part of a project called ‘Spil For Fremtiden’ (Games for the future). We’re one out of five game studios who are working together with five educational institutions, to create learning games. Learning games are games designed to be educational and teach the player about different subjects.
ClearCut Games was paired with parkvejsskolen in Odder, with the goal to create a prototype for a learning game on iPad that improves the student’s mental calculation skills.
It was a huge challenge, considering we had to come up with a game and make a playable prototype in just one month. After a few weeks of development, the game was presented at the learning games expo in Viborg.

Our approach to the prototype was to ask the students at parkvejsskolen in Odder what they considered a good learning game. The students had some very good input:

• The game should not only be about learning, and should contain gameplay for entertainment in addition to the purely educational content. To get a high score you should be good at both aspects.
• It should be competitive, either with a high score system where you can beat your friends score or an online multiplayer aspect.
• It should be fast and dynamic, small play sessions should be possible.
• The difficulty should automatically increase while playing.

After getting input from the students, we gathered some information about what kind of game our target group likes to play on the iPad. An endless runner was definitely something that not only matched the student’s idea of a good game, but was also something they already were spending a lot of time playing. Among the games on the app store, Subway Surfers and Temple Run are extremely popular endless runners, so we decided to borrow core elements from these games, and combine them with a gameplay mechanic of our own for training mental calculation.
Using a proven concept meant that we didn’t have to reinvent the wheel in just one month, and would allow us to focus on the math and calculation part of the game. And that led to MathFu!

In MathFu you play a small Japanese ninja, who is trying to escape from a group of angry Chinese farmers on The Great Wall. Utilizing the touch screen, you swipe to dodge different obstacles. But the sneaky farmers have put up calculations on the towers, so only those who can solve the calculations know which of the doors the correct one is. Bonus missions include picking out different multiplication tables while on the run.

Here’s a screenshot from the prototype:

As mentioned earlier, we presented the game at the Learning Games expo in Viborg, which was a great experience! People enjoyed playing both MathFu and our puzzle game Cado. Overall it was an inspirational event, a lot of great projects and people attended. Hopefully the prototype will be further developed into a finished game, so students can practice their mental calculation skill while enjoying the fun of an endless runner. As I mentioned, making the MathFu prototype in a month was a great challenge, but we are also very busy with our upcoming game Minnow (working title). Expect to hear more about that soon, and to finish of this post, here’s a picture of some kids playing MathFu and Cado at the expo.

Today we are going to talk about something truly unique… The singleton pattern!
The singleton pattern lets you write a class, which can only be instantiated once. A singleton object sure is ‘one of a kind’.

The singleton pattern is a very useful, yet very simple design pattern.
A design pattern is a general solution that you can apply to a problem in software design. In this case our problem is that we want a class, that there should only be one instance of, and we want easy access to that instance.

If you are a relatively new programmer, you might be thinking “What use is this? Why on earth would I write a class that can only be instantiated once?”
Now think of objects like an input manager responsible for reading input from the keyboard and mouse, or an audio handler like the one we described in our last post, responsible for playing audio in your game.
Having more than one instance of these, might cause some very incorrect behavior.

Okay, so there’s that. But what about writing a static class? Using a static class you can have a class with global access, and it can’t be instantiated so you will definitely not have multiple instances.
It seems that a static class could do the job, but it has some downsides:

• You can’t extend MonoBehaviour with a static class, and thereby not apply your class as a component on a GameObject in Unity.
• You can’t pass around a static class as a parameter
• You can’t implement an interface with a static class

Let’s try and look at a very simple implementation of the Singleton Pattern in Unity.

using UnityEngine;

public class AudioHandler : MonoBehaviour
{
    // Public field, set in the inspector we can access
    // the audio clip through the singleton instance
    public AudioClip explosionClip;

    // Static singleton property
    public static AudioHandler Instance { get; private set; }

    void Awake()
    {
        // Save a reference to the AudioHandler component as our singleton instance
        Instance = this;
    }

    // Instance method, this method can be accesed through the singleton instance
    public void PlayAudio(AudioClip clip)
    {
        audio.clip = clip;
        audio.Play();
    }
}

Now if you want to call the PlaySound() method from another class, you simply do it like this.

// Play sound
AudioHandler.Instance.PlayAudio(AudioHandler.Instance.explosionClip);

A great thing, as you see in the above example, is that you have easy access to the public variables set in the inspector. We can access the sound clips from the inspector through our singleton instance.

Let’s try and look at another more complex implementation of the Singleton Pattern

using UnityEngine;

public class AudioHandler : MonoBehaviour
{
    // Public field, set in the inspector we can access
    // the audio clip through the singleton instance
    public AudioClip explosionClip;

    // Static singleton property
    public static AudioHandler Instance { get; private set; }

    void Awake()
    {
        // First we check if there are any other instances conflicting
        if(Instance != null && Instance != this)
        {
            // If that is the case, we destroy other instances
            Destroy(gameObject);
        }

        // Here we save our singleton instance
        Instance = this;

        // Furthermore we make sure that we don't destroy between scenes (this is optional)
        DontDestroyOnLoad(gameObject);
    }

    // Instance method, this method can be accesed through the singleton instance
    public void PlayAudio(AudioClip clip)
    {
        audio.clip = clip;
        audio.Play();
    }
}

This implementation ensures that there can only be a single instance of the class, even if you accidently have more than one applied as a component in Unity. It also has the advantage/disadvantage depending on the context, of not getting destroyed between different scenes. Another feature that you might find good or bad is that the static instance variable doesn’t get reset between play sessions.

In a true singleton implementation, we have something called lazy instantiation. What this means is that the singleton instance itself, will not be created before you try to access it the first time around. This will generally spare you some resources, and is another great advantage of the singleton pattern. Now the reason we didn’t have any lazy instantiation in the above example, is because we want to be able to assign our audio clips in the inspector. This means that even before your game starts, the instance already exists, because you applied as a component by dragging and dropping.

I’m going to round up this post with a general implementation of the singleton pattern with lazy instantiation, which you can use if you are not going to assign any inspector fields.

using UnityEngine;

public class Singleton : MonoBehaviour
{
    // This field can be accesed through our singleton instance,
    // but it can't be set in the inspector, because we use lazy instantiation
    public int number;

    // Static singleton instance
    private static Singleton instance;

    // Static singleton property
    public static Singleton Instance
    {
        // Here we use the ?? operator, to return 'instance' if 'instance' does not equal null
        // otherwise we assign instance to a new component and return that
        get { return instance ?? (instance = new GameObject("Singleton").AddComponent<Singleton>()); }
    }

    // Instance method, this method can be accesed through the singleton instance
    public void DoSomeAwesomeStuff()
    {
        Debug.Log("I'm doing awesome stuff");
    }
}

The use is exactly the same; you call methods through the singleton instance.

// Do awesome stuff through our singleton instance
Singleton.Instance.DoSomeAwesomeStuff();

Now because of lazy instantiation, the first time you use the singleton instance, it is initialized and a new GameObject appears in the hierarchy.

And we can see that our awesome method actually got called in the console.

I hope you will find the singleton pattern useful, and if you have any trouble, improvements or feedback please leave a comment below

This is the first Unity post in a series where we’ll share some of our experience and methods for working with the Unity3D game engine.

This is going to be a post about sound design and programming, by David Larsen and Mathias Soeholm. We will show you how we handle audio inside Unity, and make sure that repetitive sounds, sound good. Let’s talk about the latter first.

_____

David Larsen

When we use sound effects in Unity3D, we often use a principle called Round Robin, or anti-repetition. Basically, Round Robin is when you use multiple variations of the same sound effect, so when the sound effect is triggered, one of these variations is played at random. The purpose of this is to get rid of the so-called “machinegun-effect” – when a single audio file (for example footsteps, or hit impacts) is repeated in quick succession, it sounds very unnatural and unrealistic.

Here’s an example of a series of footsteps using the same audio file:

Hardly sounds convincing, huh? It’s very obvious that it’s just the same sound effect played over and over again. Here’s how you fix it, using the Round Robin principle:
Let’s say you have a sound effect called “Explosion”. Now imagine you have 3 or more variations of that same explosion, called Exp_1.mp3, Exp_2.mp3 and Exp_3.mp3.
When the “Explosion” sound effect is triggered, have a script randomly select one of these sounds. First time it’s triggered, it might use Exp_2.mp3. Next Exp_1.mp3, then Exp_3.mp3, and then perhaps Exp_1.mp3 again. This gets rid of the machinegun effect, and it makes the sound effect feel much more dynamic and realistic.

Here is a set of footsteps that are triggered the same way as with the previous example, but now with a script that is randomly choosing between a selection of 5 variations of the footsteps. The difference should be very clear:

At a minimum, you want 3 sound variations for this to work, but the more the better. If I can get away with it, I do 4-6 variations of each sound.
Something you want to be aware of, is that true randomization won’t necessarily work better. You don’t want to play back the same sound variation twice. Our solution was to exclude the audio files that had already been played from the selection. So if Exp_1.mp3 had just been used, only Exp_2.mp3 and Exp_3.mp3 would be available.

The biggest downside to using round Robin is of course that you need to come up with a lot of variations of each sound. While it’s easy enough to get a lot of sounds for footsteps and such, you might not be able to find multiple sounds for effects like explosions, impacts, etc. But remember, even very subtle things like a tiny pitchshift, a bit of EQ’ing, and maybe timestretching will get you very far – even if you don’t have the opportunity to get multiple recordings or design variations of a specific sound.

Mathias Soeholm, our gameplay programmer, made a really useful script for this. It’s called AudioHandler, and it manages all the audio in our games. It’s responsible for playing music and sound effects, and it has a Round Robin engine build right in.
Feel free to use this however you want. Below is the entire script, and documentation on how to use it, written by Mathias.

_______

Mathias Soeholm

The AudioHandler script, utilizes one of multiple audio sources in the scene, and selects one of them at random. I use multiple audio sources, because a single audio source can only play one sound at a time. This is a great system if you are using 2D sounds and you’re not dependent on where your audio sources are located in the scene.

AudioHandler.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[System.Serializable]
public class AudioCollection
{
    public int repeatInterval;
    public AudioClip[] audioClips;

    [HideInInspector]
    public List<int> recentlyPlayedSounds = new List<int>();
}

public class AudioHandler : MonoBehaviour
{
    enum MusicState
    {
        FullVolume,
        FadingIn,
        FadingOut,
        Muted
    }

    private const float FadeFactor = 0.2f;

    // Audio clips - Example variables
    public AudioClip deliverAtSafeZoneSound;
    public AudioCollection joinShoalSounds;

    private static MusicState musicState = MusicState.Muted;
    private static int nextAudioSource;
    private static List<AudioSource> audioSources = new List<AudioSource>();
    private static AudioCollection collectionToPlay;

    // Static reference to singleton object
    public static AudioHandler instance;

    // Methods
    void Start()
    {
        audioSources.Clear();
        instance = gameObject.GetComponent<AudioHandler>();
        
        // Trigger FadeIn
        musicState = MusicState.FadingIn;

        // Get references to all audio sources in the scene
        foreach (var audioSource in GameObject.FindGameObjectsWithTag("AudioSourceObject"))
        {
            audioSources.Add(audioSource.GetComponent<AudioSource>());
        }
    }

    void Update()
    {
        HandleMusicFade();
    }

    void HandleMusicFade()
    {
        switch (musicState)
        {
            case MusicState.FadingIn:
                audio.volume = Mathf.Min(audio.volume + FadeFactor*Time.deltaTime, 1);
                if (audio.volume >= 1)
                    musicState = MusicState.FullVolume;
                break;
            case MusicState.FadingOut:
                audio.volume = Mathf.Max(audio.volume - FadeFactor*Time.deltaTime, 0);
                if (audio.volume <= 0)
                    musicState = MusicState.Muted;
                break;
        }
    }

    public void PlayCipFromCollection(ref AudioCollection collection)
    {
        collectionToPlay = collection;

        StartCoroutine("PlayCollectionClip");
    }

    IEnumerator PlayCollectionClip()
    {
        yield return 0;

        int clipToPlay;

        // The use of coroutines enables us to use a while loop
        do
        {
            clipToPlay = Random.Range(0, collectionToPlay.audioClips.Length);

        } while (collectionToPlay.recentlyPlayedSounds.Contains(clipToPlay));

        collectionToPlay.recentlyPlayedSounds.Add(clipToPlay);

        if (collectionToPlay.recentlyPlayedSounds.Count > collectionToPlay.repeatInterval)
            collectionToPlay.recentlyPlayedSounds.RemoveAt(0);

        PlaySound(collectionToPlay.audioClips[clipToPlay]);
    }

    public static void PlaySound(AudioClip clip)
    {
        // Get index for the next audio source to use
        nextAudioSource = (nextAudioSource + 1) % audioSources.Count;

        if (audioSources[nextAudioSource].isPlaying) return;

        // Assign the clip to the selected audio source
        audioSources[nextAudioSource].clip = clip;

        // Play the clip with the selected audio source
        audioSources[nextAudioSource].PlayOneShot(clip);
    }
}

The picture below shows how the audio sources are set up on individual gameobjects, all with the tag “AudioSourceObject”, which is important for the script to be able to find and utilize the audio sources.

Sounds are added in the inspector, either as a single sound or a collection. The AudioHandler script is applied on a gameobject, which also contains an audio source for the music.

I’ve set up an example of each in the script:

// Audio clips - Example variables
public AudioClip deliverAtSafeZoneSound;
public AudioCollection joinShoalSounds;

Here’s how it looks in the inspector:

Each sound collection contains a variable called ‘repeatInterval’. This is how many other sounds, which must be played before repeating a previously played sound. The repeat interval must always be below the amount of sounds in a collection, otherwise you’ll end up in an infinite while loop, and that’s bad!

To play a sound from a collection, from other scripts, you use the static instance of the AudioHandler class, which references the AudioHandler component on the gameobject. Here’s an example:

// Play sound
AudioHandler.instance.PlayCipFromCollection(ref AudioHandler.instance.joinShoalSounds);

The ‘ref’ keyword is used to pass by reference and not as a copy.

To play a single sound that is not part of a collection, you simply call the static PlaySound() method. Here’s an example:

// Play sound
AudioHandler.PlaySound(AudioHandler.instance.deliverAtSafeZoneSound);

If you have any trouble, I’ll be glad to help you out just leave a comment below. And if you make any improvements, please share.

/Mathias

We spent the holiday at the Copenhagen Games e-sport event. During the event, we worked together with our neighbor, Thermal Games, developing a small game and giving the attendees some insight to the process of developing a game.
The event lasted four days, and during that time we managed to create a small tower defense game. We only decided the genre, letting the visitors who stopped by our booth determine everything else, from protagonists and antagonists, to what kind of abilities the towers should have.
It was a great experiment, and the gamers and visitors who came with suggestions were very creative. We gave out five CS:GO beta keys as rewards to the best ideas for towers, and three Diablo III beta keys for the best name for the game: Lucifer’s Maze.

Working with Thermal Games and the people at Copenhagen Games was really fun and a great experience.

Check out Lucifers Maze here. While you play, keep in mind that the point with the event was not to make a finished game, but to give people an idea of the process. As a result, the game is fairly unfinished and buggy, but we hope you enjoy it none the less. Tell us what you think in the comments below.

 

First of all, Cado HD is now permanently 66% off! That’s 100% game for only 33% of the price!
Grab Cado HD for $1 here

Tomorrow it is time for Copenhagen Games, the biggest eSport event in Denmark. Professional gamers are pitted against in other in a virtual bloodbath featuring competitive games like Starcraft II and Counter Strike. So what does this have to do with casual iOS games? Well, we’re going to be there, all four days of the event, developing a game!

We have teamed up with our neighbor, Thermal Games, and we are going to have a booth, smack in the middle of the event. During that time we will make a small game, collaborating with Thermal Games. But it doesn’t stop there; we will base the entire game on input from the gamers at the event, so if you have always wanted to help make a game, here’s your chance.

With us, we are bringing 100 promo codes for Cado and Cado HD. We will be giving these away to everybody we see during the event. If you are attending, leave a comment below, and we’ll make sure to save one for you!

Copenhagen Games starts Wednesday and will last four days until Saturday night, and we will be there the entire time. So if you are going, be sure to stop by to get a free promo code for Cado, and command us when we make a game.

Check out Copenhagen Games on Facebook