Constraints make us Creative — From Prototype to Production

Objective: Convert the game to production stage

Till now, we worked with squares and capsules, keeping everything simple and clean but we managed to have a moving, shooting player, lasers that can hit enemies and enemies that can kill us!

This is basically what this kind of game needs, as a start. It may even be considered funny (well, maybe if you’re used to 1980’s games). Without defining it, we almost made what may be called a minimum viable product, sort of.

It has just the minimum features that allow to enjoy it (move, shoot, destroy). A good question would be: why did we not start with good quality graphics, animations, sounds, funny side features and so on?

The answer is quite simple: we are learning. While learning or simply doing something new (such as a new game style) an important thing to control is the scope. Our scope. In this first attempt of creating a game we simply cannot aim at a triple A level product. Instead we have to keep our scope small and design the game around our knowledge and skills, while improving them.

In order to do so, we just got rid of everything but the minimum, the essential. We started building a raw game, without fancy assets, but focusing on mechanics.

In my opinion, good assets make the game beautiful but good gameplay makes it funny and I think this is way more important, since the key feature of the game is playing it.

But now we can move forward, we can put some cosmetics and, why not, also new funny features.

Let’s start importing some assets into the project view. I divided them in sub folders to keep everything clean. The first thing we’re going to need are sprites, to replace square and so on.

Now I have a sprite for the enemy, one for the laser, one for the player and a background ready to go.

Let’s start the replacement. In the player inspector I’ll remove the sprite renderer component, and the collider too. Then, I’ll add a new sprite renderer and set the sprite with the one of my choice, and a new polygon collider.

The polygon collider will find a solution and calculate the vertex of a polygon approximating the sprite. If you click on the Edit Collider button you’ll have a preview. The same can be done for the enemy.

The laser is going to have the same destiny, but a box collider will be enough. Notice that I modified the box collider, narrowing it and excluding part of the glow: it seemed a better choice for me.

After that, I suggest also to tweak again the scales in transform component to reach again the right proportions and the speed valuesg.

Before going to the background sprite, let’s also introduce the layers and sorting of layers. Since this a 2D game, the z component of almost anything is going to be neglected and all the objects are just like foils.

However, it is possible to have a sort of depth management using the layers: each foil (2D gameobject) belongs to a layer, marked with a name and an order level. Sprites with a greater order level will appear on top of lower ones.

There is section in each sprite renderer component in which you can assign a sorting layer and an order. Let’s create a Ships layer, now we have two layers, the new one and the Default one, clearly one on top of the other.

So everything on default layer will appear behind anything on Ships layer. The order level will provide an ordering between sprites on the same layer, the greater the level the more sprite will appear in front of the others. Let’s assign all three sprites (player. enemy from prefab, laser from prefab) to the Ships layer and with the same order: in this way we can avoid lasers going under enemies and so on.

Background Sprite

In order to also have a nice galactic background, I want you to remember that we based most of our visuals on camera settings. We’re going to do the same. Let’s drag and drop the sprite onto the camera gameobject to set a parent-child relationship. Ensure that both the camera and the sprite have x=y=0 and opposite values of z.

Time to code. What we want is to have the sprite rescaling according to changes in camera visual bounds, in the same fashion we did for player movement bounds.

In the CameraBounds script, let’s add a couple of variables: the sprite, the scale and the position of the sprite.

Let’s grab the sprite renderer component.

And modify the UpdateCameraVisual method.

X and y component of the scale should be the same in order to keep sprite proportions. The way we calculate the scale is simpler than it looks: just grab the formula we used to get world size camera visual and invert it to find the scale, also remember to multiply by two, since the camera visual are always half the width and height. Ensure the position by setting the localPosition of the sprite to be the opposite of camera world position.

Let’s have a look.