[Day 3/4] Transitions and Animations
We will be using a scene transition to define the game over state, and then we will add Guzman into the game after a short photoshoot.
Scene Transition
Actually, loading scenes is pretty easy for the scope of this project. When the game is over, we will transition from the game scene to the results scene. This concept is similar to that in GameMaker: Studio, where scenes were called rooms. In GM:S, there is a built-in function called:
room_goto(index)
that transitions from one room to another. In Unity, we can use the Scene Manager:
SceneManager.LoadScene(index, LoadSceneMode.Single)
to load the next scene in the same manner.
The challenging part was finding the equivalent of passing certain existing objects into the next scene. In GM:S, we can make an object "persistent" and pass it over from the old scene to the new scene, then un-"persist" it at the new scene. In Unity, we could mark the object with "DontDestroyOnLoad" and pass it over to the new scene. "DontDestroyOnLoad" in Unity has the same behavior as persistence in GM:S, so that was not difficult to implement.
I decided to mark a single GameObject as my "global" object to pass around to all scenes. This is usually not a good practice, but since my game is simple and only has at most three scenes (title, game, results), I don't see this as a big deal. Maybe it's just my GM:S logic kicking in to Unity. Anyways, this global object holds two variables at the moment: "game over", a bool; and "score", the number of home runs recorded in the game scene.
Animation
Now, GM:S is primarily a 2D game engine, and for the most part I've been using that engine to make games. Thus, all of the "sprites" are in 2D, and there was no need for 3D modeling. Now that we're making a 3D game, a dilemma arises. How in the world can I make my own 3D models? I could ask the Discord or learn how to draw up a model myself- but instead, I decided to try something that old 3D games used to do...
Use 2D sprites of 3D models! And actually, I'm not even drawing those 2D sprites. I figured that if Guzman was going to be in the game... well, why not just take pictures of him swinging?
I'll let the pictures describe the rest.
Using the Unity animator was probably the hardest thing in the world. But this was probably because I was used to the way GM:S handled sprites and their respective animations. I do appreciate the fact that an "Animator" object in Unity can define states such that the animations in those states do not necessarily need to be programmed in user scripts. Specifically, Guzman only had two animations (idle and swing) and I was able to transition between states using little code.
Since I cheated the entire 3D modeling world by making 2D representations of real-life models, effectively turning this game into some sort of Nintendo 64 knock-off, I had to alter the angle of the main camera such that the Guzman sprite was actually standing in the batters box. The bat remains in 3D. More tweaking of this hybrid sprite/bat combination will probably happen towards the end of development.
Next
Now that we at least have a cheap animation of Guzman and have implemented it into the game, we can focus on the mechanic I decided I wanted to add a twist to: bat power. This will make the game a little bit more interesting. How will I implement this power mechanic without making complex the controls? (We want the game to be controlled with one button only, and the mouse/touch.)