Friday, September 29, 2017

TOE week 54: Very Variable Results



Discretion is the better part of something something. It would be cool if this was a blog about how I finally managed to tackle my Spotlight enemy problems. It would be cool if I could say that the things I tried worked and made the game tie together a little bit. It would be cool but it wouldn’t be true. 

I watch some different Youtube videos on game development. One of the series I watch is called Xtra Credits. I try to follow their advice about being an indy dev. One of the things they talked about was don’t stress about a problem that you can’t solve. Work on it and if it doesn’t work it is okay to give up and come back later. So I did that. The spotlight seemed to be not only something that didn’t work quite right but also something that was holding back other work. 

So I dropped this hot potato and moved onto a different AI. Something pretty easy. This new enemy is basically a mook enemy. It doesn’t do a lot and is easy/fun to kill. I named it a walker because that is all it does. It doesn’t even walk toward the player. It isn’t programmed to be smart enough to care. It walks until is it obstructed and if obstructed it turns around. If it touches the player it deals damage. It takes two hits and then dies. It was a very simple small victory. Probably a small victory that I needed too. 

That was cool. Then I made a different new enemy. This one I called a thrower. For this enemy I wanted to have much more random movements and random attacks. Step one was to make this enemy patrol side to side at a standard speed. AI asks itself ‘have I exceeded the limit on my position’? If so turn around. Step two was to then randomly change the limit point of enemy patrol. This led me to the discovery of Random.Range. A function that I believe is Unity specific but also pretty dope.  For the change of the patrol position it was just a die roll with a 25% chance of changing the position. Step three was to have another die roll that would randomly change the direction. Step four was then to have the enemy’s acceleration value also randomly redefine itself. 

Oh right this enemy was called thrower. Because it will randomly throw a projectile at the player.  The angle of the attack is random and the time between the attacks is also random plus a padding value. These projectiles seek the player’s position when the projectile is spawned. Turned out pretty well considering. When you put all of this together you get enemy that bounces around the level with no rhyme or reason. Leading to very variable results.  

Next week hopefully I will be able to make two more enemies! Or fix the one that is really bothering me.

Friday, September 22, 2017

TOE week 53?: Slightly Larger than Goose Egg



Well I haven’t really been able to work on this for about two weeks. I did work on my Spotlight enemy. It now will Lock On To the player and if the player gets out of the Spotlight’s vision it will then Lock Off and go back into search mode. There are some different problems with it but it effectively works. However there seems to be a problem with the underlying game itself. I want the projectiles to be avoidable but right now the player can just out run the gun fire so there is really no penalty to being spotted. If I just increase the speed of the projectile then the hits become more ‘mandatory’ and I didn’t want that either. My AI for this enemy right now is Artificial minus the Intellect. I wasn’t really sure how to fix this so I did the ‘smart’ thing. I stopped working on it for two weeks and played Slime Rancher. 

I did also work on my figure drawing because for whatever reason that helps me draw Giant Robots. But full disclosure I pretty much ignored this project for about two weeks. Whoops! The smarter thing to have done was to give up on the Spotlight enemy and work on a different enemy that I need. Instead I played an adorable Farm Sim. In some ways you could justify Slime Rancher as ‘research’ but not to the degree that I played it. I also picked up Destiny 2 from a Red Box because God knows my love hate with Destiny 1 and you cannot justify this as ‘research’ in any way really other than “hey this game contains the following things that will not be appearing in my game.” Then list EVERYTHING. 

Is it ironic after a post about how to work hard and get what you want my productivity was pretty much a goose egg over the last two weeks? I don’t know I will ask Alanis Morissette if and when I run into her at the knife store.

Friday, September 8, 2017

TOE week 52: Only 990 miles to go!



It has finally been a year of work. I’m not sure what mile we are on. As stated on day one this is a 1000 mile journey. I think I have gone about ten miles. Meaning that this will be done in about a hundred years…. Great! I’m almost there!

 Above is what the game used to look like vs what it looks like now. So much progress and still a ways to go.

This week I worked on better population for my level.  You know setting up shop. More enemies, putting in sub weapons, and ammo. The basic outline needed to have some things to do in it. Things to fight and power ups to grab. The level is slowly becoming more flushed out. 

