Coding Discussions with Mr. Risker: Crash and Burn (or Purposely crashing the game to test out coding)

As mentioned before, I am a total n00b when writing code. My experience comes from visual scripting, using programs like UDK, as well as editor extensions like Playmaker and Ork Framework. However, learning the terms on the extensions, as well as the experience I had writing in Actionscript 2.0 (AS2.0 henceforth) allows me to at least understand coding enough to manipulate things to my liking. I am using this information to learn to code and using this series as a way to teach others, as well as myself.

While I was using Visual Scripting, and before My mentor got into the habit of using Debug.Log to gauge the success of code, I was testing code differently… by purposely crashing the game! it was kinda stupid, but it was fun as a newbie having the power to crash systems.

here I will place an example of what I would have done, converting the visual scripting to C#, and I will add what I would do now instead. The new code is what I did before I added the code to make my door animate in the Modular Walls Asset Pack that I recently released. This also what I started doing to make sure that the code works at the base level before i add more.

As usual, you have to let the code know what libraries you are using:

using UnityEngine;
using System.Collections;

If you create the code within unity, it will automatically create the class for you, it also adds and Update function and a Start function:

public class Code_Name : Monobehavior

I then created a variable and gave it an initial behavior. in this case, since I was working with triggers i created a Boolean that will set as true or false depending on the trigger enter or exit. for the sake of this example the variable will be called “_exampleBool”

bool _exampleBool = false;

this is where things get interesting:

on the visual scripting side i would tell the nodes that if the game hits a specific trigger, then crash the game. for this I wanted the criteria to be that the trigger contacts the “Player” and the boolean is set to false. In unity C# it would look more like this

private void OnTriggerEnter(Collider collider)

{

if (collider.gameObject.tag == “Player” && _exampleBool == false)

{

Application.Quit();

}

}

Ok, here is the explanation. OnTriggerEnter is what you would use if you are expecting something to happen after an object crosses a trigger. in Unity’s case the “trigger” is a Collider component (caps matters) with “is trigger” selected. the words inside of parentesis is an “arguement” this allows extra functionality. in this case i gave the Collider the name of collider (again, caps matters)

for the if then statement, i told the game, “If the collider on a game object that has the tag of “Player” collides with the collider that has this code attached – AND the boolean of the variable exampleBool is still set to false…

CRASH THE GAME… or completely quit the application without warning.

This was fun, but you could not test the code multiple times without restarting the game over and over again. I will now change the coding to what I would do now.

private void OnTriggerEnter(Collider collider)

{

if (collider.gameObject.tag == “Player” && _exampleBool == false)

{

_exampleBool = true;

Debug.Log(“this collision worked”)

}

else if (collider.gameObject.tag == “Player” && _exampleBool == true)

{

Debug.LogWarning (“you have already collided once”);

}

}

for the if then statement, i told the game, “If the collider on a game object that has the tag of “Player” collides with the collider that has this code attached – AND the boolean of the variable exampleBool is still set to “false”, then change the Boolean to true and place a log in the console that says “this collision worked”

OR

if the previous conditions existed but the exampleBool was changed to “true” then create a warning message that states (“you have already collided once”)
NOTE: Alternatively “!= false” could be the same as = true and could be read as “does not equal false

I talked about Debug.Log, but I recently learned a little more and wanted to expand here. Debug.Log sends a message to the console in unity that will read off whatever you type. It has an icon of a chat box. Debug.LogWarning, on the other hand tells you the same thing but with a warning icon instead. Unity sometimes uses the warning when code has depreciated, or there is an issue, but not a big enough issue that will cause a game break.

I added the else statement because i wanted to not only test the collision, but test the variable change as well. after the if and else both work, I would then add more code and change the log if needed.

As mentioned before, I am not an expert and I can be wrong. However I believe that in teaching others, I also teach myself. Hopefully you learn something, and if you know more than I do, leave examples in the comments. i would be happy to discuss more on this.