Architecture, Performance, and Games


Software architecture is how your code is organized; the practicality and efficiency of your code's construction. As game developers, we know that games break A LOT so having an organized set of instructions is essential in attempting to fix those instructions in a quick, easy way. If I know what's wrong with my game and my code is deliberately placed, it should be easy to pinpoint the exact variable I need to change. However, when prototyping, you want to implement your ideas quickly: get an idea, make it happen, see what works, tweak, and repeat. This process has an inherent structure that doesn't always encourage pauses to architect nice code. It's about doing, not necessarily doing well so the idea of software architecture is sometimes put on the back burner. 

That being said, decoupling is when you visit that back burner and let things burn up front; it's the practice of going back and making lines of code independent so they have meaning on their own. This is important because when that infamous game break does happen (and it will) there might be a single line of code that needs fixing and if your code is "coupled," you may end up changing more things then you wanted to since a change to dependent lines affect both. 

Here is some code for a game of brick breaker within a game where you sit on the subway:

        bool resetting = resetter.GetComponent<resetGameButton>().reset2;
        bool resetting2 = resetter2.GetComponent<resetGameButton>().reset2;

        if (resetting == true)
        {
            if (ableToBeReset)
            {
                life = 3;
                GameObject.Find("gameManager").GetComponent<GM>().brickNumber = 12;
                gameOver.SetActive(false);
                ableToBeReset = false;
            }
            resetting = false;
        }

        if (resetting2 == true)
        {
            if (ableToBeReset)
            {
                life = 3;
                GameObject.Find("gameManager").GetComponent<GM>().brickNumber = 12;
                winGame.SetActive(false);
                ableToBeReset = false;
            }
            resetting2 = false;
        }


There are a couple things wrong with this code, starting with the fact that I needed too resetting booleans for one reason or another? Whatever problem I must've had was definitely not solved very elegantly with the implementation of a new, almost identical variable. Simplifying this would decrease redundancy and ultimately  make things easier to change had I needed to change more things withing the game, considering there are multiple things that change with every instance of resetting. It also looks like the booleans are tied to the exact same game object so, for whatever reason I did this, I can guarantee I just made things more complicated for myself. And I promise you that I did spend my entire birthday working on this project trying to fix things that were caused by (what I'm sure was) similar negligence. 

THUS why code architecture, while not to be doted over, can prevent a lot of stress in the long run if you give it just a little extra TLC on the way.

Comments

Log in with itch.io to leave a comment.

👍