TOE week 49: Excuse My French

Blarg. You know it is a good blog when you have not updated in two weeks and it starts with a swear word.  Unfortunately I realized that I have been doing this wrong.  I wanted to make customizable bits that I can use to create a level basically out of legos. Now this works but many blogs ago I basically said that you should white box your level first and then art it. I kind of ignored this and did the reverse. The problem is that I am ignoring the design and constraining it to the artwork. This is a bad idea. It is supposed to be the other way around. This is harming me in three ways; 1 making a fun level, 2 the amount of space I have to control in the background is ever increasing, and 3 it is killing my productivity the very thing it was supposed to greatly help. 

I have also decided that I am going to start making a level. Mainly because I think I have enough objects to put something together that is small maybe but still interesting. I have decided to make a level the way we did it on the Batman game I made. Whitebox it when the design is good, art it. You know the freaking industry standard. Sometimes there are reasons for the way we do things. Though I am also not going to throw away my title sets going to use them to create the art after design is finished. 

In other more productive news. I made a parallax background element this week that had some problems. I asked my Facebook friends what they thought about it. Mainly so I could suss out what wasn’t working with it I settled on this. 

The size of it made me reduce the size of the Factory and the Ziggurat. The tower is supposed to be large and imposing so the other two needed a slight adjustment. Wound up looking like this. Might still need to be smaller. 

Two weeks ago I burned myself out a bit so last week I did some easy tasks. My game can now spawn a sub weapon pickup on the destruction of a lamp. Sub weapons now use the game’s default gravity and collide with the collision objects instead of just floating. I can specify what subweapon spawns on the lamp’s destruction. This is not terribly well implemented but it WORKS. More maybe later.

Also now when the player dies they disappear then are teleported to the last checkpoint they hit. So I have a working check point system in the game now. Somewhat rudimentary but it works!

I was also drawing a fair amount over the last two weeks. I have finally filled up my sketch book! I have been meaning to make some concept art for the tower in the past and future. So I have been sketching some of the new designs into the future tower concept.

TOE week 48: AttackTheProblem();

It was a whirlwind week this week. I talk to computers I am not a coder, yet. I mean most of my methods for getting the programming done is basically dragging my face along a cheese grater until one of us gives up. This is how I attack the problem. It is an ugly method and one with various flaws but the work gets done. A task that I have had on my ToDo list for some time was simply to show my work to an actual programmer and have them look over the things that I have been doing that could be improved. 

Similar to the tabs and spaces argument there is this:

if(!thing){

}

Vs

if(!thing)

{

}

I was so inconsistent about this. You have to pick one. Honestly I like that top version but Visual Studio is default to the lower version. So fighting with it every time was not something I was willing to do. My programmer friend he told me how to set my rules and then format the document so that all of the existing code gets this treatment. My code is much more consistent in this regard now!

When I talk about cheese grading my face in how I work when I program that is probably also how I work with art and design as well. If I were to write it in code it would like something like this:

if (workToBeDone){

AttackTheProblem();

}

This method has some disadvantages. Mainly frustration tends to build up over time. For example I was working on my player death function. When the player health is zero make the player start to fade away. The strange thing was that I could get them to fade in from nothing but not fade out. I kicked the proverbial tire of this problem until I was just so frustrated that my wife thought I should work on something else. Not being cool headed at the time I chose to continue with cheese grading my face against this problem.

Turns out my code was actually working but the fade speed was too low. I would make a change in code run the game look at the player not fading be sad. Stop the game edit code and process would repeat. AttackTheProblem(); It is really hard to fix something that is actually working! I only realized that it was working when I pulled the slider in the inspector and the player disappeared a bit. I spent a day on this death function and some of that time was wasted.

The next day I was fighting with the UI again. I was trying to make my Player Health UI populate a Grid instead of populate a single column. Then I needed to flip the graphic if the population was above 10. Getting the grid to populate with my objects was easy BUT getting them to be the right scale was not. Again I cheese graded my face on this problem. It eventually worked but it took a whole day fighting with it. It wasn’t because this was difficult, it was because scale and parented objects are weird in Unity sometimes. It wound up looking like this: 

Then I didn’t work for two days because I was AttackingTheProblem(); IRL because one Government agency said that another Government agency lost all of my paper work. And a completely different Government agency wanted a bunch of different paper work so my car is in fact still a car. 

I got a ton of little things done after IRL was over. Player raycast while ducking now adjusts allowing the player to duck and slide under things. I got an enemy working who moves around similar to the player using the raycast controller. I fixed my melee attack problem 97% of the time. The last 3% still is bugged but it now works much better. I fixed a bug my friend found last week where the player would get stuck at the end of the ducking attack animation if the duck input is released during the attack. I made artwork for the primary attack finally. 

So much AttackingTheProblem();.

Then the next day I was just burned out. I tried to work but I couldn’t get anything done. My wife asked me when was the last time I played a game? I didn’t know. Being cool headed at the time I chose to continue working and managed to get a render texture to appear on an object through script. This is helpful because you can’t prefab a render texture. WELL you can BUT instead of using the camera at your new camera’s location it will use the camera from the prefab. Not helpful. So creating it in code allows you to build it into the prefab. This mostly worked with some caveats.

I probably just need to take my wife’s advice. 

If(workToBeDone && burnout <= 10){

PlayAGame();

}

TOE week 47: Slacking Off While Showing Off

