TOE week 2: Hitting my limitations with promblem solving

                I am still hammering away at the coding portion of this project .  More than likely there will be heavy focus on code for the foreseeable future.  There is a reason that video game companies need so many programmers.  This week I implemented wall jump using the raycast system, moving platforms with a waypoint system and further flushed out my teleportation mechanic.  Again I would like to thank Unity for being so freaking easy to use. That isn’t to say that I didn’t try to screw it up in some places. For example a render texture is remarkably easy to set up in Unity. But render textures don’t work if the user sets the Y scale to 0, woops!

                I am also still hitting my own programming limitations constantly. I would bet money that if I showed this code to any of my programmer friends from various jobs over the years they would cringe. I would actually like to do this at some point so they can point out some of my ‘bad practices’. 

                In programming issues department I am really confused about public functions and how Unity doesn’t work as I understood them to work when I took my C++ class on classes. In C++ a public function or public variable was accessible by a different class if they were linked. In Unity a public variable only seems to be accessible in the Unity editor. If you want use a public function or a public variable you have to use a Get Component call. I was told that this was computationally expensive but it was the only way that I could get my Raycast class to talk to my Player class. Computationally speaking this situation was fine with no slow down. However, hooking up my Teleportation class to my Player class and using a Get Component call allowed for the User to call on this Get Component at will. Meaning if they hammered the keyboard button enough times the game would slow down. Like I have a pretty fast laptop and mashing the B key caused moving objects to jitter and slow down. This is bad.  At this point in development it isn’t really that bad, but having a project that is currently devoid of art slow down is a sign of ‘some optimization needed here’. 

                Also this has been a week about learning some of the quirks of Unity or C#. That being that a while loop functions different from what I remember from C++. 

 while (var < 100){

    print (var);

    var++

} 

                In C++ your console would spit out the numbers between 1 and 100. In Unity the same while loop would immediately spit out the number 100. Or at least it did for me. I was using a variable to control the size of the teleportation portal while the number was less than the max size of the portal. Function would just immediately spit out the largest number. Got rid of the while loop replaced with an if statement and bang we can increment the size of a portal. Go figure. 

                Also Unity’s collision system doesn’t work if there is no Ridged Body attached to one of the colliding objects. That is fine and makes since but because I’m handling many of my collisions with raycast when I turned Ridged Body on my player hit my world collision and the world started falling, woops. Fine I thought I will just change the world collision to contain a Ridged Body that will do the trick. NOPE even worse because all of the world collision intersects itself in many places the entire world would literally explode. Probably just needed an if statement that told it not to collide with objects of its own type.  I just thought of that while writing the previous sentence.

                In the non issue department I have saved my own bacon several times this week by creating a test project devoid of anything except the issue that I am trying to solve. This is not a new concept people do this all the time in industry, but I highly recommend it for things that are stumbling blocks. I learned what Unity requires for collisions and I managed to get a simple problem that I was making WAY to complex solved by taking everything else away. Also MathF.Clamp man! That is a super handy way to keep a variable from getting away from you. 

                Next week I am looking into variable Jump Height, Pass Through Collision, and Camera Tracking. I will leave you with this video though of me being stupid. This is one problem that I solved with the test project.