TOE week 12: Unrefined Ducking

                I didn’t want to work on the game this week, for two different reasons. First reason being I was sick. Wife went back to work found new germs and the house got sick. So I spend Monday curled up on the couch binge watching Stranger Things and eating hot soup. Second reason being I thought that implementing ducking would be hard. Was I right? Kind of but not really.

                I have this fancy Ray Cast system set up for the player. Basically my player sends out a Ray and the distance of the ray determines the player’s speed.  So if the player is colliding with a box the distance of the ray is zero and so the player’s speed is zero. But the hit box I have representing the player is basically the player’s feet. So I needed to double the player’s height and add the player’s head, ‘so to speak’. This seemed really complicated to do. I knew how I thought this should work but making it and thinking about it ARE two different things.

                Well turns out that I just needed to add the player’s height to the Y calculations up for Ray Casts in the position Y direction. Negative remains the same. And then increase the height of the X direction and suddenly we are Ray Casting with everything covered! I do need to better look at this because it was some hack code to accomplish this but it does work.

                Then it was just a matter of moving the player’s head to the position of the player’s feet in the Y direction when user input is negative for Y. Setting this up caused I bug that I haven’t quite figured out yet. Basically the bug goes something like this: nine times out of ten ducking works as expected. Player presses down and head.Y is equal to feet.Y. Then there is the one time when the head.Y is -1 lower than feet.Y. So it creates a situation where you have crouched SO low that your head has fallen through the ground.  As a tester inconsistent bugs were slightly annoying but as a dev they are the WORST. A game is made out of so many variables and tracking down the one thing that one thing that broke everything is a pain in the ass. 

                There are other things not quite right with ducking at the moment, like you can move left and right while ducking. So I have imperfect ducking at the end of the week. I mean it was less of a head ache to set up than I thought and I have a rudimentary version actually working, so overall I will call it a B-! 

                The thing I set up earlier in the week before ducking was wind tunnels and treadmills. Basically a vector that pushes the player in a direction when they collide with this type of collision. This was something else that I thought would be difficult and turned out to be REALLY easy. I slapped on some classical music and in about an hour I had it working rather well. Then two more hours and it was refined push collision. Maybe by the time next week rolls around I will have refined ducking? Who knows. 

                I think I am about ready to start arting this here game thing. Maybe slap some pretty pictures on this and finally show off what it is supposed to look like! Oh I guess I have to make those pictures. Going to close with a video of ducking and push collision. 

 

TOE week 11: No 'real' progress still = progress.

                Last week I was complaining about Get Component calls and how confused I was about them. The next day I had another light bulb breaking moment where I watched a video on Unity by Unity on Get Component and I finally saw it. I saw what I was doing wrong. Then everything made sense. Part of my problem was I was not thinking about a Get Component as a variable. 

If(!Blah){

                Int aNumber = 7;

}

While(Blah){

                aNumber = 10;

}

                I knew you couldn’t do the above. Basically the variable aNumber only exists in the above if statement. When the compiler leaves that statement that variable dies. So last week when I was asking why doesn’t Update know about the Get Component call from the Start function it was because I was doing the above. Trying to set the value of aNumber in a function where that variable had ceased to exist. 

                But when I figured out where I was going wrong worlds kind of opened up. I went back through a fair amount of my code and corrected my wrongness. Nothing really changed about the game after this fix. The frame rate didn’t change but the code is more optimized right now. Also knowing how to set it up right means that I will set it up correctly going forward and that is a good thing. 

                Also  in my quest to do things that show no ‘real’ progress I put in all of the code for input from a game controller. Right now my game can be played with a 360 controller. Before this it was all off of keyboard inputs. Again nothing has really changed but I find this to be super cool. 

                Anyway I have been meaning to post a video of what I actually have going on right now. So enough talk, watch this video of me playing my game. 

TOE week 9 and 10: Showing Off and Doing It Wrong.

                I was on vacation again this week so I didn’t really do a lot. Aside from show off the game to various different people who I could subject it to. I did however get a working primary attack set up. Last week I set up some targets that would take damage when hit but any of my secondary weapons. This week I set it up so the targets will die after they run out of hit points. The targets are supposed to give the player ammo when they die but I didn’t have a set up for player ammo being deduced when a secondary weapon was used. I added a player ammo counter and a restriction that prevents the player from using a secondary weapon if they don’t have any ammo. Once that was set up it was pretty easy to add into the on death for the target to give the player ammo when the target is destroyed. 

                Next week I need to add in a basic UI for Player; health, current secondary weapon, ammo and can teleport. I also wanted to make a video of what I currently have. But I think that may have to wait until next week. It hasn’t really been a big week but I did get more done than the last time I was on vacation. 

                Hey look it is next week. I didn’t post this last week partly because I was on vacation and partly because I didn’t have a lot to report. I kind of still don’t BUT I did add in all of the UI elements for Player stuffs. I did find some small bugs with my can teleport bool. Basically if my top raycast is not touching collision but the bottom raycast is touching collision the can teleport bool is true BUT the player can’t teleport. Super minor. It is certainly something that needs to be fixed but for the most part it works. The issue is clearly not with the UI and more with the teleport testing method I’m using. I need to change this test to an onOverlap instead off of four rayCastHit.

                So I’m going to complain about getComponent call once again SHOCKING I know. To make my UI work I have four Canvas elements that each monitors four player variables. I have seen on the internets in my research on this topic that you should never use a getComponent call every frame it will slow your game down. This was the only way I could figure out how to get the UI to update when the player variables changed. However there was no slow down when all of them were updating. Basically my update for UI stuff looked like this: 

Update(){

GameObject thePlayer = GameObject.Find("Player");
Player playerScript = thePlayer.GetComponent<Player>();


displayPlayerAmmo.text = playerScript.playerAmmoCount.ToString();

}

                Again I have been told that this is terrible but various Unity people on different Unity forums. But how am I supposed to display and monitor variables from the player in the UI canvas? No seriously how does one do this?  I had a thought and it was this: 

Update(){

If (hasGotten == false){

GameObject thePlayer = GameObject.Find("Player");
Player playerScript = thePlayer.GetComponent<Player>();

hasGotten = true;

}


displayPlayerAmmo.text = playerScript.playerAmmoCount.ToString();

}

                However THAT doesn’t work because GetComponent call only seems to pertain to the method you are currently in. Meaning that Update doesn’t know about playerScript. Only the nested If statement knows about the playerScript. 

                The wife goes back to work next week and I will have less time to devote to this thing. So my Updates might be shorter. I think I need to switch to working on more of the artwork as that is something I can do at the same time as being a stay at home parent much easier than programming.