Aaaaand, CUT! That’s a Wrap Folks! Project 2 DONE!
Welcome back friends! It’s day 31 of my journey into Software Engineering and Game Development and today, today is a GLORIOUS DAY!
Why? You may be asking? Well, I mean it’s in my title, but I’ll tell you anyways.
After working my butt off today, I was able to do it.
Its.
Done.
Yes. It’s not perfect, and there are a few more tweaks that I’d like to do, but for the game itself is finished and can be successfully built into a functioning free standing game!
So may I present,
The Great Fleece: By Ryan Yamura at GameDevHQ
Sniffle… They grow up so fast. I remember the days when Darren was just an idea, just a 3D capsule sliding along the carpets of the Beatrice Auction House…
When lighting issues plagued my game…
But now, its all done, and it feels great! There was no better feeling than pressing play in Unity and running through the game for the first time. Well there was a better feeling, when it was all said and done and IT ALL WORKED!
So what exactly did I do today in my world of development?
A lot of management.
First up: The Game Manager.
This aspect of the UI controlled how it functions when you have a game over or a win. Basically making it so the buttons that you see when you’re caught, or victorious work, so you may choose to restart the game or quit out of the application. While the coding for this looks quite simple, it actually had a quite complicated design behind it.
The concept behind this, is called the Singleton Pattern or Design. It’s one of the most common design patterns in software development and design. A Singleton pattern ensures a class has only one instance int he program and provides a global point of access to it. It only allows a single instance of itself to be created and gives simple access to that instance. This is ideal for a Game manager system as it allows for certain vales that are in the manager to be gotten by all the scripts in the scene, and has the option of executing extra lines of codes for design or implementation while these parameters are being called publicly. It allows you to control the privacy of these parameters as well.
To be completely frank, I don’t quite yet have my head completely wrapped around this design, and I know there’s a lot more I need to research on it’s implementation. But, I do know its a great design to simplify how parameters are shared between the game objects and classes. This game manager allowed me to have a boolean be shared across my scripts so I could set if the Player could win the level if they had the security key card necessary in order to open the final vault.
This is also where I allowed a public input in order to give functionality to the skip cut scene script written at the bottom left of the screen during the introduction cut scene. Which uses the namespace/library: UnityEngine.Playbles in order to manipulate the timelines in the scene via C#.
Finally, with all the functionality in the main game scene done and working, I moved on to animating and creating a main title screen and loading screen for the initial game launch.
While at first this seemed to be pretty straight forward, with simple animations, things quickly got complicated.
Challenge:
- Create a function to act like a “Loading Screen” and implement a visual aspect to it using the assets provided.
This in itself resulted in the research and implementation of a new Scripting API:
An asynchronous operation is a coroutine that can run parallel to other game systems, useful for “loading” scenes. The progress of these load times can be visually valued using different methods, like strings and images, which in themselves have many clever ways to be implemented. Such as a loading wheel image, or a progress bar, percentage output, etc.
You can check the progress the load by first creating a variable for the asynchronous coroutine, then calling it’s properties.
Properties such as:
- isDone — is the operation finished?
- Priority — let’s you tweak in which order async operation calls will be performed.
- Progress what’s the operations progress: read-only.
By linking a UI image to the progress property of the Async Coroutine and setting the image type to fill, this was how the result of filling the bar according to progress was achieved.
Blockers:
- Wrapping my head around Asynchronous coroutines.
It really does look so simple when all is said and done but the Unity scripting AI documentation has very little explanation and just links to the different properties and their uses.
Victories:
- Getting it all to work!
I have no doubt that this will probably be the single most used thing in future games, especially larger games which require longer load times. I am fortunate to have a pretty powerful computer so the load times for this game were pretty non-existent, but there are some games that I play where it can load anywhere from 20–30 seconds before the scene is fully in.
And with that, I just wanted to say thanks for reading, and following my journey. There has been so much support and kind words offered, and it really means the world to me. So to you, thank you.
Looking forward to what tomorrow brings!
— Ryan
A meat Popsicle.
