Indie Quest -- Week 11; refeaturing news - Castle Mashers

Indie Quest — Week 11; Refeaturing

This is the tenth entry in my devlog about my endeavor in making a game within 2 months (supposedly ) and releasing it as part of my course’s capstone. You can read the previous entry of the series below:

Indie Quest — Week 10; refactoring
This is the tenth entry in my devlog about my endeavor in making a game within 2 months (supposedly ) and releasing it…medium.com

This is another week of internal progress, albeit I’ll try to show as many things we’ve done as possible. Let’s get started…

Misc:

Refactoring the code was completely done and I am really happy with how it turned out. I mentioned I have created a manager for most general things happening in the game (WaveManager, XPManager, GUIManager, etc…) with the GameManager holding everything together and well… managing the managers.

However, it dawned on me a few things while working on the game. First the wave system was dragging the length of each level. At first I started out with a target of 3–5 minutes for each level — 7 minutes is the maximum allowed per level. With the introduction of waves, the length of the average level jumped to twice that much. That wasn’t acceptable.
The reason behind that, previously, waves made sense since the enemies ran into the fire at the bottom of the screen and died like below:

But with the respawning system introduced in the last update, that made the level much longer. So we scrapped that and now you don’t fight waves, rather only the enemies you see in a given level.
That said, we are dabbling with the idea of unlocking endless battle mode at the moment. The game does give way for something like to be implemented — we’ll have to see how things turn out though, too early to tell at this point.

The second most important update in design is the main mechanic of the game. It was mentioned that the game is static — it feels like Breakout. You throw a ball and then you idle till it comes back. It took me a few days (we’ll talk about the technicalities in the Code section) to implement a new system.
The idea is that instead of a ball, you throw a weapon at your enemies, the weapon ricochet off walls but goes through enemies (or bounces off them dependent on the type of weapon you have). A certain number of “bounces” is allowed before the weapon is broken.

As an example, the Knight would use a spear or a javelin. He throws it at the enemy, it goes through the enemy doing some damage, bounces off a wall (both going through an enemy and the bouncing deduct from the “lifes” the spear has) perhaps then it gets destroyed completely. You start the level with X amount of spears and if you use them all, you have to wait Y amount of time for them to recharge.
Here is a quick (and badly drawn) sketch of how it would look like:

The top left corner; there is the usually displayed picture and the dashes below it are the number of spears you have until you wait to recharge.
Hopefully by next post (or even earlier than that) we’d have 2 versions of the demo for testing and feedback.

Bugs and Code:

It isn’t easy to let go of something you’ve worked many hours (and in this case days) on. The WavesManager literally took me close to 78 hours of work. While it may seem an easy task and many programmers can write it up in their sleep, it wasn’t that easy for me. I always faced some kind of bug and mostly had to resolve it alone.

After finishing the code for the WaveManager and it working 100% as I liked it to, I decided to scrap it as mentioned above, the time per level changed quite drastically.

Once I got over that I started working on the code for the new mechanic. It didn’t prove easy at first as I wasn’t sure where to start with making a projectile slow based on number of collisions but I finally found a way.

Here is the code so far:

using UnityEngine;
using System.Collections;

public class PlayerProjectile : MonoBehaviour {
	
	public float Speed;
	public float buttonPressedTime;
	public float DragConstant = 0.2f;
	private Rigidbody2D rb;
	public int Strength;
	
	public int WallStrengthReduction = 2;
	public int EnemyStrengthReduction = 1;
	
	private Vector3 direction;
	private LayerMask oldLayer = LayerMask.NameToLayer("Default");
	private LayerMask voidLayer = LayerMask.NameToLayer("Void");
	
	void Start () 
	{
		rb = GetComponent<Rigidbody2D>();
		
	}
	
	public void Launch()
	{	
		GameManager.instance.ProjectileThrown = true;
		float totalTime = Mathf.Clamp(Time.time - buttonPressedTime, 0, 1);	
		Vector3 mousePosition = Camera.main.ScreenToWorldPoint(Input.mousePosition);
		
		if (totalTime >= 0.5f)
		{
			Strength = 4;
		}
		else if (totalTime < 0.5)
		{
			Strength = 2;
			Speed = 0.035f;
		} 
		
		
		
		
		transform.parent = null;
		rb.isKinematic = false;
		GetComponent<CircleCollider2D>().isTrigger = false;
		
		direction = mousePosition - transform.localPosition;
		Vector3 rotation = direction;
		direction.Normalize();
		rb.drag = 0;
		rb.AddForce(direction * Speed);
		float angle = (Mathf.Atan2(rotation.y, rotation.x) * Mathf.Rad2Deg);
		Quaternion qAngle = Quaternion.AngleAxis(angle, Vector3.forward);
        transform.rotation = Quaternion.Slerp(transform.rotation, qAngle, Time.deltaTime * Speed);
		// implement mechanic where you target a location on the map and drag for force.
		// The projectile then caluclates the force and then launches toward the location.
		
	}
	
