Gamedev Log: “Slash’n’crack” #6 (Unity/C#)

A step-by-step log of how I made a basic Unity/C# game: “Slash’n’crack”!

This article is also available on Medium.

This past couple of weeks, I’ve posted several gamedev logs to share how I’m currently developing a simple Unity/C# mobile game: Slash’n’crack!

For this dev challenge, I have a tight time constraint: I only have 8 hours to make the entire game, from start to finish!

And, during the first five hours, I got down all the core features I wanted. I now have a full, although basic, version of my game in which I get an endless wave of asteroids coming at me, that I can slash to destroy, which gives me points… are that will reduce my number of lives if they get passed and exit the screen. Then, if I reach 0 lives, it’s game over!

Today, I’m going to take a step back and work on the overall organisation of my project and on setting up a multi-scene workflow so that the player first arrives in a main menu and can then switch to the actual game…

Hour #6: Setting up a multi-scene workflow, a main menu and nice scene transitions

Features & demo

Just like last time, a lot of in this episode will be about UI and pixel-art assets imports. But, this time, there is also a bit of “high-level logic” I want to take care.

Namely, I want to take advantage of the Unity 5+ new scene system to integrate my game into a multi-scene workflow and easily switch from the main menu to the game scene. If you’re not familiar with this notion of multi-scenes, you can check out this other article I wrote a while ago on the topic 😉

The basic idea is to “overlay” several Unity scenes; the combination of all these small chunks of data allow me to quickly share global data but still separate the different logic units in a maintainable way. For more info on my multi-scene workflow, feel free to take a look at the “tips & tricks” section below.

I also want the scene to transition smoothly, rather than directly cutting to the next one; so I’ll need to implement some kind of “fade-to-black” logic to get a nice effect 🙂

And finally, I have to make sure that, in my game scene, in the Game Over panel, my “Quit” button sends me back to the menu instead of directly closing the application so that I have a full user workflow.

After creating and linking these new scenes, and adding some UI panels and buttons, I now have a simple “menu-to-game” player experience that makes for a smoother introduction, and a more professional-looking app:

Of course, this main menu could have some additional elements like a title, a logo, etc. But I’m out of time, so this will be for the next episode 😉

During the next hour, I will therefore work on miscellaneous features and improvements: I will finish my main menu, add a little intro text and a pause system in my game scene and give my asteroids different colours depending on their “level”, which will determine how many times to need to slash them before they are completely destroyed…

A few details, tips & tricks

My multi-scene workflow consists of 3 scenes: the “Core”, the “Main Menu” and the “Game”.

The “Core” scene is the first that is loaded, and it is in charge of, in turn, loading the rest of the scenes in additive mode. This is essential because it allows me to keep my “Core” scene in the background and have it contain all my global data and/or shared Singletons.

The “Main Menu” and “Game” scene each contain the elements specific to these two contexts: the “Main Menu” has a UI canvas with two buttons and a background, and the “Game” has all I’ve prepared up til now – except some general scripts that should only be instantiated once, like the EventManager, and that I’ve moved to the “Core” scene.

The other scenes are loaded thanks to a new C# script, the SceneBooter, that basically unloads the current data and replaces it with the right one to reconstruct either the full menu or the full game scene.

For now, “Core” contains 3 things:

  • a “CORE” empty game with the EventManager and SceneBooter scripts attached on it
  • a UI canvas with the “SceneTransitioner”; this is a simple UI image that I toggle on and off when I switch between scenes to get my fade-to-black effect
  • the EventSystem associated with this UI canvas – and that I moved from the “Game” scene

For the fade-to-black scene transitions, I’m using C# coroutines to make UI animations via scripting. As I’ve already detailed in a previous article, this is more efficient than using built-in Unity animations and, here, it lets me “sandwich” the actual scene loading process in-between the fade-out and fade-in of the black screen.

The “Main Menu” scene is very basic, too, since it just has a camera and a UI canvas with the two “Play” and “Quit” buttons:

The little trick is to make sure to remove the “Main Camera” tag on the menu’s camera, so that Unity doesn’t get confused when I load my “Game” scene. Otherwise, during the brief moment where both scenes are loaded (i.e. just before the SceneBooter has unloaded the “Main Menu”), I will have two main cameras and Unity will output a bunch of bad warnings 😉

Also, even if I don’t yet have audio in my game, I can’t have several instance of an “AudioListener” component – so I can actually move it from my two cameras to the “Core” scene, and add it on an “AUDIO” empty game object.

Conclusion

As usual, although I have figured out most of what I want to do for this game (in terms of features, gameplay, art style, etc.), I might come up with unexpected ideas along the way… and, of course, I’d be really happy if you’d participate, too, so feel free to leave comments with cool ideas for Slash’n’crack!

I hope you like this series of Gamedev Logs, and I’ll see you in a couple of days for the next one 🙂

Leave a Reply

Your email address will not be published.