TOE week 24: Hmmmmmm needs more dinosaur

I did something amazing this week. I finally figured out what was causing my inconsistency and it has nothing to do with how bad I probably am at coding. Or might have everything to do with how bad I am at coding. 

I have a laptop tray. Don’t worry I didn’t waste any money on buying one. This tray originally was for my son’s old baby chair that he has grown out of. It is wide enough that I can use a mouse on. Yeah I’m an old man I need a mouse to use a computer. If you can enter values in Unity or model in Blender better than me with a track pad great on you. I’m still a dinosaur. Last night I was trying to squeeze one final animation onto the player. As I started I noticed that my mouse wasn’t working. Whoops forgot to plug that in, did so. Worked on the last animation, ran the game walked into one of my push boxes with an up vector and the player remained on the ground. “DAMN IT! Why does this happen on a weekly basis?”

 I looked at my laptop battery. My computer wasn’t plugged in must have forgot that too. The game was still running. I thought about how laptops run slower when not plugged in to conserve power. I looked at the player standing in the push box that should be pushing them upward. ‘I wonder what would happen if I plugged this thing in…’ Did so and damn that push box did toss my player up into the air. My secondary weapons started working normal again. The background no longer jittered. It was liked suddenly everything that I hated about my game that I couldn’t fix just needed more power. Like the kind that comes out of the wall from dead dinosaurs.  

SWEAT! It is not my fault. It is a processing thing. Or maybe it is entirely my fault… If I ever manage to finish this here thing would it run differently on different machines? Should I cap the frame rate? Wait I have no clue how to do that. This is probably the smallest part of my accomplishments this week. I basically found out the WHY of this problem 15 minutes before I went to bed yesterday.

 The rest of the week was spent attaching animations to the player. Now it looks even MORE like a game. I had to build a player state monitor in C#. If the player’s Y vector is positive display the jump up arc animation if it is negative display the jump down up arc animation. Isolating all of the various things my player can do and figuring out of to actually use that confusing Unity graph was a chunk of work.

On Monday I started a new fresh project dedicated to only animation. I set up a detailed tutorial online about how to animate in Unity. I got Megaman X running with a sprite sheet.  When I pressed the right arrow he ran and he went to idle when I hit the left arrow. STUPID SIMPLE. Breaking it down into its most simple components allowed me to understand how I could integrate it with my must more complicated project. I managed to get 14 of 15 different animations set up and MOSTLY working. There are some tiny problems. Like the player’s actual attack spawns before the animation plays. BUT hey the animation still plays! Also the attack animations end abruptly and I can’t seem to convince the graph to let me hold an animation’s last frame. So the functionality is not fully there but it is almost correct. 

And I almost forgot to mention that I managed to put down some art on the edge of the player’s portal to give it a more rounded and energy portal look as opposed to a window. This art also color cycles, it kind of pulses between colors. Overall this last week super productive I got a lot done and found answers to something that had been plaguing my work. 

I know that last week I promised a video showing off just how all of this is working BUT I think I have to wait another week. Maybe after I get that last animation working. Next week a video and I will have to finally make some textures so I can really show it off!

TOE week 23: Consistent Inconsistency

I worked on consistency this week. Last week I worked on the background plugged it in and things were humming along. Wrote a blog about it and published it. When my wife got home I showed her the thing that I had been working on and it looked slightly wrong. The background jumped around and was not smoothly in place. My secondary weapons began to act up when I checked them. 

So I spent a day looking into this problem. I asked a question on the Unity Facebook group I’m a part of and was told that I should be using Time.FixedDeltaTime instead of Time.DeltaTime and that I shouldn’t have public editor values. Wat?! One of the great things about Unity is public editor values! When you first write code you don’t immediately know that a value of 7 for a force will send the thrown axe careening off into the infinite. You just make a guess of a good value then when you see it working for the first time, and the force is too strong or weak, you adjust it in game, find a value that works, and then leave it the hell alone. Very rarely to never have I coded something in Visual Studio and it just worked perfectly with my guess-timates. 