	void OnCollisionEnter2D (Collision2D other)
	{
		if (Strength > 1)
		{
			if (other.gameObject.tag == "Wall")
			{
				Strength -= WallStrengthReduction;
				rb.drag = DragConstant * EnemyStrengthReduction;
			}
			else if (other.gameObject.tag == "Enemy")
			{
				gameObject.layer = voidLayer;
				Strength -= EnemyStrengthReduction;
				rb.drag = DragConstant * WallStrengthReduction;
			}	
		}
		else if (Strength <= 1)
		{
			if (other.gameObject.tag == "Wall" || other.gameObject.tag == "Enemy")
			{
				GameManager.instance.spawnBall.DestroyBall();
			}
		}
	}
	
	void OnCollisionExit2D(Collision2D other)
	{
		if (other.gameObject.tag == "Enemy")
		{
			gameObject.layer = oldLayer;
		}
	}
	
	void Update()
	{
		if (rb.drag < 0.02f && Strength <= 1)
		{
			GameManager.instance.spawnBall.DestroyBall();
		}
	
	}
}

The idea is that we setup an int that represents the strength of the projectile (i.e. how many bounces it can do before it dies). Each bounce the number decreases as well as some drag is being applied. Once the number reaches 0 or the drag reaches less than 0.02 then the projectile gets destroyed right away.

It is crude but it does what I want. However, what is proving quite tricky is the part where I want the projectile to pass through the enemies rather than bounce off of them like the walls. This has me hitting walls for the past day.
You can see from the code I switch layers on the moment of collision from the “Default” to a “Void” layer. The “Void” layer doesn’t collide with anything and it setup to hold the projectile temporarily until it passes through the enemy.
It is all well and dandy but testing this, it doesn’t actually work. The first collision occurs no matter what and it bounces off the enemy. The next collision however is registered and the switch to “Void” takes place, yet, it never switches back to “Default”.

I have thought about using Physics2D.ignoreCollisions() but it produces similar results. Only difference it takes a few collisions before it actually finally does the switch and never switches back again.
This is also the main reason I didn’t add any demos today for feedback. I couldn’t get it to work right. Hopefully I get it fixed by next Monday.

Art; Graphics and Eye Candy:

As always our relentless Serg is working hard on the art department — knock on wood — he has drawn a few concepts, here are they below:

This is one of the most tricky enemies in the game; a goblin. I had a hard time choosing with Serg which one to go with but finally we went with the below version (colors are final):

On the other hand we have the dark wizard this is by far the hardest enemy you’ll face in the game that isn’t a boss:

I loved the last one the most honestly. Not sure why, but it captured the darkness without being as cliched as the first one or necromantic as the third. So we went with it.

But what proved challenging is getting the player to look right. In our previous post we had the weapon extend to form a stick where the ball bounces off. It didn’t look realistic to have the shield look the same as before. So we managed to spice things up and change how it looks:

Right now Serg has stopped working on the player sprites to test the new mechanic and wait for its feedback. If people like it, the sprites will change again. If not, then we’re back to where we are currently and he can continue on. Meanwhile, he is working on new animations for the Rat, Goblin, Wizard and another background the Throne Room which you can see a final sketch below:

On the other hand we wanted to create a trailer that would showcase what we’ve worked on so far. It would prove useful later on. I have been working on it before the feedback came that spurred the new mechanic change. However I thought it wouldn’t hurt to continue and make it anyway.

Unfortunately I am not a professional video editor (trailer maker?) so I tried my best to adhere to what I know about trailers

• Short video that is 1 minute tops.
• Don’t use introductions, just get into the important parts.
• Showcase the gameplay and show it well.
• Describe your game; show don’t tell.
• Awesome music.
• Great effects.
• Go with a bang

Sadly I know I lack on the “great effects” and the whole “go with a bang”. Like I said, I never made trailers before I am not into video editing and I don’t know any software (aside from Microsoft Movie Maker — which is obvious I used it) that creates professional trailers. Here is what I got:

Not much huh?

Progress Results:

While I mentioned before that we are approaching Alpha, it seems the feedback pushed us a bit behind and many things need to change to look more polished. I am not of course blaming feedback, I have to say I would LOVE to get more of it. The more feedback, the better the game.

Hopefully by next week we have 2 demo versions that you can compare side by side and help us out by giving us feedback on which you prefer and why. That said, if you’d like what you’ve read so far or tested in the build, consider subscribing to our newsletter (if you don’t want to signup for Medium) to get instant news:

Castle Mashers
Castle Mashers Email Formseepurl.com