Jumping into a new genre with The King's Dungeon

You can check out the game here: https://adam-danial-krb.itch.io/ggs-2-build-7-the-kings-dungeon

This version of the game was still made using a game engine called "Stencyl" which is a relatively easy to use engine that doesn't require the user to be good at coding.

Key Features within The King's Dungeon

So, an update regarding The King's Dungeon is, that for the Game Development class that this game was made for, we had to add another genre to the game and basically make a hybrid amalgamation between a Beat Em' Up and a Platformer. How fun! So, without further ado, let me take you through the cool new features that I added for the game this time around and my process making them.

Player Jump Mechanic

What does every platformer have? That's right. A jumping mechanic. Most if not all platformers have this mechanic and I would say is one of the biggest thing that a platformer game should have. If not, then well that game is gonna have a hard time trying to convince people that its a platformer cause you can't even jump and platform. With that in mind, that's the 1st thing I started to work in the game.

"Adam", I hear you asking, "Why are you highlighting the Jump Mechanic? Did you come up with some kind of breakthrough with the Jump Mechanic?" To that I answer, no. Not really. I wanted to talk about the Jump Mechanic because I wanted to just state of how proud I am being able to get the darn thing to work in Stencyl. If you read my previous post, you'd know that Stencyl is not really the best game engine. It gets the work done quick but it also lacks quite a few things that can make your life that much easier when programming things in a game. The Jump Mechanic is one of such examples.

I had to basically program the whole thing from the ground up and that itself wasn't hard. No, dear reader. The hard part came when I had to change animations. For some reason, getting animations to change when you are moving and jumping as well as standing still and jumping was a complete nightmare. The issue that I faced was that the Player Character refused to change back to the Idle Animation each time it hit the floor and I spent 2 whole days trying to figure that out. I tried using pre-existing behaviors in Stencyl to help me overcome this issue but nope, my game refused to use the pre-existing behavior and I was forced to program it regardless. Nevertheless, after 2 days, I finally got it to work and the Jump Mechanic had its animation change be on point for each state appropriately.

Enemy Patrol Behavior

In most platforming games that include enemies, they would normally have their Enemy Characters to be able to patrol from left to right. This is to make the Enemies seem more alive and not like a dead statue that just stands there until the player comes near them. In an effort to avoid such a thing, I managed to program in my game a simple patrol behavior for me Skeleton Enemies.

Programming this and making sure it worked in Stencyl wasn't the most challenging thing. It wasn't easy either, so it kind of falls in the middle of being a mechanic that can be easily implemented into the game if you know your way around Stencyl. So, what I did was that I set a behavior that if the player character is not near the Enemy Character, the Enemy will just keep walking left for a set amount of time before turning to the right and walking to the right. This would then just repeat and loop until the Player Character is near said Enemy Character.

So, how did I check if the Enemy Character is close to the Player Character? Well, that was done with the use of a trigger box where I said if the Player Character enters this trigger, the Enemy Character would stop patrolling and follow the Player Character left and right and attack until the Player Character exits said trigger. This way, the Enemy Character would only attack and move towards the Player Character when it is near them and not go wondering off everywhere and anywhere in the level. I also managed to make the time it would take for them to walk left and right when they patrol to be modular so that I can change easily in the scene how far do I want each Skeleton Enemy Character to patrol individually and independently.

Open door by collecting keys

Now, all games require an objective within it that the players must complete in order to beat or clear the level. The King's Dungeon is no exception to that. For the previous genre, I had my player kill all enemies in a room before they can proceed. That idea did not work so well with having a platformer. I wanted an objective that the players could speed run through if they'd like but also force them to encounter and meet enemies. With that as my basis, I came up with the idea to include collecting keys as my game's objective.

This objective works exactly as it sounds like. In order for the player to open the door to progress to the next level, they would have to collect 3 keys in the level. Once they have collected all 3 keys, the door would open and they could pass and enter to the next level. I decided to use this mechanic as my main level objective because by playtesting the game and trying out other level objectives alongside this, most of my play testers enjoyed going around the level and looking for keys.

Why? Well, according to them, it provided some form of challenge in the level where they have to run around the level and avoiding traps and fighting enemies to find the keys. Another reason was that, they were able to explore and see what the level had in store for them. They had to basically explore the whole level in order to find each key and this gave them the opportunity to look around and experience the whole level, which was something that they really enjoyed.

Boss Character in Platformer

If you had read my last post regarding The King's Dungeon, first of all, thanks for that. Really appreciate it, and that you would know that I had a Boss Character made that mirrors in abilities as the Player Character. I did this to give the player the sense that this Boss is almost like rival, someone who is just as good as you and it's up to you to prove who is better. Well, that same Boss Character had to be tweaked in order to make it fit into the whole platformer genre. And oh boy, did that come with a lot of problems.

Getting the Boss to follow and trigger when the Player Character reaches a certain point in the level wasn't the challenge. That was relatively easy to do and I got that down in about 30 to 40 minutes. Now, the bigger problem was when the Boss Character attacked. Whenever the Boss Character were to do an attack, it would not register a hit. For the longest time, it wouldn't. How I made the characters in the game to hit another character was that they would spawn an invisible bullet that would travel and deal damage once it hits the respective character.

I found out when programming this behavior that the Boss King's bullets would spawn above him and at times move in the wrong direction. They were even times that the Boss' bullets wouldn't even register the hit with the Player Character when it clearly would've been one. I spent quite a few days trying to figure out how to fix this and after 6 days, I finally managed to fix the whole behavior and got it work the way I wanted it to. I basically had to ditch the old behavior as it was built for a 4 way movement style game and wasn't able to be modified well to fit the whole left to right platformer genre.

So I just made a new one using the existing Skeleton Enemy Attack and Player Attack Behaviors as my base and guide in helping me program the whole thing. The whole behavior worked perfectly and I was really proud of myself being able to make sure that the idea of a Boss Character was still be able to be included in this version of the game.

Camera Follows Player Character

The final mechanic that I would like to highlight is a rather simple one but a very important one. Which is the Camera Follow Player Behavior.

This mechanic was the easiest thing for me to program into the whole but man, is it useful and important. This whole mechanic basically allowed me to build a larger level in Stencyl without having to show the whole level in 1 screen. I could control and pace each level so that the players would only see what I want them to see at a time as well slowly increase the challenge in the level as they progress through while keeping it a surprise. This by far was one, if not, the most vital mechanic that would have either make or break my game and I'm really happy that I did as I managed to make a really cool and interesting game thanks to it.