The issue I have been having doesn’t seem like I changed something else and it impacted the secondary weapons either. I would be thrilled if it was that easy of a problem to solve. This issue seems to pop up depending on  the opening Unity. It also sticks around broken or working for little while. It was broken all of last weekend and worked correctly all of the week and was broken when I opened it today. It breaks and fixes itself regardless of anything I seem to do. Yay…..

I grabbed my Sprite sheet off of my storage hard drive. I got all of the animations in Unity and working. Well that is to say that I managed to import all of them into Unity and they animate. So far as the player animating the only thing I have working right now is making the player sprite flip when you are heading left or right. Man oh man animation in Unity seems complicated! Well that and I have basically never done it before. Maybe some basic things but this is pretty crazy.

Related to this I did write a Player state machine to tell the Animator what animation to display. I haven’t quite yet figured out how to swap animations on the player. I looked at some tutorials on how to do this but I wasn’t really happy with them. But it did also make this: 

For those uninitiated in Unity that is an animation graph. Basically all of the animations are allowed to transition into any connected animation. I just have to get it working… Unfortunately that might mean actually doing one of the tutorials in a separate project to really understand how really implement my sprite animations. So close! Maybe next week I can wow all four of you with a video of the player running around. I could do it right now but it would be complete trickery.

TOE week 22: Two minor bugs and Hot Garbage

I fixed two minor bugs this week. One was minor in the fact that if you ‘played right’ the game didn’t look stupid. However if you abused it I thought it looked dumb. Funny enough when I showed my wife this same bug before I fixed it she thought it looked cool. Eye of the beholder I guess. This minor issue was that if the player was standing in a place where they were not allow to teleport and tried to open the portal to teleport the portal would pop open for a frame or two and then snap shut. You were not allowed to teleport but you could briefly open the window so to speak. You could also hammer on the B button and see this rather continuously. I didn’t like it but the wife did.

The other bug related to this was the UI indication for if you are allowed to teleport would continuously flicker between true and false. For some related reasons. The way it used to be set up was the bool will reset to true based on the player’s position BUT will be false if the test object was overlapping with collision at the teleport location. So the player would say, “Okay I’m in the right dimension to teleport so condition TRUE.” But the test object would say, “Hey I’m colliding with collision so condition FALSE”. And it would bounce back and forth between these two states. 

When I originally set up the teleport functionality weeks ago when I finally got everything mostly working and saw these two minor issues I thought, “I don’t want to break anything, it works right now, I’ll fix it later.” Well turns out the fix took me about all of ten or twenty minutes. So way have I spent three paragraphs talking about this? Well because the rest of the week was spent painting another background. Describing that is something that a time lapsed video is probably better at. Speaking of those I HATE those people who can just take a blank sheet of photoshop and turn it in a perfect landscape. Your thought is “Hey any idiot can do that.” Then you try and it turns into hot garbage. Need more practice I suppose. 

Overall it was a good week. Great to be back on the horse so to speak. Next week I am hoping to work on the ground textures and get animation working… Animation seems daunting. I have a sprite sheet of my character even broken up into animations. Just got to trick Unity into making them work I suppose. 

 

The window is open.

 This week's background

HOT GARBAGE as promised.

TOE week 21: Complex road to a simple solution

I was feeling out of practice when I opened up Visual Studio for the first time in a while. A lot of the code work has been done. Not that this here thing is even close to done, but right now I’m working on the art stuff. So imagine my surprise when I tried to program something that should be a complete cake walk and nothing I did remotely worked. 

Basically I need to have two backgrounds for my game. Because they are backgrounds they need to move with the player in the X and Y directions but not in the Z direction. I remembered in a different game I made from a YouTube tutorial that you could lock an Axis. Meaning that an object would not be allowed to move on a locked Axis. This didn’t work with what I was trying to do because the Backgrounds are not moved because of Ridged Body(a property in Unity). These Backgrounds were instead attached to the Player and move relative to the Player’s position.  If the Player moves in the Z the Backgrounds do the same. Meaning that you could never see the farthest Background because the closer Background always covered it.

So much of programming is Syntax. Have I said that before? Because it is so freaking true. People for the most part are Syntax free. Ask your friend to ‘move cup’ and generally they can look at the table and extrapolate that you want them to pick up the cup on the table. A computer on the other hand will stare back at you and say “error expected: definite article”. 

