Indie Devs: Best Practices

Hello, indie devs!

The next thing on the list is having the enemy chase the player. Now, first, the enemy has to determine what the player is. However, the player is not the parent, or the child, of the enemy- so how can we have the enemy determine what the player is?

Assuming you have things set up where the parent is the world, and the children of that are the zombie and the player, you could call the parent by typing in "..".get_node("name_of_node). However, that's a bit sloppy. Instead, you could get the parent, and from there, get the target, as I did here.

Now, what is the rest of this stuff?

The function hostile needs delta to work, but it won't be able to access it on its own, so instead we give it a parameter, and then in _process, pass delta as that argument.

Now, this enemy will chase the player no matter what while set like this- if you don't have the states changed and only have hostile, it will chase the player forever. How do we fix it so that the player is only chased when it is in range, and how do we stop the change_state function?

For the trigger, we could add an area2D, and check if the body entering it is the player, and then switch over to the hostile function.

As for the change_state(), it goes off based on a timer, so you could simply add the name of the timer responsible for state changing, and after that type .stop().

Now, this enemy doesn't move around obstacles, but doing so would be beyond the scope of this tutorial. However, I encourage you to research ways to make the enemies travel in this manner- for a hint, search for information on path finding. For the purposes of this tut, all you're trying to learn is how to build very basic mechanics. Besides, zombies are usually pretty stupid- it wouldn't surprise me if they decide to slam into walls.

Now let's see if you can make your enemies chase the player. I will see you in the next one.

Hello, indie devs!

Has anyone noticed if one enemy detects the player, the entire gang of them from that level comes charging? Let's fix that next. This will also help export var become a lot more helpful.

An easy way to do this is to put somewhere above _ready(), type var enemy_name = self.name. Now, why do that? If you would then have a print function in _ready() for your enemies, you will notice that each enemy has its own name. This means that we can determine which enemy we need to do something. If zombie1 notices the player in its area, it will check if its own name is the one being called while the player is in that collision. This means, even though zombie2 gets the same message, since his name isn't zombie1, he will not go charging after the player.

Alright, we are almost ready to wrap up. We still need a pause menu and a system to interact with our small inventory system, and then we can go through the steps of beta testing and releasing. I will see you in the next one.

Hello, indie devs!

Now, before we get deeper into things and I lose this idea to show you another node.... well, you guessed it- I'm going to show you another node.

This time, it is the particles2D.

It's not much, but, say you are building a game that has a dripping faucet, or a leaky grate in a sewer, this could come in handy. This could also serve as another method to represent damage.

Let's grab a Particles2D, and in the inspector, under Process Material, select New ParticlesMaterial. Now, it will not be very big when you first see it.

From there, what you do with it is up to you. Just have some fun with it and see what all you can do with it. I will see you in the next one.

Hello, indie devs!

Now, before we go crush zombies, the player needs a weapon, right?

Fear not! I am going to show you how to make lasers.

I am using an area2D, as it isn't supposed to react to any physics, but it needs to detect collision. I added a collision shape and a collision shape to match it.

Now, the laser only has to do three things- move in one direction, damage an enemy if it hits one, and leave the screen once it hits something. Here is the basic code I have for that, minus the enemy attacks, that is coming.

You can adjust the speed of the laser as needed, or whatevr in the inspector. Now how do we shoot them?

Remember how the player move on button pressed ui up, ui down, and all that stuff? We can add a new Input for attacking, and assign it to the lasers. To make an input, go under Project -> Project Settings, and then Input Map.

From there, at the top of the panel, there is a text bar next to the word Action. You can type in a name for your action, and click on add to add it as a new input.

After that, locate the new input in the list, and select the little plus button to the right of the new input.

There are different settings for each type of input. I'm going to use the space bar, so I will click on key. It asks me to press the key that I want to use- space. After that, I click on OK. Do not press enter, or else you will switch your input to the enter key.

And, there you have it! Your very own custom input!

But how do we use it?

First, we need to make the laser its own scene, so right click on it and add the branch as new scene.

Next, in the Player Script, add this line of code in the get_input function:

However, we have one issue. When we use Attack after pressing play, the laser follows the player's movements. How do we fix that? If we now use remove_child, it does not work.

The issue is that the child is following its parent node, so we need to find a parent that is not going to move... like the root node.

Now, when you shoot the lasers, in your SaveData, you would want to subtract a "bullet" from your stash.

Your code would then look something like this.

Also, a nice little trick you can do with lasers is add a shadeless canvas material, and a light2D.

Have fun making your weapons, and I will see you in the next one.

Hello, Indie devs!

Has anyone been having issues with their lasers, you know, only shooting in one direction, and not keeping track of how many lasers you actually have?

Let's fix that.

The easiest thing to fix is the weird countdown. Instead of using Input.is_action_pressed(), we can use Input.is_action_just_pressed(). This will keep the action subject to only firing once, whereas the previous method just keeps spamming the action.

Okay, next, we'll tackle the directions.

For directions, we can add pre_dir to the player, and set it equal to Vector2(0, 1), or whichever way your player is facing. Mine is initially facing down.

Now, we change the get_input() to this:

Then, we adjust our laser function:

This will allow you to zap enemies in all directions, but it still doesn't change the direction of the sprite.

The sprite, however, is easy. if the laser's laser_dir.y is not equal to 1, the sprite's rotation_degrees is equal to 90.

That's my challenge for now. I will see you in the next one.

Hello, once again, indie devs!

Have you notice, lately, how the player is being crowded? My zombie will not leave the player along yet refuses to fight him. Chances are, your orcs, zombies, robots, and whatever, are not letting your player sleep, either. The player knows it has a weapon, but it is useless at this point.

Let's change that.

Going back to the enemy, the enemy has an area2D, correct? We'll use that to have it detect damage.

First, let's put the laser's collision shape in a group- I'll call it laser. Then we go to the enemy, and get the signal on_area_entered(area).

From there, we add this:

And we can see at the bottom that it worked!

Now, things are not so fair for the enemies, are they?

Well, they will have to wait until next time!

Hello, indie devs!

So, how do we make the enemy attack the player- ya know, to get a little revenge for them being helplessly attacked first?

The method I used was to have an animation player connected to the zombie, and I then attached another area2D as well. The animation player has an Attack animation, and an idle animation. (This was unintentional, as it caused some problems later on.) After that, I set the area2D to be called Attack, and, in the animation player, I disabled/enabled the Attack's collision shape.

For the test, I left the speed at 1, but I will change that later.

For the zombie script, I added the signal on Area Entered, and set it up like this:

And, as you can see, it works!

Now, why did I multiply the damage by 0.01? Well, if you remember, we had a progress bar in an earlier section, which had a scale of 1. The health bar, most likely, is also set up this way.

Now, I made one little mistake here at first, and I'm addressing this as this is so easy to do. I accidentally made the idle animation "idle", instead of "Idle". It still works as an animation, but if you call the animation "Idle", it will not work as it is case sensitive.

Now, we have one more problem- the attack only attacks once per hitting the player. To fix this, make sure your attack animation is being looped.

Now the player and enemy can fight each other!

So, what's next?

The pause menu.

I will see you in the next one.

Hello, indie devs!

So now that you have your game mostly done, completed with all the action from your heroes and villains... how do you make it stop just long enough to go to the options menu?

For me, I have added a new Control node to the player, as I have him in each of the scenes- and in the inspector, you will notice something called Pause Mode. It is currently set to Inherit.

What does this mean?

It means that it will inherit the method which this node's parent handles being paused. We don't want that, we want the player to stop moving on pause. To fix this, we switch the mode to Process. If you don't have anything set to Process and you pause the game, it will freeze everything.

Now, how do we pause the game? Through a new script.

Now, if you didn't rename your last Control nodes, then you will notice that we can load the Control script- we don't want that. So, we'll rename the Control node and/or script and click on create.

To pause a game, we use the line get_tree().paused = true. However, we need to also be able to switch it to false when we're done as well.

This will be handy to get you started with a pause menu. From there, you can also add a UI that needs to appear after Pause is triggered, but, again, make sure the UI's pause mode is set to Process.

So, set up your pause menu/ UI however you want, and I will see you in the next one.

Hello, indie devs!

Now, before we dig into the last few parts of this, there is something you should know which will make your lives so much easier: get_children() in a for loop.

First, what is a loop? A loop is something that will do something within a certain period of time.

Now, for get_children().

Let's say, in the pause menu, you have a lot of child nodes which serve as buttons:

You could type something like button1.visible = true, button2.visible = true, and so on. However, this is rather time consuming. Instead, you can use get_children and put them in a for loop to grab each child node, and set them each to be visible or not, like so:

Hopefully, this will help you as you build your game, and the rest of your games in the future. I will see you in the next one.

Hello, indie devs. Are you ready to finish up the game?

It's getting close. You may even have already claimed your game is finally done- which is fantastic! There is, however, a nice trick that some games have which makes the players like it a little more.

Choosing the character.

How can you switch your character to be another character?

First off, how many different characters do you want to be able to choose from in your game? This is important. Each different animation, if it's being done with an animated sprite or animation player, will need to be named based on the type of character it is, or by its number. I will use a letter for this test, which I saved for the main player. For enemies, you can just have the code randomly pick a number, so you won't have to actually save it for them.

Why have the animations marked with a letter or name? Check out the code:

If I wanted another character, say, a female, I could instead use f_idle_down, and all the other animations, and because it starts with an f, if I use a button to switch the m to the f, the code will perfectly for the female character. You can do the exact same thing for multiple characters, and just change one little letter and make something to switch characters automatically for you.

The next part might take a bit to actually make, as I still have to finish up this game- still, if you have already read all of this, you have gotten very far. If your game is done, great! Make another one, then! You can release as many games as you have, right?

My challenge for you now, however, is a rather long one- but it is something you have to do before you release your game. This is actually a two-part challenge.

1: Go back and look at the assets you have used for your game, and do everything to ensure their licenses are being followed. If you don't know what license something has, pick something else, unless you would like to get in more than a little trouble with the law. I don't mean to scare you. After coming so far along with your game, you need to follow the rules so you can be successful. Also, make sure you follow the license for Godot.

2. Once you have set up everything and your game is done, find some friends to play your game- but not just anyone, you need to find friends who want to see you succeed- they could be family members, friends from wherever you work or study, it could be at a church you go to, wherever. Pay attention to their reactions to the game, as they will offer you your first game reviews.