Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

March 24, 2018 Weekly Update - Untouched Earth Game Development Blog



A lot of exciting updates this week! I spent a good amount of time updating the enemies and creating new challenges for the hero to deal with in the game world. I also fixed a few bugs that were causing some minor annoyances and affecting game play.
***This blog post is copied from a post on the game's website. The original post can be found here***
Update 1: Added a slider cable
I added a new element to the game that allows the hero to grab hold of a "sliderCable" object in the form of a vine or rope and use it to slide down a longer vine. The mechanic threw a few curve balls at me, but overall didn't take more than about an hour to develop. It still has a few kinks to work out, but is functional and fun. The main challenge was getting the hero to stop abruptly when he reached the end of the vine. As you see from the video below, he was overshooting the vine and falling off the map.
The mechanic is pretty simple. The long vine has a trigger collider at the end of it called a "stopPoint." When the stopPoint triggered by the hero, it activates all of the RigidBody2D constraints on the sliderCable to instantly stop the sliderCable and hero. Needless to say, it wasn't working that way. The sliderCable was using a SliderJoint2D, so I spent some time researching complications associated with the joint. It turns out the problem was with my code. When the hero initially grabs the sliderCable, the sliderCable code turns off the RigidBody2D constraints in order to allow the SliderJoint2D to take over. This is where the problem developed. The hero was being separated from the sliderCable as it was sliding and then touching it again when it stopped abruptly. By touching it again, the RigidBody2D constraints on the sliderCable were turned off by the code right after they were turned on by stopPoint code. After changing a few lines of code around, it worked great! It's a really fun game mechanic, just has a few more bugs to fix.
Update 2: Made enemies turn red when hit
I wanted to make it more exciting and noticeable when the character strikes an enemy, so I decided to turn the enemy characters red when they get hit by the hero. I thought it would be as simple as adding a coroutine that turned the enemy red, waits a few seconds, and then turns him back to his original color. Turns out it wasn't that simple. Since the character uses bone based animation (meaning tons of little sprites make up the character), I had to load the enemy's original colors into an array in the Start() method and then copy them back at the end of the coroutine. Success!
The "ren" variable is a reference to an array that holds each sprite's SpriteRenderer component. The "color' variable is a reference to an array that holds the original color of each sprite. I copied the original colors in the Start() method.
Update 3: Added new enemy characters
I created two new enemy characters. They're fantastic! They are both based on the "explorer" enemy - Thank you HQ game assets for making great assets! - I had to do a little creative artwork to make them look unique, and I must say they look great. One of them is a tiny little guy that moves fast, jumps, and evades the hero's attacks. The other is a big, slow enemy that has a powerful attack and doesn't move when hit by the hero. Super exciting!
Update 4: Fixed wall jumping bug
There was a very annoying little bug that allowed the hero to jump up any 90 degree wall he wanted to. The bug was definitely exploited by some of my testing team (wife). I wasn't quite sure how to fix it at first, and ultimately had to add some new code to the CanJump() method of the hero's Detection Manager. It turns out the character's detection points were determining that he was eligible to run and jump whenever he was colliding with a wall, regardless of whether he was colliding with the wall while suspended in midair or not. 
Needless to say this isn't the behavior I was going for. I ended up creating a few conditions that dictate when the hero is able to jump. Basically, he has to be touching a piece of world that has a "Movement tag" (tags for objects that the hero can run on), and, if the front detection point (fp_2) is active, then the front non static ray will check whether there is a wall in front of the hero. If there is a wall, the hero is not eligible to jump unless his fp_Main detection point is active. It works so far, but I'm wondering if another bug might pop up from this fix. I'm open to any suggestions on how to deal with this type of problem.
This code is from the hero's detection manager. Make sure you read the Game Mechanics section of the web page to fully understand what I mean by detection points, detection manager, fp_2 and fp_Main as they are game specific scripts and gameObjects.
Update 5: Fixed standing on enemy bug
I've been having an issue where the hero lands on top of an enemy, and is then able to stay standing on top of him. This glitch allows the hero to safely ride the enemy around the map, and makes it hard to get off of the enemy when standing on his head. It was definitely taking the fear out of the fight.
I struggled with coming up with a good solution, but ultimately decided to make the hero bounce off enemies when he touches them. The solution was relatively simple, and involved the creation of game objects with BoxCollider2D components attached. These game objects create an outline of the enemy and each have a script attached called "BouncePoint." You can see the full script below. When the character hits one of these bounce points, he bounces off the enemy in a direction determined by the BouncePoint script. I was looking at using a physics2D material, but was having trouble getting it to work. Instead I just added a force to the hero when he collides with the collider. So far it works great!
This is the entire BouncePoint script. heroScript and enemyScript reference the scripts attached to the hero and any enemy. The bounceValue is used to determine which direction the hero should bounce in. The direction is dependent upon the direction the enemy is facing.
Any thoughts on how to improve some of these mechanics are welcome! Any questions are also welcome! feel free to comment or contact me at watermoongames@gmail.com. 
***This blog post is copied from a post on the game's website. The original post can be found here***


1 Comment

Recommended Comments

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!