TOE week 3: Solved 5 problems Created 2 more

                I am continuing the trend of continuing good weeks. Last week I said that I was going to be working on Camera Tracking, Pass Through Collision and Variable Jump height. Not only did I do all of those things BUT I also implemented Double Jump and Air Dash. They are in the game and function pretty well over all. There are some things that each of these powers do not play nice with. Like Double Jump combined with Wall Jump currently allow for the player to hop up a wall like Megaman X or Super Meat Boy. Not what I want but the overall function is correct. Also have a small problem with the player landing after an Air Dash and if the air dash button is still down the player will immediately air dash again. Super minor considering that I roughly implemented each of these things in one day. I probably shouldn’t put the focus of this on everything that is going wrong when the majority is going right. But I need to give an accurate report of my week. If you implement five new mechanics/functions and it only creates two new problems, then I would call that ‘a win overall’. 

                Camera Tracking, Pass Through Collision and Variable Jump height all went off without a hitch.  Pass Through and Variable Jump height are slight modifications to the Player Class. I think each of these things is controlled by two different if statements. Camera Tracking became its own class with a small pile of code but it only monitors the player position so it couldn’t really break anything. So it was also super easy to make.  

                I got to show off the game to two friends this week.  Show and tell is fun even if there isn’t a lot there really. I only have a tiny gym level to show off my current player skill set. One of my friends seemed to like my teleport mechanic that I mentioned briefly last week. 

                Currently I’m not really happy about the feel of the game. Player Jump doesn’t feel like I want it to yet. BUT that is also fine. I have to keep telling myself that this is week three and there is plenty of time for tuning the numbers. I don’t have a reason to be upset yet given that we are about to get to week four. 

                There isn’t really a lot to say about this week aside from the fact that it was a pretty smooth week and I implemented like five things. I should also say that I have been neglecting one of my other projects that’s further along. So I might be working on that one next week a bit more and neglecting this one a bit. I have really enjoyed the big momentum that I have had with this project TOE but I don’t want the other one to fall by the wayside. 

                I am not totally sure what I am going to do next week! I have been debating between, Secondary Weapons or implementing a Player Sprite. I have a sprite sheet of Run, Jump, Duck, Wall Jump Slide, and Double Jump. I made this sprite sheet back when I was puttering about in XNA. I will also take a stab at fixing my two new problems created from Wall Jump and Air Dash. I think I can fix the Air Dash right now but Air Dash isn’t being so nice. My code could also do with a comment pass. I have commented some of it but not all of it. I have been told that comments are really important.

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. 

TOE week 1: Picture = 1000 words, 1000 miles - 1 step to go

                This is the production Blog for my TOE game. TOE is an acronym for something that I’m not quite ready to reveal yet. That being said I have been wanting to make this game since at least 2009. I am literally doing everything on this project. Art, Design and Code. (Yeah it isn’t correct to capitalize those words but I did it for emphasis. Also if you want to read a blog without spelling or grammar errors you should probably look elsewhere.)

                A journey of a thousand miles BLAH BLAH BLAH! I am not a programmer and that is fine. I have some rudimentary coding skills. I can make a program that will find every prime number between one and any specified large number. I fooled around with project euler and solved some of the problems on the front page in C++. At my best I am a Software Engineer in my sophomore year of college. (If this means nothing to you the take away is that I’m not very good at telling computers what to do but I might be better than you.) 

                I can kind of program, and currently that is enough. Right now I am making the whole thing in Unity. I have a 2D character in a 3D space who can move and jump and teleport in the Z direction. This took me a week to do. I know that to some people who don’t work on video games or various other creative endeavors this might seem like a long time but I assure you that this is amazing. Unity is stupid easy. Oh and there are slopes! I have a 2D platform game with slopes! If that is not impressive then you don’t understand the work required to use a raycast to tell the player cube to move up an incline. 

                I can actually draw. You wouldn’t know it by looking at the game as it is now. The entire affair is currently represented by 3D cubes and rectangles of varying colors rendered orthographically so what is the point? Making the art at this point would be pointless as so much is subject to change at the beginning of the project. The control needs to be hammered out first. Then getting the code to fall in line. The game looking great and playing poorly is a sure fire recipe for failure.

I am a Game Designer. I have been a Level Designer on various game for the past ten years. If I told you the names then you would probably stop reading this right now. When making a game and the player specifically you want the player pawn to control well in a white room. Think about any Mario game and remove all of the enemies and all of the bricks and put Mario in a blank box would Mario still be interesting to make run around? Mechanically controlling Mario in a white box would still be interesting. This is the most often overlooked part of game making. Often this is the thing that makes a bad player pawn. If you really think about it what are you doing for the vast majority of any game? You’re steering a hit box through a world of obstacles to reach some kind of goal. If your player pawn handles like a pinto you might as well leave the game in your garage. I am not all that far in the design portion but like the art portion design isn’t what is important right now. I need to get it working with code before I can make it feel good and be pretty. 

            Well that is week one of Project TOE. Next week my wife is going to be done with teaching and it is the start of her summer vacation. So I can get even more work done on this project.