Week03 - Architecture, Performance, and Games

1.) Software architecture is the organization of a project. In Unity, this means having separate functions and folders for scripts and assets.

2.) When prototyping, your primary goal is to iterate on what you have and figure out what works, what doesn't, and what to keep as a result of this. This conflicts with the best practices of software architecture because removing and adding elements constantly can interfere with the organization of your game, and in addition, good software architecture calls for elegant code, and when prototyping, there isn't always time for elegant code. 

3.) De-coupling is making pieces of code separable from one another so you could delete one and have the other run, and it's essential for software architecture so you can destroy a piece of your game if it needs to be cut and the rest of your structure will stay standing. 

4.) In my own games, I've had code that looks like this:

GetComponent<Rigidbody> ().velocity = new Vector3(GetComponent<Rigidbody> ().velocity.x,GetComponent<Rigidbody> ().velocity.y, 0f);

This is extremely inefficient and hard to look at it. I could easily apply simplicity, define the Rigidbody in start(), and refer to it as "playerRB" in the three times I mention it here.