When I ‘asked’ the computer to set the transform.position.z of the background object to be equal to ALWAYS be equal to its starting Z position the computer said you can’t do that. I fought with it for awhile. More like I tried to trick it with various ways for a while. None of that worked. My brother in law called and I complained to him about my problem we laughed. When I went back I deleted everything I had tried to do and started from scratch. 

Then I basically found out that I was asking the computer to do something entirely the wrong way. 

transform.position.z = stickingPointZ is not legal. 

You have to define a new Vector and set that vector to be equal to your variable. Basically transform.position.z is part of a vector and stickingPointZ is not a vector it is Float. So they don’t like talking to each other I guess. 

transform.position = new Vector3(playerPointX, playerPointY, stickingPointZ);

It is a simple solution but it was complicated getting there. Then I spent the rest of the week painting after I figured out that small problem. After I had finished my BG I plugged it in and bam suddenly my game was like 50 percent more presentable! Next week I have to paint the other background and we will have something that is closer to looking like a game.

 

My game with a background!

 The background.

TOE week 20: Jumping the 1 pixel gap

                The UV rays burn! I think I hate UV mapping or Blender’s UV tools or both. I worked on UV mapping a couple of times over the past few weeks that I haven’t been writing my producer e-mails. (AKA this blog.) I would look at UVs in Blender fight with them throw my hands up in despair and walk away. A friend of mine was coming over to work on my other project with me and have a dev day. He spent the day accomplishing things and my entire Saturday dev day was me know figuring out UVs. The stupid thing is that I already know how to UV things. In fact I recently UVed a hover craft racecar for a completely different project. Racecar’s are harder than squares. Like all I am trying to do is a plainer projection on the front of squares. Blender from what I have looked for on the internet for how to seems to indicate that Blender used to have planer but now uses project from view. Project from view means that the size of all of the objects is different every time I make the projection. And that sucks when you want your UVs to line up. 

                Meanwhile I’m also wrapping up my other project. It is called Ninja Zen and on the Google play store. I have described it as Tetris with Ninjas. So project TOE has been neglected because of the more relevant release. Also not going to lie but UVs have made wanting to work on this project increasingly difficult as mentioned above.

                So this week I got myself in gear and sat down with UV nonsense for a large chunk of time this week. About 4 days this week. I got all of the UVs lined up then got them into Unity fought with Shaders for reasons I’m not entirely clear on then connected all of the pieces together to see how well they all lined up. Looked at the seams adjusted them in Photoshop. Back to Unity got it mostly working. Super annoyed with one piece in particular. There was a 1 pixel gap between a straight piece and a hill piece. I tried everything I could think of to removed this gap. It basically shouldn’t be there. The UVs were right as far as I could tell. I didn’t want to mess with them as I could break them worse. Photoshop was right. I turned up the quality in Unity. No help. Checking boxes and turning all of the relative dials I could find and nothing. Still a 1 pixel gap. 

                My wife told me to quit. It isn’t a big deal. The stupid thing was, it was a BIG deal, to me. This 1 pixel gap was haunting me. The words of advice from Extra Credits ran through my mind “If you are working on something for an hour and it doesn’t go well move on figure it out later.” Good advice. Screw THAT! I joined two Facebook Unity Dev groups. Posted my problem got back three different possible answers. I tried all three and none of them worked. That is when it clicked. It wasn’t in the UVs I thought. I opened Blender and looked at the model. I snapped the two pieces together and looked at their vertexes. Sure enough they didn’t line up. They were off by something stupid like .0012. Rejiggered the vertexes a little used blender’s snap to vertex tool and opened Untiy and BAM! No more 1 pixel gap. Victory yay. Was it worth it? I don’t know.

                As far as learning how to solve problems goes it was clearly worth it. If you try everything to fix a problem and everything fails there is power in that failure. You now know that thing that you think is the problems is actually not the problem.  Knowing where the problem is, is halfway to solving it.

                   Above is the very simple squares that I UVed. Squares that were a pain!

 More complicated race car. This object was easier for me to UV.... I need to get a copy of Max or Maya.