Jump to content
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
  • Advertisement
  • Blog Entries

  • Similar Content

    • By CommanderLake
      I've been experimenting with my own n-body simulation for some time and I recently discovered how to optimize it for efficient multithreading and vectorization with the Intel compiler. It did exactly the same thing after making it multithreaded and scaled very well on my ancient i7 3820 (4.3GHz). Then I changed the interleaved xy coordinates to separate arrays for x and y to eliminate the strided loads to improve AVX scaling and copy the coordinates to an interleaved array for OpenTK to render as points. Now the physics is all wrong, the points form clumps that interact with each other but they are unusually dense and accelerate faster than they decelerate causing the clumps to randomly fly off into the distance and after several seconds I get a NaN where 2 points somehow occupy exactly the same x and y float coordinates. This is the C++ DLL:
      #include "PPC.h" #include <thread> static const float G = 0.0000001F; void Compute(float* pointsx, float* pointsy, float* points, float* velx, float* vely, long pcount, float aspect, float zoom) { #pragma omp parallel for for (auto i = 0; i < pcount; ++i) { auto fx = 0.0F; auto fy = 0.0F; for (auto j = i + 1; j < pcount; ++j) { const auto dx = pointsx[i] - pointsx[j]; const auto dy = pointsy[i] - pointsy[j]; //if(px != px) continue; //most efficient way to avoid a NaN failure const auto f = G / (dx * dx + dy * dy); fx += dx * f; fy += dy * f; } for (auto k = 0; k < i; ++k) { const auto dx = pointsx[i] - pointsx[k]; const auto dy = pointsy[i] - pointsy[k]; //if (px != px) continue; const auto f = G / (dx * dx + dy * dy); fx += dx * f; fy += dy * f; } pointsx[i] += velx[i] -= fx; pointsy[i] += vely[i] -= fy; if (zoom != 1) { //replacing this with a direct assignment as below does not help points[i * 2] = pointsx[i] * zoom / aspect; points[i * 2 + 1] = pointsy[i] * zoom; } else { points[i * 2] = pointsx[i] / aspect; points[i * 2 + 1] = pointsy[i]; } /*points[i * 2] = pointsx[i]; points[i * 2 + 1] = pointsy[i];*/ } } This is the relevant part of the C# OpenTK GameWindow:
      private void PhysicsLoop(){ while(true){ if(stop){ for(var i = 0; i < pcount; ++i) { velx[i] = vely[i] = 0F; } } if(reset){ var r = new Random(); for(var i = 0; i < Startcount; ++i) { retry: pointsx[i] = (float)(r.NextDouble() * 2.0F - 1.0F); pointsy[i] = (float)(r.NextDouble() * 2.0F - 1.0F); if(Math.Sqrt(pointsx[i]*pointsx[i] + pointsy[i]*pointsy[i]) > 1.0F) goto retry; velx[i] = vely[i] = 0.0F; } pcount = Startcount; buffersize = (IntPtr)(pcount*8); updatepcount = true; reset = false; } are.WaitOne(); NativeMethods.Compute(pointsx, pointsy, points0, velx, vely, pcount, aspect, zoom); var pointstemp = points0; points0 = points1; points1 = pointstemp; are1.Set(); } } protected override void OnRenderFrame(FrameEventArgs e){ if(updatepcount){ Title = pcount.ToString(); updatepcount = false; } GL.Clear(ClearBufferMask.ColorBufferBit); GL.EnableVertexAttribArray(0); GL.BindBuffer(BufferTarget.ArrayBuffer, vbo); mre1.Wait(); are1.WaitOne(); GL.BufferData(BufferTarget.ArrayBuffer, buffersize, points1, BufferUsageHint.StaticDraw); are.Set(); GL.VertexAttribPointer(0, 2, VertexAttribPointerType.Float, false, 0, 0); GL.DrawArrays(PrimitiveType.Points, 0, pcount); GL.DisableVertexAttribArray(0); SwapBuffers(); } These are the array declarations:
      private const int Startcount = 4096; private readonly float[] pointsx = new float[Startcount]; private readonly float[] pointsy = new float[Startcount]; private float[] points0 = new float[Startcount*2]; private float[] points1 = new float[Startcount*2]; private readonly float[] velx = new float[Startcount]; private readonly float[] vely = new float[Startcount]; The compiled x64 AVX versions can be downloaded from my server here:
      How it should work:
      Single thread: http://commanderlake.net/PPsingle.7z Multithread: http://commanderlake.net/PPmulti.7z   Current broken version: http://commanderlake.net/PP.7z   Edit: It seems that adding 3 zeros to G increases the accuracy of the simulation but I'm at a loss as to why its different without interleaved coordinates.
    • By Sergio Ronchetti
      Continuing to work on “Eldest Souls” (first article here!), I’ve begun familiarising myself with the workflow between Fmod and Unity, and the integration system. I know much of this will be pretty obvious to most, but I thought I’d share my thoughts as a complete beginner learning the ropes of sound designing. 
      The library of sounds that Fmod provides has been very useful, at least as reference points. I’ve still kept to my ethos of producing the sounds myself as much as possible. Having said that, Fmod gives you 50 free sounds with your download, and I’ve used a wooden crate smash, a drawbridge and electricity sound you can hear in the foley video below.
      The thing i found most useful was witnessing changes i made in Fmod being realised instantly in Unity. If a volume needed changing, or the timing of one of my effects was off, i can literally switch to Fmod and then back to Unity and immediately see the result of my alterations. It also seems apparent that using middleware such as this (or i've heard Wwise is also equally intuitive) grants the developer, and myself included, a great deal more flexibility and opportunity to edit sounds without going all the way back to a DAW, and bouncing down again. Needless to say, my workflow is so much faster because of it.
      I've also loved the randomised feature of Fmod, whereby any sound can be made to sound slightly different each time it is heard. Taking a footstep recording i made for example, I was able to add further authenticity of uneven footsteps by randomising the pitch and volume of each playback. 

      I used this technique when creating footsteps for the first major boss in the game called "The Guardian". A big, over-encumbered husk of a monster. I also had fun rummaging through the garage for old tools and metal components for the “Guardian” (the first boss) footsteps. See below!
      I also created a sword attack for our player, trying to sound different from the generic “woosh” I see in so many video games. I used a very “sharp” and abrasive sound to differentiate him from any enemies.
      On another note, I recently upgraded my microphone to a Rode NTG2 shotgun, which has been phenomenal. I haven’t had to worry about noise interfering with the clarity of my objects, whereas before with the sm58 I had to be clever with my EQ and noise reduction plugins.
      Important to note again that this still a “cheap” mic in comparison to most other products on the market, and all in all my entire setup is still very simple and affordable which I’m quite proud of. I’ve seen many musicians spend heaps of money on gear they don’t necessarily need. I much prefer being resourceful with less equipment, than to have more than I can understand or remember how to use.
      It’s forced me to understand every aspect and capability of my tools, which I believe is a principal that can be applied to any discipline.
      I have more fun little sound effect videos on my Instagram for those interested, where I post regular updates. Thanks for reading! (if you’ve made it this far)
    • By Sergio Ronchetti
      Recently I joined the talented team at Fallen Flag Studio as the composer for their latest release "Eldest Souls" which consequently lead me into a field I have always dreamt of trying - sound design!
      Having no prior experience, I began watching a few online tutorials (if you want to learn from anyone make it Akash Thakkar from "Hyper Light Drifter"... what a guy!) and basically just testing stuff out i found around the house. Luckily my dad has a garage FULL of random crap to use.
      Before i continue, it's important to note that i DO NOT have fancy equipment, meaning anyone can try this. (my equipment is an sm58, focusrite scarlett interface and Logic Pro X plugins... that's it!)
      I started basic with some footsteps, which weren't all too difficult. Then I moved on to projectiles and a spear attack one of the bosses has. Below are a couple super short videos on my resulting attempts.
      Amazing how great a banjo sounds for that typical "woosh" sound! And if you're wondering, the paper was added to give some texture to the jab.
      I could be finding a lot of these sounds in libraries online (like the built-in ones that come with Fmod and Unity) but I've chosen not to, in order to produce authenticity and hopefully a more unique gameplay experience for players when the final product is put together.
      P.S. if you'd like to try the game and hear my hard work we'll be at EGX and several other conventions later this year, soon to be announced! Thanks for reading!
      To those interested, there's an Alpha trailer of the game in question below.
    • By OConquestGame
      Hello there!
      I’m the creator and producer of an upcoming visual novel / video game. 
      My team and I are looking for artists (character and background), writers (experienced in writing relatable characters and witty dialogue), and programmers (familiar with unity and creating mini games). 
      Our team is a group of close friends looking to break the mold of the traditional visual novel and create something new and positive. This game will be highly promoted and be a great portfolio piece. Rates are negotiable!
      If you are interested please contact/message us today! OConQuestGame@gmail.com
    • By Kamal Wafi
      Hi there,
      i recently start learning unity and im working in my first game ,
      I was wondering if unity had functions to support the motion control effect (tilting screen to move character) you see
      in doodle jump (which is 2d game) ? If it exists, what are they called? and how it works ?


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!