Common Mistakes when coding Games

Hey everyone! Its Shelby from the Submersion development team and I have returned from the long month and a half development cycle. We are rapidly approaching the release of our game Not So Trash Panda so definitely stay tuned for when the game becomes formally available!

With our game being a little over a week away from release, I believe its important to discuss what can (and will) occur during the development cycle, and that is bugs! Bugs are going to occur in any level of software no matter how basic or complex it is, and given that we are developing a game, ours was filled with them! So how about I go through and list some of the major bugs that occurred, what caused them, and how to fix them!

So what exactly defines a bug?

A bug is defined as any unintentional behavior presented by the software. There are multiple different types of bugs, but the common two types are Syntax Errors and Logic Errors. 

A syntax error occurs when the developer miswrites their code, causing it to not even function. In game development these types of errors typically won't let you even playtest your game because it won't compile. 

A logic error occurs when the developer provides the software with instructions that end up with an unintended result. In this case, the code will compile meaning the user can test the code, but the end result will not be what they expected it to be. In my opinion, logic errors tend to be a little trickier to dissect, as you may not know how to actually fix the code to get your desired result. With that being said, here are a couple of tips I can give you for Unity Engine related bugs.

Race Conditions

One of our major issues came from race conditions. These are conditions in which a strand of code is not able to get called because multiple pieces of necessary code are being called across multiple scripts. This can happen quite often when using Unity if you aren't careful.

Unity has an order for how it's default functions get called:

In previous devlog's, We've mentioned the Start() function and the FixedUpdate() functions, but Unity has a few other major functions that can be used to call script. As you might see in the image above, when you load your software in Unity, Start() is actually called third in the order of operations. Awake() is called as that script is being loaded, whereas Start() calls once the game is fully loaded.

A common issue that we ran into with our code was calling most of our major functions from just Start(). This led to issues where scripts could not reference variables from other scripts on Start() because they didn't actually exist yet. The best solution to this issue is to simple split up your code between scripts into either Awake() or Start(), depending on what is being called. For example, if you wanted an object to be found on load time from one script, and then have that object be accessed by a different script post load, you would call the finding function in Awake(), and the accessing function in Start().

Clipping through Colliders

In my previous devlog in which I taught you how to make 8-directional movement, I taught you all how to code in a somewhat flawed way. The vast majority of the code is still accurate, however if you are making your own video game, you might have noticed that you can walk up to corners and phase right through them pretty easily. This is because we are not using a Rigidbody to control our player movement. When we originally designed the player movement, we directly changed the position of the player by changing the transform.position of our object. This means that technically speaking, the player is teleporting a very small amount in a microscopic amount of time, which means that the player can technically teleport into and through a collider in front of it. This is bad coding and I apologize for misinforming you all, lets fix that shall we?

For this, we are going to be using a Rigidbody to control our player movement and instead of changing the transform.position of our object, we are going to change the Rigidbody.velocity of our Rigidbody attached to the object. Pretty much everything about our code will remain the same except for the transform.position. Our original code for that looked like this:

transform.position += new Vector3(_direction.x, 0, _direction.y) * (sprintAction.ReadValue<float>() > 0.1f ? runSpeed : walkSpeed) * Time.deltaTime;

We are going to change this to simply declaring a new Vector3 variable. Make sure that you remove the multiplication of Time.deltaTime at the end of the previous script:

Vector3 velocity = (new Vector3(_direction.x, 0, _direction.y) * (sprintAction.ReadValue<float>() > 0.1f ? runSpeed : walkSpeed));

Now, assuming you have a Rigidbody variable already in your code, you can call the name of that variable and append the ".velocity" to the end of it to directly access the velocity of your Rigidbody:

Depending on how fast you have your player already moving, you probably won't need to add that "50f" float into the multiplication, but you definitely need to multiply this by Time.deltaTime or else your player will move at light speed. This should fix most of your collision issues but there's one extra thing we can do to hopefully ensure it won't ever occur again!

Go into the Unity editor and locate the Rigidbody component on your player object. Locate the section of the Rigidbody labeled as "Collision Detection", then change the detection mode from what is normally "Discrete" to "Continuous."

Continuous Collision Detection uses more precise algorithms to calculate and detect collisions; however, it is generally more computationally intensive than Discrete Collision is. This shouldn't be too big of an issue so long as you aren't doing to many CPU intensive tasks.

Most of our bugs fell into one of these two main categories, but these definitely aren't the only issues that can occur with software. I hope the little information I have provided will help you all with any potential errors you may encounter, but also know that the Unity Forums are a great source of help. Even if you aren't asking a question, there are plenty of people who have had similar issues to you that have been resolved!

If you have any questions for me relating to the content I mentioned above or any questions for the Submersion development team, feel free to ask them in the comments! I look forward to showing y'all our game when it releases and I hope you guys stick along for the ride! Happy coding!