Last week I found out about a couple of things that I needed to fix. This week I found one more. Two  weeks ago I set all of the level collision boxes to be Convex Colliders. It is a check box in the Mesh Collision in Unity and I’m not really sure what it means. I want to say that this makes the inside of the Collider count as collision as that seems to be the effect.

I noticed that my teleport test only triggered when the teleport tester collided with the edge of the collision in the past. BUT you could move past the collision edge and it would then be legal to teleport and you could fall out of the world. This is bad. Changing all of the collision to Convex fixed this. So again I am assuming that is check box means check on the inside of the Collider. The actual definition of the word means curved outward like and oval or all interior angles are less than 180 (and that also means curved outward).  And looking at the Unity Docs says nothing about testing for collision inside the box just that it can collide with other convex colliders something that it was doing before I checked the box just not as well as I would like. 

So I checked the box and went on my merry way making my new level. And unknown to me at the time this broke my grenade sub weapon. This is just something that often happens while in development. You find a problem, fix that problem, and create a different problem. Two weeks later when I trying to use my sub weapon it no longer explodes on impact with the collision. Why? Because the sub weapon didn’t play well with a convex collider. 


My grenade sub weapon changes its angle based off of the angle of the collision that it hits. To do this it needed to know two things. 1 the angle of the object that it collided with and 2 the direction of the slope. Angle of the object is basically the normal of the object the grenade hit minus vector3.up. The slope was calculated using a function I found online to get the 3D vector of an object based on all faces. This function doesn’t work with convex colliders. Well crap. Funny story though: hit.normal will basically do the same thing it is built into Unity and works with convex colliders. HILLARIOUS I know. I also had hit.normal in the code for this and it wasn’t hooked up to ANYTHING.

Say while we are on the subject of things I don’t understand. What is the front of an object? Or how do I tell Unity that THIS is the front of an object? I installed some tracking logic onto my spot light enemy. 



I get why Unity thinks that the front is over there. It is because computers are only as smart as you tell them to be. I never told Unity that THIS is the front. But I’m not sure even how to tell the lookRotation ‘hey this is your ‘front’’. Probably just means I will have to find out next week. My spotlights now rotate toward the player when the player is spotted but I now know that ‘toward’ is a very relative term.

So I guess this is the end of Year one for project TOE.

Friday, September 1, 2017

TOE week 51: Highlighting Short Comings



Last week things got a little off topic and instead I talked a bit about work ethic. I didn’t even talk about the fact that I built about half of a level. This week I finished the other half of it. This new level is by no means done. In fact if anything it has highlighted some of the short comings of my game currently. You can’t really know what is and isn’t working until you try to put it all together as a cohesive whole. In my test level I could tell if thing were functioning and for the most part they were. But was the functionality that I made in the test level working in terms of actually being fun to play? The answer I got was yes and no. Certain things work really well and other things do not. 

For example my using the portal as a barrier against enemy energy attacks is really rather cool. This also makes my stationary beam attack enemies and spot light enemies more cool. Also in the cool column are the fire push colliders. Using the portal to block a vector in the future or utilize a vector in that past is default cool. Having the Player teleport to the past to get a checkpoint reminds me of opening a shortcut to a bonfire in Dark Souls. However the spotlight enemy that I made need to track the Player once spotted until the Player is out of sight for a certain amount of time. My little rushling enemies are not fun to fight on slopes. The flying nuisance enemies don’t seem to even have a place in this level. 

The level right now is currently just populated by some enemies, push colliders, checkpoints and the rest is level geometry. Currently it is in white box mode. Nothing pretty, mostly function. So the next step is making the stuff above that is not working to its full potential, function better. 

I did also address some minor problems this week like the Player’s attack animation could not transition to the duck animation. Meaning that the Player would stick on the last frame of the attack animation if you attacked and then pressed down on the controller this made fighting the stationary beam enemies not fun because your control would break mid fight causing you to take a hit. I found this out while putting them in this level. Fixed this and it became more fun. I just have to keep doing stuff like that to make the level better. Stuff to do next week. 

This is how it looks right now.