"Hello, Ducklings!
Madame Evil, Amanda, here to introduce our new EVIL affiliate! We here at EVIL Quacks studios thought we weren't exploring the full potential EVIL could mean. So we decided to add a master of the dark occult arts to our team!
We found them in a sunken dungeon under the pond lair...we're not sure when's the last time he got out, but he's here now to help with our Schemes!
And with that, I'll turn it over to him!
- Amanda D. Barbadora"
New EVIL Approaches!
The team of EVIL Geniuses summoned a new minion just in time for the week of Friday the 13th!
Greetings, Ducklings! It's nice to meet you, muahahaha! I'm here to give you your first update from the depths of the Dungeons of Programming. Beep Boop Meow!
Why were you summoned, oh master of the Dark Arts?
What an EVIL question! With structural changes to S.A.M. in the works, we decided to design a whole new approach to EVIL Development so any new Schemes we concoct can be quickly prototyped and implemented right from the get-go. This means that we're working to completely overhaul our backend design in two places:
General code structure for any and all projects
Game or app-specific structures that can be swapped around as necessary
That sounds like a lot of EVIL work...
Oh, it is, but let's break it down!
I know Madame EVIL showed this a few days ago, but I wanted to remind you all of the high-level design to better describe it with visuals:
We designed our general structure to achieve a few specific goals:
The EVIL word of the day is MODULAR!
We want it to be a template for any project. This will allow us to customize what modular pieces we include on a per-project basis without reaching into the code.
An EVIL example perhaps?
Another game we make might not need Multiplayer, but will still need access to accounts and cloud saves. These can all be togglable options that we choose on a need basis on project initialization. This also allows us to create a generic metadata file to pull-in and save APIs for in-code use since each project will have both recycled and custom API calls
So long as your EVIL we don't judge...*
Some of the teams EVIL geniuses are geniuses in other areas outside the Dark Arts of Code.
This structure should allow for them to easily change object settings, edit resource files, etc without needing a copy of Madame EVIL's Step-by-step Guide to Witchcraft, and they can stay doing what they're most EVIL at since most of the art and assets will live on standard Unity components and objects
*But we do judge your number of Monobehaviors...
We're also hoping to limit the number of Monobehavior files that live in-scene. Monobehaviors have multiple loops that run once every frame (sometimes more than once with updates relating to the Physics engine). Even if we don't override these loops for custom code, they will still try to fire. This can cause lots of loops to try to run while also processing physics, visuals, etc, 60+ times per second! We're EVIL, but not that EVIL!
You see ducklings...
Instantiating and destroying Monobehaviors is very resource-heavy, so minimizing the number of times we do this will optimize the code for a more consistent EVIL experience
Some components must be Monobehaviors as dictated by the engine itself.
These include:
Views: used for editing things in-scene and can't be avoided
Input Receiver: because of the way Unity handles input, but we'll look into this
Unity-specific: Some objects have innate Monobehaviors that can't be avoided
But what about the Arcane Horror: Load Time?
Don't worry ducklings, we're considering that too.
Along with keeping the number of Monobehavior objects down, we're also looking to minimize the number of scene loads to keep mass Monobehavior instantiation and destruction to a minimum. Because of this, the Main Scene will hold all of the base managers and controllers, and will always exist and never unload.
Ok but why...?
This helps with not destroying and re-instantiating files, resources, etc except for initial load only and this helps maintain limits to managers and cameras, etc while still allowing us to change properties in the editor.
Ok, but what about that manager design you showed us twice now?
We'll talk about that right now, Ducklings!
The Game Manager itself is kind of like the Boss of the Project; it will know of and connect to all the other managers and controllers the project needs to function.
The Scene Manager will be used for loading and unloading individual levels and areas (on top of the scene that never changes).
The Sound Manager will allow access to music and sound effects assets. As well as determine when to play them, how many can exist in the scene, and which ones have priority.
The Character Controller will hold the logic for any type of character, AI or otherwise. For any character that is controlled specifically by the player, there will be separate logic that lives under the Character Controller to allow for controller, keyboard, or touch inputs
The Network Controller will house things like notifications, APIs, cloud services, and Multiplayer code. This will have togglable features depending on the project and its needs
The Event Manager is the only piece that doesn't work directly under the Game Manager. This component will allow all of the other controllers and their child parts to converse with each other and request things without the scripts directly touching one another. Consider it like sending an email asking for something to get done. This allows each other component and sub-component to stay "hidden" from the other components but still able to request sounds in the middle of a character's animation.
Again, this sounds like a lot of EVIL work...
Oh, it is, but once we complete this general template, it will allow us to focus on the "fun" parts of coding. As these parts are completed, they should also be modular enough to pick up and drop into another game!
Imagine it ducklings...
Inventories can be as simple as a list of powerups or as complex as Skyrim or other RPGs. With a basic inventory structure, we can help ease dev times of any other project type! Remember the word of the day is modular. We're striving for a design with modular components that can be picked up and placed where ever!
WHEW!! That was a whole lot of EVIL! Hopefully, that helped give more insight into our Terror-ific ideas and how we plan on moving forward with S.A.M. and other EVIL Schemes we cook up!
That's all I have for you for now, so take care and stay EVIL, Ducklings!
"Madame Evil here again.
Wow! Quite a blog post for his first one, right? We hope you'll hear more from him and show him the same EVIL support you show the rest of us.
Quick note!
Special thanks to Alex Hollander for teaching me about custom Event Managers. The Event Manager Evil Quacks uses is heavily influenced by his and I owe all my knowledge with that to him. Check him out when you get the chance!
Thanks, ducklings! Remember to be your true EVIL selves."
Comments