Big Game Project – Week 6

This week we had an internal Beta deadline on Friday, so we wanted to have most of the game complete so we can focus on polishing the last weeks until Gotland Game Conference.

I worked a lot with the world map this week. First I implemented the proper progressing system through levels, and then I continued to work on the world map bonuses. The player gains them for holding an area on the map, and they are random every playthrough. I explained them slightly last week, but some areas on the map have a resource and a number on them. The player gains increased resources (by the number amount stated) when matching that resource as long as the area is under control. Eventually the enemy troops will try to take it back (refer to Invasion System on last week’s post), and you will have to play that level again to defend against them to keep it.

Here’s a screenshot of one of our current levels.

Audio Manager

In the beginning of the week we made a list of things we wanted finished for the Friday deadline, one of them was to implement all sounds and music that we had. Some sounds were already in, so putting a couple more of them doesn’t sound like a problem, does it?

It wouldn’t have been if we didn’t load new scenes for every menu and played a sound just before doing so. This meant that the sound was cut off since the new scene was loaded and the object that was playing the sound was destroyed. This problem wasn’t really something we needed to solve by itself, though, since we were going to make an Audio Manager anyway. The Audio Manager was going to handle all playing of sounds and music, as well as eventually restricting certain sounds from playing too often. This helps when the player has a lot of towers all shooting at the same time in the game.

Since we have a scene for every level and menu, we use a class called Blob to send information between them (because it holds all sorts of information for various objects), and I had made that into what I thought was the best solution for a Singleton in Unity. Singleton is a Design Pattern that restricts the instantiation of a class to one object and makes it global, letting the whole application access it. Singletons are very useful when there will only ever be a single instance of something, but a lot of classes need to access it. The Blob It wasn’t really a Singleton since all objects that needed to refer to it needed to have their own variable to hold it, but at least there couldn’t exist more than one Blob.

I realized I could either make the Audio Manager the same as the Blob, or try to make it into more of a static class that everything in the project could access. After all, there would only be one Audio Manager and it would be handling all playing audio. So I first tried to copy an actual singleton, having an instance that it created itself and everything else referring to it. This didn’t work out since we wanted to fill the list of sounds from the inspector, for easy managing.

So I tried to have the object already created on the first scene, but this meant that every time the player went back to the main menu another Audio Manager would be created, resulting in multiple music tracks playing.

Grid – Pseudo-Singletons for Game Engines

When I started looking for solutions I found something called Grid. Grid is described as “a handy class which allows you to ‘call other stuff easily’”. When I first implemented it I didn’t believe how simple it was.

Grid is a static class that creates static variables of your classes you want to make into “Singletons” and then sets those to the existing ones on the scene by GameObject.Find(). Playing a sounds, in this case, is now done through calling Grid.audioManager.PlaySound().

The end result is that the Main Menu class creates a Blob and an AudioManager the first time it’s run, and then Grid sets it’s public variables to those existing objects. I definitely recommend looking up Grid if you have any sort of need for this.

Until next time!