Dominic Frei

Developer Advocate

Persisting data is an important part of most games. Unity offers only a limited set of solutions, which means we have to look around for other options as well.

In this tutorial series, we will explore the options given to us by Unity and third-party libraries.

Saving Data in Unity3D Using PlayerPrefs

Nic Raboy

Staff Developer Advocate



<div class="introduction">

Are you working on a game in [Unity](https://unity.com/) and finding yourself needing to make use of a database in the cloud? Storing your data locally works for a lot of games, but there are many gaming scenarios where you'd need to leverage an external database. Maybe you need to submit your high score for a leaderboard, or maybe you need to save your player stats and inventory so you can play on numerous devices. There are too many reasons to list as to why a remote database might make sense for your game.

If you've been keeping up with the content publishing on the [MongoDB Developer Hub](https://developer.mongodb.com) and our [Twitch](https://www.twitch.tv/mongodb) channel, you'll know that I'm working on a game development series with [Adrienne Tacke](https://www.twitter.com/adriennetacke). This series is centered around creating a 2D multiplayer game with Unity that uses MongoDB as part of the online component. Up until now, we haven't actually had the game communicate with MongoDB.

In this tutorial, we're going to see how to make HTTP requests from a Unity game to a back end that communicates with [MongoDB](https://www.mongodb.com). The back end was already developed in a tutorial titled, [Creating a User Profile Store for a Game With Node.js and MongoDB](https://developer.mongodb.com/how-to/creating-user-profile-store-game-nodejs-mongodb). We're now going to leverage it in our game.

To get an idea where we're at in the tutorial series, take a look at the animated image below:

![Plummeting People Fake Doors Example](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/plummeting-people-fake-doors-example.gif)

To take this to the next level, it makes sense to send data to MongoDB when the player crosses the finish line. For example, we can send how many steps were taken by the player in order to reach the finish line, or how many times the player collided with something, or even what place the player ranked in upon completion. The data being sent doesn't truly matter as of now.

The assumption is that you've been following along with the tutorial series and are jumping in where we left off. If not, some of the steps that refer to our project may not make sense, but the concepts can be applied in your own game. The tutorials in this series so far are:

-   [Designing a Strategy to Develop a Game with Unity and MongoDB](https://developer.mongodb.com/how-to/designing-strategy-develop-game-unity-mongodb)
-   [Creating a User Profile Store for a Game with Node.js and MongoDB](https://developer.mongodb.com/how-to/creating-user-profile-store-game-nodejs-mongodb)
-   [Getting Started with Unity for Creating a 2D Game](https://developer.mongodb.com/how-to/getting-started-unity-creating-2d-game)
-   [Designing and Developing 2D Game Levels with Unity and C#](https://developer.mongodb.com/how-to/designing-developing-2d-game-levels-unity-csharp)

If you'd like to view the source code to the project, it can be found on [GitHub](https://github.com/mongodb-developer/plummeting-people-game).

## Creating a C# Class in Unity to Represent the Data Model Within MongoDB

Because Unity, as of now, doesn't have an official MongoDB driver, sending and receiving MongoDB data from Unity isn't handled for you. We're going to have to worry about marshalling and unmarshalling our data as well as making the request. In other words, we're going to need to manipulate our data manually to and from JSON and C# classes.

To make this possible, we're going to need to start with a class that represents our data model in MongoDB.

Within your project's **Assets/Scripts** directory, create a **PlayerData.cs** file with the following code:

``` csharp
using UnityEngine;

public class PlayerData
{
    public string plummie_tag;
    public int collisions;
    public int steps;
}
```

Notice that this class does not extend the `MonoBehavior` class. This is because we do not plan to attach this script as a component on a game object. The `public`-defined properties in the `PlayerData` class represent each of our database fields. In the above example, we only have a select few, but you could add everything from our user profile store if you wanted to.

It is important to use the `public` identifier for anything that will have relevance to the database.

We need to make a few more changes to the `PlayerData` class. Add the following functions to the class:

``` csharp
using UnityEngine;

public class PlayerData
{
    // 'public' variables here ...

    public string Stringify() 
    {
        return JsonUtility.ToJson(this);
    }

    public static PlayerData Parse(string json)
    {
        return JsonUtility.FromJson<PlayerData>(json);
    }
}
```

Notice the function names are kind of like what you'd find in JavaScript if you are a JavaScript developer. Unity expects us to send string data in our requests rather than objects. The good news is that Unity also provides a helper `JsonUtility` class that will convert objects to strings and strings to objects.

The `Stringify` function will take all `public` variables in the class and convert them to a JSON string. The fields in the JSON object will match the names of the variables in the class. The `Parse` function will take a JSON string and convert it back into an object that can be used within C#.

## Sending Data with POST and Retrieving Data with GET in a Unity Game

With a class available to represent our data model, we can now send data to MongoDB as well as retrieve it. Unity provides a [UnityWebRequest](https://docs.unity3d.com/ScriptReference/Networking.UnityWebRequest.html) class for making HTTP requests within a game. This will be used to communicate with a back end designed with a particular programming language.

We're going to spend the rest of our time in the project's **Assets/Scripts/Player.cs** file. This script is attached to our player as a component and was created in the tutorial titled, [Getting Started with Unity for Creating a 2D Game](https://developer.mongodb.com/how-to/getting-started-unity-creating-2d-game). In your own game, it doesn't really matter which game object script you use.

Open the **Assets/Scripts/Player.cs** file and make sure it looks similar to the following:

``` csharp
using UnityEngine;
using System.Text;
using UnityEngine.Networking;
using System.Collections;

public class Player : MonoBehaviour
{
    public float speed = 1.5f;

    private Rigidbody2D _rigidBody2D;
    private Vector2 _movement;

    void Start()
    {
        _rigidBody2D = GetComponent<Rigidbody2D>();
    }

    void Update()
    {
        // Mouse and keyboard input logic here ...
    }

    void FixedUpdate() {
        // Physics related updates here ...
    }
}
```

I've stripped out a bunch of code from the [previous tutorial](https://developer.mongodb.com/how-to/designing-developing-2d-game-levels-unity-csharp) as it doesn't affect anything we're planning on doing. The previous code was very heavily related to moving the player around on the screen and should be left in for the real game, but is overlooked in this example, at least for now.

Two things to notice that are important are the imports:

``` csharp
using System.Text;
using UnityEngine.Networking;
```

The above two imports are important for the networking features of Unity. Without them, we wouldn't be able to properly make GET and POST requests.

Before we make a request, let's get our `PlayerData` class included. Make the following changes to the **Assets/Scripts/Player.cs** code:

``` csharp
using UnityEngine;
using System.Text;
using UnityEngine.Networking;
using System.Collections;

public class Player : MonoBehaviour
{
    public float speed = 1.5f;

    private Rigidbody2D _rigidBody2D;
    private Vector2 _movement;
    private PlayerData _playerData;

    void Start()
    {
        _rigidBody2D = GetComponent<Rigidbody2D>();
        _playerData = new PlayerData();
        _playerData.plummie_tag = "nraboy";
    }

    void Update() { }

    void FixedUpdate() { }

    void OnCollisionEnter2D(Collision2D collision) 
    {
        _playerData.collisions++;
    }
}
```

In the above code, notice that we are creating a new `PlayerData` object and assigning the `plummie_tag` field a value. We're also making use of an `OnCollisionEnter2D` function to see if our game object collides with anything. Since our function is very vanilla, collisions can be with walls, objects, etc., and nothing in particular. The collisions will increase the `collisions` counter.

So, we have data to work with, data that we need to send to MongoDB. To do this, we need to create some `IEnumerator` functions and make use of coroutine calls within Unity. This will allow us to do asynchronous activities such as make web requests.

Within the **Assets/Scripts/Player.cs** file, add the following `IEnumerator` function:

``` csharp
IEnumerator Download(string id, System.Action<PlayerData> callback = null)
{
    using (UnityWebRequest request = UnityWebRequest.Get("http://localhost:3000/plummies/" + id))
    {
        yield return request.SendWebRequest();

        if (request.isNetworkError || request.isHttpError)
        {
            Debug.Log(request.error);
            if (callback != null)
            {
                callback.Invoke(null);
            }
        }
        else
        {
            if (callback != null)
            {
                callback.Invoke(PlayerData.Parse(request.downloadHandler.text));
            }
        }
    }
}
```

The `Download` function will be responsible for retrieving data from our database to be brought into the Unity game. It is expecting an `id` which we'll use a `plummie_id` for and a `callback` so we can work with the response outside of the function. The response should be `PlayerData` which is that of the data model we just made.

After sending the request, we check to see if there were errors or if it succeeded. If the request succeeded, we can convert the JSON string into an object and invoke the callback so that the parent can work with the result.

Sending data with a payload, like that in a POST request, is a bit different. Take the following function:

``` csharp
IEnumerator Upload(string profile, System.Action<bool> callback = null)
{
    using (UnityWebRequest request = new UnityWebRequest("http://localhost:3000/plummies", "POST"))
    {
        request.SetRequestHeader("Content-Type", "application/json");
        byte[] bodyRaw = Encoding.UTF8.GetBytes(profile);
        request.uploadHandler = new UploadHandlerRaw(bodyRaw);
        request.downloadHandler = new DownloadHandlerBuffer();
        yield return request.SendWebRequest();

        if (request.isNetworkError || request.isHttpError)
        {
            Debug.Log(request.error);
            if(callback != null) 
            {
                callback.Invoke(false);
            }
        }
        else
        {
            if(callback != null) 
            {
                callback.Invoke(request.downloadHandler.text != "{}");
            }
        }
    }
}
```

In the `Upload` function, we are expecting a JSON string of our profile. This profile was defined in the `PlayerData` class and it is the same data we received in the `Download` function.

The difference between these two functions is that the POST is sending a payload. For this to work, the JSON string needs to be converted to `byte[]` and the upload and download handlers need to be defined. Once this is done, it is business as usual.

It is up to you what you want to return back to the parent. Because we are creating data, I thought it'd be fine to just return `true` if successful and `false` if not. To demonstrate this, if there are no errors, the response is compared against an empty object string. If an empty object comes back, then false. Otherwise, true. This probably isn't the best way to respond after a creation, but that is up to the creator (you, the developer) to decide.

The functions are created. Now, we need to use them.

Let's make a change to the `Start` function:

``` csharp
void Start()
{
    _rigidBody2D = GetComponent<Rigidbody2D>();
    _playerData = new PlayerData();
    _playerData.plummie_tag = "nraboy";
    StartCoroutine(Download(_playerData.plummie_tag, result => {
        Debug.Log(result);
    }));
}
```

When the script runs—or in our, example when the game runs—and the player enters the scene, the `StartCoroutine` method is executed. We are providing the `plummie_tag` as our lookup value and we are printing out the results that come back.

We might want the `Upload` function to behave a little differently. Instead of making the request immediately, maybe we want to make the request when the player crosses the finish line. For this, maybe we add some logic to the `FixedUpdate` method instead:

``` csharp
void FixedUpdate() 
{
    // Movement logic here ...

    if(_rigidBody2D.position.x > 24.0f) {
        StartCoroutine(Upload(_playerData.Stringify(), result => {
            Debug.Log(result);
        }));
    }
}
```

In the above code, we check to see if the player position is beyond a certain value in the x-axis. If this is true, we execute the `Upload` function and print the results.

The above example isn't without issues though. As of now, if we cross the finish line, we're going to experience many requests as our code will continuously execute. We can correct this by adding a boolean variable into the mix.

At the top of your **Assets/Scripts/Player.cs** file with the rest of your variable declarations, add the following:

``` csharp
private bool _isGameOver;
```

The idea is that when the `_isGameOver` variable is true, we shouldn't be executing certain logic such as the web requests. We are going to initialize the variable as false in the `Start` method like so:

``` csharp
void Start()
{
    // Previous code here ...
    _isGameOver = false;
}
```

With the variable initialized, we can make use of it prior to sending an HTTP request after crossing the finish line. To do this, we'd make a slight adjustment to the code like so:

``` csharp
void FixedUpdate() 
{
    // Movement logic here ...

    if(_rigidBody2D.position.x > 24.0f && _isGameOver == false) {
        StartCoroutine(Upload(_playerData.Stringify(), result => {
            Debug.Log(result);
        }));
        _isGameOver = true;
    }
}
```

After the player crosses the finish line, the HTTP code is executed and the game is marked as game over for the player, preventing further requests.

## Conclusion

You just saw how to use the `UnityWebRequest` class in Unity to make HTTP requests from a game to a remote web server that communicates with MongoDB. This is valuable for any game that needs to either store game information remotely or retrieve it.

There are plenty of other ways to make use of the `UnityWebRequest` class, even in our own player script, but the examples we used should be a great starting point.

This tutorial series is part of a series streamed on Twitch. To see these streams live as they happen, follow the [Twitch](https://www.twitch.tv/mongodb) channel and tune in.

Learn how to interact with MongoDB from a Unity game with C# and the UnityWebRequest class.

Sending and Requesting Data from MongoDB in a Unity Game

Learn how to build a space shooter game that synchronizes between clients and the cloud using MongoDB, Unity, and Atlas Device Sync.

Building a Space Shooter Game in Unity that Syncs with Realm and MongoDB Atlas

If you've been keeping up with the content on the [MongoDB Developer Portal](https://developer.mongodb.com), you'll know that a few of us at MongoDB ([Nic Raboy](https://www.nraboy.com), [Adrienne Tacke](https://www.twitter.com/adriennetacke), [Karen Huaulme](https://www.twitter.com/youoldmaid)) have been working on a game titled Plummeting People, a [Fall Guys: Ultimate Knockout](https://fallguys.com/) tribute game. Up until now we've focused on [game planning](https://developer.mongodb.com/how-to/designing-strategy-develop-game-unity-mongodb) and part of our backend infrastructure with a user profile store.

As part of the natural progression in our development of the game and part of this tutorial series, it makes sense to get started with the actual gaming aspect, and that means diving into [Unity](https://unity.com/), our game development framework.

In this tutorial, we're going to get familiar with some of the basics behind Unity and get a sprite moving on the screen as well as handing collision. If you're looking for how we plan to integrate the game into MongoDB, that's going to be saved for another tutorial.

An example of what we want to accomplish can be seen in the following animated image:

![Unity 2D Game Example](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-2d-game-example.gif)

The framerate in the image is a little stuttery, but the actual result is quite smooth.

## The Requirements

Before we get started, it's important to understand the requirements for creating the game.

-   Unity 2020+
-   Image to be used for player
-   Image to be used for the background

I'm using Unity 2020.1.6f1, but any version around this particular version should be fine. You can download [Unity](https://unity.com/) at no cost for macOS and Windows, but make sure you understand the licensing model if you plan to sell your game.

Since the goal of this tutorial is around moving a game object and handling collisions with another game object, we're going to need images. I'm using a 1x1 pixel image for my player, obstacle, and background, all scaled differently within Unity, but you can use whatever images you want.

## Creating a New Unity Project with Texture and Script Assets

To keep things easy to understand, we're going to start with a fresh project. Within the **Unity Hub** application that becomes available after installing Unity, choose to create a new project.

![Unity Create New 2D Project](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-new-2d-project.png)

You'll want to choose **2D** from the available templates, but the name and project location doesn't matter as long as you're comfortable with it.

The project might take a while to generate, but when it's done, you should be presented with something that looks like the following:

![Unity Empty New Project](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-empty-2d-project.png)

As part of the first steps, we need to make the project a little more development ready. Within the **Project** tree, right click on **Assets** and choose to create a new folder for **Textures** as well as **Scripts**.

![Create New Unity Asset Folder](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-new-asset-folder.jpg)

Any images that we plan to use in our game will end up in the **Textures** folder and any game logic will end up as a script within the **Scripts** folder. If you have your player, background, and obstacle images, place them within the **Textures** directory now.

As of right now there is a single scene for the game titled **SampleScene**. The name for this scene doesn't properly represent what the scene will be responsible for. Instead, let's rename it to **GameScene** as it will be used for the main gaming component for our project. A scene for a game is similar to a scene in a television show or movie. You'll likely have more than one scene, but each scene is responsible for something distinct. For example, in a game you might have a scene for the menu that appears when the user starts the game, a scene for game-play, and a scene for what happens when they've gotten game over. The use cases are limitless.

With the scene named appropriately, it's time to add game objects for the player, background, and obstacle. Within the project hierarchy panel, right click underneath the **Main Camera** item (if your hierarchy is expanded) or just under **GameScene** (if not expanded) and choose **Create Empty** from the list.

![Create Empty Game Object in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-create-empty-gameobject.jpg)

We'll want to create a game object for each of the following: the player, background, and obstacle. The name isn't too important, but it's probably a good idea to give them names based around their purpose.

To summarize what we've done, double-check the following:

-   Created a **Textures** and **Scripts** directory within the **Assets** directory.
-   Added an image that represents a player, an obstacle, and a background to the **Textures** directory.
-   Renamed **SampleScene** to **GameScene**.
-   Created a **Player** game object within the scene.
-   Created an **Obstacle** game object within the scene.
-   Created a **Background** game object within the scene.

At this point in time we have the project properly laid out.

## Adding Sprite Renders, Physics, Collision Boxes, and Scripts to a Game Object

We have our game objects and assets ready to go and are now ready to configure them. This means adding images to the game object, physics properties, and any collision related data.

With the player game object selected from the project hierarchy, choose **Add Component** and search for **Sprite Renderer**.

![Add Sprite Renderer to Game Object](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-2d-sprite-renderer-component.png)

The **Sprite Renderer** allows us to associate an image to our game object. Click the circle icon next to the **Sprite** property's input box. A panel will pop up that allows you to select the image you want to associate to the selected game object. You're going to want to use the image that you've added to the **Textures** directory. Follow the same steps for the obstacle and the background.

You may or may not notice that the layering of your sprites with images are not correct in the sense that some images are in the background and some are in the foreground. To fix the layering, we need to add a **Sorting Layer** to the game objects.

![Add Sorting Layer to Sprite Rendering in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-sprite-renderer-sorting-layer.png)

Rather than using the default sorting layer, choose to **Add Sorting Layer...** so we can use our own strategy. Create two new layers titled **Background** and **GameObject** and make sure that **Background** sits above **GameObject** in the list. The list represents the rendering order so higher in the list gets rendered first and lower in the list gets rendered last. This means that the items rendering last appear at the highest level of the foreground. Think about it as layers in Adobe Photoshop, only reversed in terms of which layers are most visible.

With the sorting layers defined, set the correct **Sorting Layer** for each of the game objects in the scene.

For clarity, the background game object should have the **Background** sorting layer applied and the obstacle as well as the player game object should have the **GameObject** sorting layer applied. We are doing it this way because based on the order of our layers, we want the background game object to truly sit behind the other game objects.

The next step is to add physics and collision box data to the game objects that should have such data. Select the player game object and search for a **Rigidbody 2D** component.

![Add Rigid Body 2D to Game Object in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-rigidbody2d-component.png)

Since this is a 2D game that has no sense of flooring, the **Gravity Scale** for the player should be zero. This will prevent the player from falling off the screen as soon as the game starts. The player is the only game object that will need a rigid body because it is the only game object where physics might be important.

In addition to a rigid body, the player will also need a collision box.  Add a new **Box Collider 2D** component to the player game object.

![Add Box Collider 2D to Game Object in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-box-collider-2d.png)

The **Box Collider 2D** component should be added to the obstacle as well. The background, since it has no interaction with the player or obstacle does not need any additional component added to it.

The final configuration for the game objects is the adding of the scripts for game logic.

Right click on the **Scripts** directory and choose to create a new **C# Script**. You'll want to rename the script to something that represents the game object that it will be a part of. For this particular script, it will be associated to the player game object.

![Add Script to Game Object in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/getting-started-unity-creating-2d-game/unity-new-script.png)

After selecting the game object for the player, drag the script file to the **Add Component** area of the inspector to add it to the game object.

At this point in time everything for this particular game is configured.  However, before we move onto the next step, let's confirm the components added to each of the game objects in the scene.

-   Background has one sprite renderer with a **Background** sorting layer.
-   Player has one sprite renderer, one rigid body, and one box collider with the **GameObject** sorting layer.
-   Obstacle has one sprite renderer, and one box collider with the **GameObject** sorting layer.

The next step is to apply some game logic.

## Controlling a Game Object with a Unity C# Script

In Unity, everything in a scene is controlled by a script. These scripts exist on game objects which make it easy to separate the bits and pieces that make up a game. For example the player might have a script with logic. The obstacles might have a different script with logic. Heck, even the grass within your scene might have a script. It's totally up to you how you want to script every part of your scene.

In this particular game example, we're only going to add logic to the player object script.

The script should already be associated to a player object, so open the script file and you should see the following code:

``` csharp
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Player : MonoBehaviour
{

    void Start()
    {
        // ...
    }

    void Update()
    {
        // ...
    }

}
```

To move the player we have a few options. We could transform the position of the game object, we can transform the position of the rigid body, or we can apply physics force to the rigid body. Each will give us different results, with the force option being the most unique.

Because we do have physics, let's look at the latter two options, starting with the movement through force.

Within your C# script, change your code to the following:

``` csharp
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Player : MonoBehaviour
{

    public float speed = 1.5f;

    private Rigidbody2D rigidBody2D;

    void Start()
    {
        rigidBody2D = GetComponent<Rigidbody2D>();
    }

    void Update()
    {

    }

    void FixedUpdate() {
        float h = 0.0f;
        float v = 0.0f;
        if (Input.GetKey("w")) { v = 1.0f; }
        if (Input.GetKey("s")) { v = -1.0f; }
        if (Input.GetKey("a")) { h = -1.0f; }
        if (Input.GetKey("d")) { h = 1.0f; }

        rigidBody2D.AddForce(new Vector2(h, v) * speed);
    }

}
```

We're using a `FixedUpdate` because we're using physics on our game object. Had we not been using physics, the `Update` function would have been fine.

When any of the directional keys are pressed (not arrow keys), force is applied to the rigid body in a certain direction at a certain speed. If you ran the game and tried to move the player, you'd notice that it moves with a kind of sliding on ice effect. Rather than moving the player at a constant speed, the player increases speed as it builds up momentum and then when you release the movement keys it gradually slows down. This is because of the physics and the applying of force.

Moving the player into the obstacle will result in the player stopping.  We didn't even need to add any code to make this possible.

So let's look at moving the player without applying force. Change the `FixedUpdate` function to the following:

``` csharp
void FixedUpdate() {
    float h = 0.0f;
    float v = 0.0f;
    if (Input.GetKey("w")) { v = 1.0f; }
    if (Input.GetKey("s")) { v = -1.0f; }
    if (Input.GetKey("a")) { h = -1.0f; }
    if (Input.GetKey("d")) { h = 1.0f; }

    rigidBody2D.MovePosition(rigidBody2D.position + (new Vector2(h, v) * speed * Time.fixedDeltaTime));
}
```

Instead of using the `AddForce` method we are using the `MovePosition` method. We are now translating our rigid body which will also translate our game object position. We have to use the `fixedDeltaTime`, otherwise we risk our translations happening too quickly if the `FixedUpdate` is executed too quickly.

If you run the game, you shouldn't get the moving on ice effect, but instead nice smooth movement that stops as soon as you let go of the keys.

In both examples, the movement was limited to the letter keys on the keyboard.

If you want to move based on the typical WASD letter keys and the arrow keys, you could do something like this instead:

``` csharp
void FixedUpdate() {
    float h = Input.GetAxis("Horizontal");
    float v = Input.GetAxis("Vertical");

    rigidBody2D.MovePosition(rigidBody2D.position + (new Vector2(h, v) * speed * Time.fixedDeltaTime));
}
```

The above code will generate a value of -1.0, 0.0, or 1.0 depending on if the corresponding letter key or arrow key was pressed.

Just like with the `AddForce` method, when using the `MovePosition` method, the collisions between the player and the obstacle still happen.

## Conclusion

You just saw how to get started with Unity and building a simple 2D game. Of course what we saw in this tutorial wasn't an actual game, but it has all of the components that can be applied towards a real game.  This was discussed by [Karen Huaulme](https://www.twitter.com/youoldmaid) and myself ([Nic Raboy](https://www.nraboy.com)) in the fourth part of our [game development Twitch stream](https://www.youtube.com/watch?v=wDRf2jHrCPM).

The player movement and collisions will be useful in the Plummeting People game as players will not only need to dodge other players, but obstacles as well as they race to the finish line.

Learn how to get started with Unity for moving an object on the screen with physics and collisions.

Getting Started with Unity for Creating a 2D Game



<div class="introduction">

When it comes to game development, you should probably have some ideas written down before you start writing code or generating assets. The same could probably be said about any kind of development, unless of course you're just messing around and learning something new.

So what should be planned before developing your next game?

Depending on the type of game, you're probably going to want a playable frontend, otherwise known as the game itself, some kind of backend if you want an online component such as multiplayer, leaderboards, or similar, and then possibly a web-based dashboard to get information at a glance if you're on the operational side of the game and not a player.

[Adrienne Tacke](https://www.twitter.com/adriennetacke), [Karen Huaulme](https://www.twitter.com/youoldmaid), and myself ([Nic Raboy](https://www.nraboy.com)) are in the process of building a game. We think [Fall Guys: Ultimate Knockout](https://fallguys.com/) is a very well-made game and thought it'd be interesting to create a tribute game that is a little more on the retro side, but with a lot of the same features. The game will be titled, Plummeting People. This article explores the planning, design, and development process!

Take a look at the [Jamboard](https://jamboard.google.com/d/1CdF-ZbegRWjsttwLExgt5VZBNC0ss3SAEBsKMBX5a8Q/viewer?f=1) we've created so far:

![Game Development Planning Board](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/gamedev-jamboard.gif)

The above Jamboard was created during a [planning stream on Twitch](https://www.youtube.com/watch?v=XAvy2BouZ1Q) where the community participated. The content that follows is a summary of each of the topics discussed and helpful information towards planning the development of a game.

## Planning the Game Experience with a Playable Frontend

The game is what most will see and what most will ever care about. It should act as the driver to every other component that operates behind the scenes.

Rather than try to invade the space of an already great game that we enjoy (Fall Guys), we wanted to put our own spin on things by making it 2D rather than 3D. With Fall Guys being the basic idea behind what we wanted to accomplish, we needed to further break down what the game would need. We came to a few conclusions.

**Levels / Arenas**

We need a few arenas to be able to call it a game worth playing, but we didn't want it to be as thought out as the game that inspired our idea. At the end of the day, we wanted to focus more on the development journey than making a blockbuster hit.

Fall Guys, while considered a battle royale, is still a racing game at its core. So what kind of arenas would make sense in a 2D setting?

![Fall Guys Door Dash](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/fall-guys-door-dash.png)

Our plan is to start with the simplest level concepts to save us from complicated game physics and engineering. There are two levels in particular that have basic collisions as the emphasis in Fall Guys. These levels include "Door Dash" and "Tip Toe" which focus on fake doors and disappearing floor tiles. Both of which have no rotational physics and nothing beyond basic collisions and randomization.

![Fall Guys Tip Toe](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/fall-guys-tip-toe.png)

While we could just stick with two basic levels as our proof of concept, we have a goal for a team arena such as scoring goals at soccer (football).

**Assets**

The arena concepts are important, but in order to execute, game assets will be necessary.

We're considering the following game assets a necessary part of our game:

-   Arena backgrounds
-   Obstacle images
-   Player images
-   Sound effects
-   Game music

To maintain the spirit of the modern battle royale game, we thought player customizations were a necessary component. This means we'll need customized sprites with different outfits that can be unlocked throughout the gameplay experience.

**Gameplay Physics and Controls**

Level design and game assets are only part of a game. They are quite meaningless unless paired with the user interaction component. The user needs to be able to control the player, interact with other players, and interact with obstacles in the arena. For this we'll need to create our own gameplay logic using the assets that we create.

## Maintaining an Online, Multiplayer Experience with a Data Driven Backend

We envision the bulk of our work around this tribute game will be on the backend. Moving around on the screen and interacting with obstacles is not too difficult of a task as demonstrated in a [previous tutorial](https://developer.mongodb.com/how-to/maintaining-geolocation-specific-game-leaderboard-phaser-mongodb) that I wrote.

Instead, the online experience will require most of our attention. Our first round of planning came to the following conclusions:

**Real-Time Interaction with Sockets**

When the player does anything in the game, it needs to be processed by the server and broadcasted to other players in the game. This needs to be real-time and sockets is probably the only logical solution to this. If the server is managing the sockets, data can be stored in the database about the players, and the server can also validate interactions to prevent cheating.

**Matchmaking Players with Games**

When the game is live, there will be simultaneous games in operation, each with their own set of players. We'll need to come up with a matchmaking solution so that players can only be added to a game that is accepting players and these players must fit certain criteria.

The matchmaking process might serve as a perfect opportunity to use [aggregation
pipelines](https://docs.mongodb.com/manual/core/aggregation-pipeline/) within MongoDB. For example, let's say that you have 5 wins and 1000 losses. You're not a very good player, so you probably shouldn't end up in a match with a player that has 1000 wins and 5 losses. These are things that we can plan for from a database level.

**User Profile Stores**

User profile stores are one of the most common components for any online game. These store information about the player such as the name and billing information for the player as well as gaming statistics. Just imagine that everything you do in a game will end up in a record for your player.

So what might we store in a user profile store? What about the following?:

-   Unlocked player outfits
-   Wins, losses, experience points
-   Username
-   Play time

The list could go on endlessly.

The user profile store will have to be carefully planned because it is the baseline for anything data related in the game. It will affect the matchmaking process, leaderboards, historical data, and so much more.

To get an idea of what we're putting into the user profile store, check out a [recorded Twitch stream](https://youtu.be/XUQCOf3NuJQ) we did on the topic.

**Leaderboards**

Since this is a competitive game, it makes sense to have a leaderboard. However this leaderboard can be a little more complicated than just your name and your experience points. What if we wanted to track who has the most wins, losses, steps, play time, etc.? What if we wanted to break it down further to see who was the leader in North America, Europe, or Asia? We could use [MongoDB geospatial queries](https://docs.mongodb.com/manual/geospatial-queries/) around the location of players.

As long as we're collecting game data for each player, we can come up with some interesting leaderboard ideas.

**Player Statistics**

We know we're going to want to track wins and losses for each player, but we might want to track more. For example, maybe we want to track how many steps a player took in a particular arena, or how many times they fell. This information could be later passed through an aggregation pipeline in MongoDB to determine a rank or level which could be useful for matchmaking and leaderboards.

**Player Chat**

Would it be an online multiplayer game without some kind of chat? We were thinking that while a player was in matchmaking, they could chat with each other until the game started. This chat data would be stored in MongoDB and we could implement [Atlas Search](https://docs.atlas.mongodb.com/atlas-search/) functionality to look for signs of abuse, foul language, etc., that might appear throughout the chat.

## Generating Reports and Logical Metrics with an Admin Dashboard

As an admin of the game, we're going to want to collect information to make the game better. Chances are we're not going to want to analyze that information from within the game itself or with raw queries against the database.

For this, we're probably going to want to create dashboards, reports, and other useful tools to work with our data on a regular basis. Here are some things that we were thinking about doing:

**MongoDB Atlas Charts**

If everything has been running smooth with the game and the data-collection of the backend, we've got data, so we just need to visualize it. [MongoDB Atlas Charts](https://www.mongodb.com/products/charts) can take that data and help us make sense of it. Maybe we want to show a heatmap at different hours of the day for different regions around the world, or maybe we want to show a bar graph around player experience points. Whatever the reason may be, Atlas Charts would make sense in an admin dashboard setting.

**Offloading Historical Data**

Depending on the popularity of the game, data will be coming into MongoDB like a firehose. To help with scaling and pricing, it will make sense to offload historical data from our cluster to a cloud object storage in order to save on costs and improve our cluster's performance by removing historical data.

In MongoDB Atlas, the best way to do this is to enable [Online Archive](https://docs.atlas.mongodb.com/online-archive/manage-online-archive/) which allows you to set rules to automatically archive your data to a fully-managed cloud storage while retaining access to query that data.

You can also leverage [MongoDB Atlas Data Lake](https://www.mongodb.com/atlas/data-lake) to connect your own cloud storage - Amazon S3 of Microsoft Blob Storage buckets and run [Federated Queries](https://docs.mongodb.com/datalake/query/query-data-lake) to access your entire data set using MQL and the Aggregation Framework.

## Conclusion

Like previously mentioned, this article is a starting point for a series of articles that are coming from [Adrienne Tacke](https://www.twitter.com/adriennetacke), [Karen
Huaulme](https://www.twitter.com/youoldmaid), and myself ([Nic Raboy](https://www.nraboy.com)), around a Fall Guys tribute game that we're calling Plummeting People. Are we trying to compete with Fall Guys? Absolutely not! We're trying to show the thought process around designing and developing a game that leverages MongoDB and since Fall Guys is such an awesome game, we wanted to pay tribute to it.

The next article in the series will be around designing and developing the user profile store for the game. It will cover the data model, queries, and some backend server code for managing the future interactions between the game and the server.

Want to discuss this planning article or the Twitch stream that went with it? Join us in the [community thread](https://developer.mongodb.com/community/forums/t/gamedev-episode-1-designing-a-strategy-for-building-a-game-with-mongodb-and-unity/9179) that we created.

Learn how to design a strategy towards developing the next big online game that uses MongoDB.

Designing a Strategy to Develop a Game with Unity and MongoDB



<div class="introduction">

Did you know that MongoDB has a [Realm
SDK](https://www.mongodb.com/realm) for the
[Unity](https://www.unity.com) game development framework that makes
working with game data effortless? The Realm SDK is currently an alpha
release, but you can already start using it to build persistence into
your cross platform gaming projects.

A few weeks ago I [streamed](https://youtu.be/8S0NuFwFazY) about and
wrote about [creating an infinite
runner](https://developer.mongodb.com/how-to/build-infinite-runner-game-unity-realm-unity-sdk/)
type game using Unity and the Realm SDK for Unity. Realm was used for
storing the score between scenes and sessions within the game.

There were a lot of deep topics in the infinite runner (think Temple Run
or Subway Surfer) example, so I wanted to take a step back. In this
tutorial, we're going to spend less time making an interesting game and
more time including and using Realm within a [Unity](https://unity.com/)
project.

To get an idea of what we're going to accomplish, take a look at the
following animated image:

![MongoDB Realm with Unity Example](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/realm-example.gif)

In the above example, we have three rectangles, each of a different
color. When clicking our mouse on a rectangle, the numeric values
increase. If the game were to be closed and then opened again, the
numeric values would be retained.

</div>

<div class="prerequisites">

## The Requirements

There aren't many requirements to using Realm with Unity, and once Realm
becomes production ready, those requirements will be even less. However,
for now you need the following:

-   [Unity](https://www.unity.com) 2020.2.4f1+
-   [Realm SDK for
    Unity](https://github.com/realm/realm-dotnet/releases) 10.1.1+

For now, the Realm SDK for Unity needs to be downloaded and imported
manually into a project. This will change when the SDK can be added
through the Unity Asset Store.

When you download Unity, you'll likely be using a different and
potentially older version by default. Within the Unity Hub software, pay
attention to the version you're using and either upgrade or downgrade as
necessary.

</div>

<div class="content">

## Adding the Realm SDK for Unity to a Project

From GitHub, [download the
latest](https://github.com/realm/realm-dotnet/releases) Realm SDK for
Unity tarball. If given the option, choose the **bundle** file. For
example, **realm.unity.bundle-10.1.1.tgz** is what I'm using.

Create a new Unity project and use the 2D template when prompted.

Within a Unity project, choose **Window -> Package Manager** and then
click the plus icon to add a tarball.

![Unity Add Custom Package](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/unity-add-realm-sdk.png)

The process of importing the tarball should only take a minute or two.
Once it has been added, it is ready for use within the game. Do note
that adding the tarball to your project only adds a reference based on
its current location on your disk. Moving or removing the tarball on
your filesystem will break the link.

## Designing a Data Model for the Realm Objects Within the Game

Before we can start persisting data to Realm and then accessing it
later, we need to define a model of what our data will look like. Since
Realm is an object-oriented database, we're going to define a class with
appropriate member variables and methods. This will represent what the
data looks like when persisted.

To align with the basic example that we're interested in, we essentially
want to store various score information.

Within the Unity project, create a new script file titled
**GameModel.cs** with the following C# code:

``` csharp
using Realms;

public class GameModel : RealmObject {

    [PrimaryKey]
    public string gamerTag { get; set; }

    public int redScore { get; set; }
    public int greenScore { get; set; }
    public int whiteScore { get; set; }

    public GameModel() { }

    public GameModel(string gamerTag, int redScore, int greenScore, int whiteScore) {
        this.gamerTag = gamerTag;
        this.redScore = redScore;
        this.greenScore = greenScore;
        this.whiteScore = whiteScore;
    }

}
```

The `redScore`, `greenScore`, and `whiteScore` variables will keep the
score for each square on the screen. Since a game is usually tied to a
person or a computer, we need to define a [primary
key](https://docs.mongodb.com/realm-sdks/java/10.0.1/io/realm/annotations/PrimaryKey.html)
for the associated data. The Realm primary key uniquely identifies an
object within a Realm. For this example, we're use a `gamerTag` variable
which represents a person or player.

To get an idea of what our model might look like as JSON, take the
following:

``` json
{
    "gamerTag": "poketrainernic",
    "redScore": 0,
    "greenScore": 0,
    "whiteScore": 0
}
```

For this example, and many Realm with Unity examples, we won't ever have
to worry about how it looks like as JSON since everything will be done
locally as objects.

With the `RealmObject` class configured, we can make use of it inside
the game.

## Interacting with Persisted Realm Data in the Game

The `RealmObject` only represents the storage model for our data. There
are extra steps when it comes to interacting with the data that is
modeled using it.

Within the Unity project, create a **GameController.cs** file with the
following C# code:

``` csharp
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Realms;
using UnityEngine.UI;

public class GameController : MonoBehaviour {

    private Realm _realm;
    private GameModel _gameModel;

    public Text scoreText;

    void OnEnable() {
        _realm = Realm.GetInstance();
        _gameModel = _realm.Find<GameModel>("poketrainernic");
        if(_gameModel == null) {
            _realm.Write(() => {
                _gameModel = _realm.Add(new GameModel("poketrainernic", 0, 0, 0));
            });
        }
    }

    void OnDisable() {
        _realm.Dispose();
    }

    public void SetButtonScore(string color, int inc) {
        switch(color) {
            case "RedSquare":
                _realm.Write(() => {
                    _gameModel.redScore++;
                });
                break;
            case "GreenSquare":
                _realm.Write(() => {
                    _gameModel.greenScore++;
                });
                break;
            case "WhiteSquare":
                _realm.Write(() => {
                    _gameModel.whiteScore++;
                });
                break;
            default:
                Debug.Log("Color Not Found");
                break;
        }
    }

    void Update() {
        scoreText.text = "Red: " + _gameModel.redScore + "\n" + "Green: " + _gameModel.greenScore + "\n" + "White: " + _gameModel.whiteScore;
    }

}
```

In the above code, we have a few things going on, all related to
interacting with Realm.

In the `OnEnable` method, we are getting an instance of our Realm
database and we are finding an object based on our `GameModel` class.
The primary key is the `gamerTag` string variable, so we are providing a
value to query on. If the query returns a null value, it means that no
data exists based on the primary key used. In that circumstance, we
create a `Write` block and add a new object based on the constructor
within the `GameModel` class. By the end of the query or creation of our
data, we'll have a `_gameModel` object that we can work with in our
game.

We're hard coding the "poketrainernic" value because we don't plan to
use any kind of authentication in this example. Everyone who plays this
game is considered the "poketrainernic" player.

The `OnDisable` method is for cleanup. It is important to dispose of the
Realm instance when the game ends to prevent any unexpected behavior.

For this particular game example, most of our logic happens in the
`SetButtonScore` method. In the `SetButtonScore` method, we are checking
to see which color should be incremented and then we are doing so. The
amazing thing is that changing the `_gameModel` object changes what is
persisted, as long as the changes happen in a `Write` block. No having
to write queries or do anything out of the ordinary beyond just working
with your objects as you would normally.

While we don't have a `Text` object configured yet within our game, the
`Update` method will update the text on the screen every frame. If one
of the values in our Realm instance changes, it will be reflected on the
screen.

## Adding Basic Logic to the Game Objects Within the Scene

At this point, we have a `RealmObject` data model for our persisted data
and we have a class for interacting with that data. We don't have
anything to tie it together visually like you'd expect in a game. In
other words, we need to be able to click on a colored sprite and have it
persist something new.

Within the Unity project, create a **Button.cs** file with the following
C# code:

``` csharp
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Button : MonoBehaviour {

    public GameController game;

    void OnMouseDown() {
        game.SetButtonScore(gameObject.name, 1);
    }

}
```

The `game` variable in the above code will eventually be from a game
object within the scene and configured through a series of dragging and
dropping, but we're not there yet. As of right now, we're focusing on
the code, and less on game objects.

The `OnMouseDown` method is where the magic happens for this script. The
game object that this script will eventually be attached to will have a
[collider](https://docs.unity3d.com/ScriptReference/Collider2D.OnCollisionEnter2D.html)
which gives us access to the `OnMouseDown` method. When the game object
is clicked, we use the `SetButtonScore` method to send the name of the
current game object as well as a value to increase the score by.
Remember, inside the `SetButtonScore` method we are expecting a string
value for our switch statement. In the next few steps, naming the game
objects appropriately is critical based on our already applied logic.

If you're not sure where `gameObject` is coming from, it is inherited as
part of the `MonoBehavior` class, and it represents the current game
object to which the script is currently attached to.

## Game Objects, Colliders, and the Gaming Wrap-Up

The Unity project has a bunch of short scripts sitting out in the ether.
It's time to add game objects to the scene so we can attach the scripts
and do something interesting.

By the time we're done, our Unity editor should look something like the
following:

![Realm Unity Example, Editor](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/unity-inspector-realm-example.png)

We need to add a few game objects, add the scripts to those game
objects, then reference a few other game objects. Yes, it sounds
complicated, but it really isn't!

Within the Unity editor, add the following game objects to the scene.
We'll walk through adding them and some of the specifics next:

-   GameController
-   RedSquare
-   GreenSquare
-   WhiteSquare
-   Canvas
    -   Scores
-   EventSystem

Now the `Scores` game object is for our text. You can add a `Text` game
object from the menu and it will add the `Canvas` and `EventSystem` for
you. You don't need to add a `Canvas` or `EventSystem` manually if Unity
created one for you. Just make sure you name and position the game
object for scores appropriately.

If the `Scores` text is too small or not visible, make sure the
rectangular boundaries for the text is large enough.

![Resize Text Area in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/how-to/unity-resize-text-field.gif)

The `RedSquare`, `GreenSquare`, and `WhiteSquare` game objects are
`Square` sprites, each with a different color. These sprites can be
added using the **GameObject -> 2D Object -> Sprites -> Square** menu
item. You'll need to rename them to the desired name after adding them
to the scene. Finally, the `GameController` is nothing more than an
empty game object.

Drag the **Button.cs** script to the inspector panel of each of the
colored square sprites. The sprites depend on being able to access the
`SetButtonScore` method, so the `GameController` game object must be
dragged onto the **Score Text** field within the script area on each of
the squares as well. Drag the **GameController.cs** script to the
`GameController` game object. Next, drag the `Scores` game object into
the scripts section of the `GameController` game object so that the
`GameController` game object can control the score text.

We just did a lot of drag and drop on the game objects within the scene.
We're not quite done yet though. In order to use the `OnMouseDown`
method for our squares, they need to have a collider. Make sure to add a
**Box Collider 2D** to each of the squares. The **Box Collider 2D** is a
component that can be added to the game objects through the inspector.

You should be able to run the game with success as of now! You can do
this by either creating and running a build from the **File** menu, or
by using the play button within your editor to preview the game.

</div>

<div class="summary">

## Conclusion

You just saw how to get started with the Realm SDK for
[Unity](https://unity.com/). I wrote another example of using Realm with
Unity, but the game was a little more exciting, which added more
complexity. Once you have a firm understanding of how Realm works in
Unity, it is worth checking out [Build an Infinite Runner Game with
Unity and the Realm Unity
SDK](https://developer.mongodb.com/how-to/build-infinite-runner-game-unity-realm-unity-sdk/).

As previously mentioned, the Realm SDK for Unity is currently an alpha
release. Expect that there will be problems at some point, so it
probably isn't best to use it in your production ready game. However,
you should be able to get comfortable including it.

For more examples on using the Realm SDK, check out the [C#
documentation](https://docs.mongodb.com/realm/sdk/dotnet/quick-start-local/).

Questions? Comments? We'd love to connect with you. Join the
conversation on the [MongoDB Community
Forums](https://developer.mongodb.com/community/forums/).

</div>


Learn how to get started with the Realm SDK for Unity for data persistance in your game.

Getting Started with the Realm SDK for Unity

If you've been keeping up with the game development series that me ([Nic Raboy](https://www.nraboy.com)) and [Adrienne Tacke](https://www.twitter.com/adriennetacke) have been creating, you've probably seen how to [create a user profile store for a game](https://developer.mongodb.com/how-to/creating-user-profile-store-game-nodejs-mongodb) and [move a player around on the screen with Unity](https://developer.mongodb.com/how-to/getting-started-unity-creating-2d-game).

To continue with the series, which is also being streamed on [Twitch](https://www.twitch.tv/mongodb), we're at a point where we need to worry about designing a level for gameplay rather than just exploring a blank screen.

In this tutorial, we're going to see how to create a level, which can also be referred to as a map or world, using simple C# and the Unity Tilemap Editor.

To get a better idea of what we plan to accomplish, take a look at the following animated image.

![Unity Tilemap Level Example](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_tilemap_level_example_f544522660.gif)

You'll notice that we're moving a non-animated sprite around the screen. You might think at first glance that the level is one big image, but it is actually many tiles placed carefully within Unity. The edge tiles have collision boundaries to prevent the player from moving off the screen.

If you're looking at the above animated image and wondering where [MongoDB](https://www.mongodb.com) fits into this, the short answer is that it doesn't. The game that Adrienne and I are building will leverage MongoDB, but some parts of the game development process such as level design won't need a database. We're attempting to tell a story with this series.

## Using the Unity Tilemap Editor to Draw 2D Game Levels

There are many ways to create a level for a game, but as previously mentioned, we're going to be using tilemaps. Unity makes this easy for us because the software provides a paint-like experience where we can draw tiles on the canvas using any available images that we load into the project.

For this example, we're going to use the following texture sheet:

![Plummeting People Doordash Level](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/doordash_level_ae923dd2df.png)

Rather than creating a new project and repeating previously explained steps, we're going to continue where we left off from the [previous tutorial](https://developer.mongodb.com/how-to/getting-started-unity-creating-2d-game). The **doordash-level.png** file should be placed in the **Assets/Textures** directory of the project.

While we won't be exploring animations in this particular tutorial, if you want the spritesheet used in the animated image, you can download it below:

![Plummie Spritesheet](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/plummie_6065e6e27d.png)

The **plummie.png** file should be added to the project's **Assets/Textures** directory. To learn how to animate the spritesheet, take a look at a [previous tutorial](https://www.thepolyglotdeveloper.com/2020/10/animate-spritesheets-unity-2d-game/) I wrote on the topic.

Inside the Unity editor, click on the **doordash-level.png** file that was added. We're going to want to do a few things before we can work with each tile as independent images.

-   Change the sprite mode to **Multiple**.
-   Define the actual **Pixels Per Unit** of the tiles in the texture packed image.
-   Split the tiles using the **Sprite Editor**.

![Define Spritesheet Information in Unity](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_spritesheet_edit_0716a89e40.jpg)

In the above image, you might notice that the **Pixels Per Unit** value is **255** while the actual tiles are **256**. By defining the tiles as one pixel smaller, we're attempting to remove any border between the tile images that might make the level look weird due to padding.

When using the **Sprite Editor**, make sure to slice the image by the cell size using the correct width and height dimensions of the tiles. For clarity, the tiles that I attached are 256x256 in resolution.

![Unity Sprite Editor](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_sprite_editor_c1d14aeaee.jpg)

If you plan to use the spritesheet for the Plummie character, make sure to repeat the same steps for that spritesheet as well. It is important we have access to the individual images in a spritesheet rather than treating all the images as one single image.

With the images ready for use, let's focus on drawing the level.

Within the Unity menu, choose **Component -> Tilemap -> Tilemap** to add a new tilemap and parent grid object to the scene. To get the best results, we're going to want to layer multiple tilemaps on our scene. Right click on the **Grid** object in the scene and choose **2D Object -> Tilemap**. You'll want three tilemaps in total for this particular example.

![Unity New Tilemap](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_new_tilemap_43965a5517.jpg)

We want multiple tilemap layers because it will add depth to the scene and more control. For example, one layer will represent the furthest part of our background, maybe dirt or floors. Another layer will represent any kind of decoration that will sit on top of the floors — aay, for example, arrows. Then, the final tilemap layer might represent our walls or obstacles.

To make sure the layers get rendered in the correct order, the **Tilemap Renderer** for each tilemap should have a properly defined **Sorting Layer**. If continuing from the previous tutorial, you'll remember we had created a **Background** layer and a **GameObject** layer. These can be used, or you can continue to create and assign more. Just remember that the render order of the sorting layers is top to bottom, the opposite of what you'd experience in photo editing software like Adobe Photoshop.

The next step is to open the **Tile Palette** window within Unity. From the menu, choose **Window -> 2D -> Tile Palette**. The palette will be empty to start, but you'll want to drag your images either one at a time or multiple at a time into the window.

![Unity Tile Palette Images](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_tile_palette_images_2d48870d09.jpg)

With images in the tile palette, they can be drawn on the scene like painting on a canvas. First click on the tile image you want to use and then choose the painting tool you want to use. You can paint on a tile-by-tile basis or paint multiple tiles at a time.

It is important that you have the proper **Active Tilemap** selected when drawing your tiles. This is important because of the order that each tile renders and any collision boundaries we add later.

Take a look at the following possible result:

![Unity Tilemaps for Level Design](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_tilemap_layer_results_3c4a4df5de.jpg)

Remember, we're designing a level, so this means that your tiles can exceed the view of the camera. Use your tiles to make your level as big and extravagant as you'd like.

Assuming we kept the same logic from the previous tutorial, [Getting Started with Unity for Creating a 2D Game](https://developer.mongodb.com/how-to/getting-started-unity-creating-2d-game), we can move our player around in the level, but the player can exceed the screen. The player may still be a white box or the Plummie sprite depending on what you've chosen to do. Regardless, we want to make sure our layer that represents the boundaries acts as a boundary with collision.

## Adding Collision Boundaries to Specific Tiles and Regions on a Level

Adding collision boundaries to tiles in a tilemap is quite easy and doesn't require more than a few clicks.

Select the tilemap that represents our walls or boundaries and choose to **Add Component** in the inspector. You'll want to add both a **Tilemap Collider 2D** as well as a **Rigidbody 2D**. The **Body Type** of the **Rigidbody 2D** should be static so that gravity and other physics-related events are not applied.

After doing these short steps, the player should no longer be able to go beyond the tiles for this layer.

We can improve things!

Right now, every tile that is part of our tilemap with the **Tilemap Collider 2D** and **Rigidbody 2D** component has a full collision area around the tile. This is true even if the tiles are adjacent and parts of the tile can never be reached by the player. Imagine having four tiles creating a large square. Of the possible 16 collision regions, only eight can ever be interacted with. We're going to change this, which will greatly improve performance.

On the tilemap with the **Tilemap Collider 2D** and **Rigidbody 2D** components, add a **Composite Collider 2D** component. After adding, enable the **Used By Composite** field in the **Tilemap Collider 2D** component.

![Unity Composite Collider 2D on Tilemap](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_tilemap_composite_collider_2d_fcf5f8e3a9.jpg)

Just like that, there are fewer regions that are tracking collisions, which will boost performance.

## Following the Player While Traversing the 2D Game Level using C#

As of right now, we have our player, which might be a Plummie or might be a white pixel, and we have our carefully crafted level made from tiles. The problem is that our camera can only fit so much into view, which probably isn't the full scope of our level.

What we can do as part of the gameplay experience is have the camera follow the player as it traverses the level. We can do this with C#.

Select the **Main Camera** within the current scene. We're going to want to add a new script component.

Within the C# script that you'll need to attach, include the following code:

``` csharp
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class CameraPosition : MonoBehaviour
{

   public Transform player;

   void Start() {}

   void Update()
   {
      transform.position = new Vector3(player.position.x, 0, -10);
   }
}
```

In the above code, we are looking at the transform of another unrelated game object. We'll attach that game object in just a moment. Every time the frame updates, the position of the camera is updated to match the position of the player in the x-axis. In this example, we are fixing the y-axis and z-axis so we are only following the player in the left and right direction. Depending on how you've created your level, this might need to change.

Remember, this script should be attached to the **Main Camera** or whatever your camera is for the scene.

![Unity Camera to Player Transform](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/unity_camera_transform_71b2136131.jpg)

Remember the `player` variable in the script? You'll find it in the inspector for the camera. Drag your player object from the project hierarchy into this field and that will be the object that is followed by the camera.

Running the game will result in the camera being centered on the player. As the player moves through the tilemap level, so will the camera. If the player tries to collide with any of the tiles that have collision boundaries, motion will stop.

## Conclusion

You just saw how to create a 2D world in Unity using tile images and the Unity Tilemap Editor. This is a very powerful tool because you don't have to create massive images to represent worlds and you don't have to worry about creating worlds with massive amounts of game objects.

The assets we used in this tutorial are based around a series that myself ([Nic Raboy](https://www.nraboy.com)) and [Adrienne Tacke](https://www.twitter.com/adriennetacke) are building titled Plummeting People. This series is on the topic of building a multiplayer game with Unity that leverages MongoDB. While this particular tutorial didn't include MongoDB, plenty of other tutorials in the series will.

If you feel like this tutorial skipped a few steps, it did. I encourage you to read through some of the previous tutorials in the series to catch up.

If you want to build Plummeting People with us, follow us on [Twitch](https://www.twitch.tv/mongodb) where we work toward building it live, every other week.


Learn how to use Unity tilemaps to create complex 2D worlds for your game.

Designing and Developing 2D Game Levels with Unity and C#

Persisting data is an important part of most games. Unity offers only a limited set of solutions, which means we have to look around for other options as well. In this tutorial series, we will explore the options given to us by Unity and third-party libraries.

Unity

Featured

Saving Data in Unity3D Using SQLite

Saving Data in Unity3D Using PlayerPrefs

Sending and Requesting Data from MongoDB in a Unity Game

All Unity Content