The week before this I was on vacation. It was really busy, seeing family as we usually do over the summer. I didn’t get to work at all. So much of my time was spent around the hotter part of the state where our families are located. I did however get to show off the game to my father in law, brother in law, father and a friend of mine. I didn’t let the first three play the game because I brought my Xbox dongle but like a genius I forgot to bring along a controller. My friend though she had a PS4 controller and I figured that would work. 

This was a dumb thing to think apparently. Did you know that the PS4 and Xbox controllers use different numbers for the buttons? Cause I found that out when we plugged in. My friend she could open a portal but couldn’t teleport through it. I did look up that button 8 on PS4 is the share button where as button 8 is clicking the left analog but I did this after the fact. Also jump is the square button and is A on Xbox. Basically I think every button on the face of the controller rotated clockwise. This is good to know whenever I get around to porting this thing to PS4 or PS5. I could have had my brother in law look at the game in this way but there was a time consideration and honestly I didn’t even think about it. 

Another thing that happened was my friend she managed to detach the player’s head. You know the thing I thought I fixed weeks ago. I blame the PS4 controller.

Then there was this week and was honestly about as productive as last week. I had no time this week. Everything this week was either car or baby class or just decompression from vacation. Showing off my game to family was pretty great. Now I just have to get back to work on making this thing so I have more work to show off later.

‘This week’ and by this week I mean today. I made a Fire push collider. It is basically the same thing as my push colliders but this push collider only pushes you if the portal is open. The idea being that the portal blocks the fire and pushes the player in the given direction. If the portal is not open the player will take damage. So yeah any amount of work next week will be better than this week.

TOE week 46: Fixing a hack that I made.

Have you ever made a UI before? Cause I have… Maybe? Three days I ago, I found that something was tanking my frame rate. Like my computer was plugged in and everything, and still my push colliders in the vertical direction refused to work. Two days ago I found out what was tanking my frames. It turns out that hacking in a functioning UI has consequences on calculations. Creating and deleting all of the health graphics every frame is not a good idea. I tried to fix it and failed. 

Yesterday I was able to fix it. I spent all day (some of it face down on the floor) reworking the health display. Now in all appearances it functions identically to the hack without the drop in frame rate. All of that work basically brought me back to where I was two days ago but if you look at it then and now you probably couldn’t tell the difference. It is clearly a win but it doesn’t seem like one I suppose.

I need to update Unity to its latest version but I think some things will break. I have some code I got for free from the unity store to export  3D objects from Unity to Blender so I can create backgrounds and I am pretty sure that it will die when I update. My code may also break in places, I am just less sure about where that is going to happen. 

In AI related news I have created two more enemies. One is the Spotlight Cannon that I talked about last week shown above. If a raycast from it hits the player it starts shooting at the player. The other enemy is a flying enemy that is difficult to hit but dies in one hit. 

I had a revelation on Monday that my collision objects are too large. This means that I have to possibly remake them or more likely resize them. As they are now it is somewhat difficult to see them through my teleport window. This is relevant for gameplay reasons.  Yay more work to redo!

TOE week 45: Building a better Nemesis.

I was really lacking motivation this week. I wasn’t as distracted as last week but it was really difficult to get anything done. On Wednesday I made a basic enemy this week. This enemy doesn’t move probably one of the things that makes it basic. It is a stationary ranged attack enemy that fires at the player. I took a Udemy course on Unity like a year ago. One of the things that I did not understand about this course was why they made the enemy object determine the projectile’s path. 

In my opinion it is far easier to give the projectile ‘directions’ than have the enemy object pass said information to the projectile. I don’t think my way of doing things is wrong but there may in fact be something that I have yet to understand. 

 My enemy’s tiny AI brain works something like this.

AI: Is the player within firing range? Yes or No.

If No do nothing.

If Yes count down until it is time to fire by spawning projectile object. Then reset time to fire.

Then the Projectile asks: What side is the player on relative to the Projectile’s position? Then head in the direction toward the player. 

The thing that was strange was how easy all of this was. All of it was really easy to make. A lot of the starting properties of the enemy were created using existing pieces of code. Slap my target code and deal damage code onto this new thing and bang instant enemy. Then same thing for the projectile and instant projectile by creating a modified version of my knife sub weapon.  It was practically a cake walk. No problems…

I was/am really excited about my basic AI enemy. I made a cool mechanic out of the player’s teleport window blocks enemy projectiles.

The white rectangle is actually two enemy’s stacked on top of each other. The pink lines are attack projectiles.

Then Thursday happened. Because everything went so well on Wednesday I thought we can make another enemy in a day. This time I wanted a spot light enemy that visually ‘patrolled ‘ a piece of ground by looking back and forth between two points then if the player was occupying the space the spotlight was looking at stop and fire at the player. I couldn’t get the projectile to head toward the player. It would instead spawn in with the desired rotation and head screen left. I then spent too much time fighting trying to get the thing to work and none of it working. I would have been better off playing more Rimworld that is how much Thrusday’s work accomplished. 

Because my new AI wasn’t working out I then decided to make my Player into a prefab something that I had been putting off but it was about time to do. That BROKE my teleport artwork. I then spent the next hour fixing all of the things that this broke. I was expecting some breakage but I wasn't expecting HOW broken this would get. Basically Thursday’s progress was all in the opposite direction. I could never get the hang of Thursdays.