About the development of the game

Introduction

The last weekend I've been working near non-stop to get this project out and running. I came into this without a lot of expectations because it's been a while since I joined a jam. But fortunately It's been a really great experience not only for learning but for my own enjoyment. 

The game this time was a challenge in which I had to learn how to use tools of Godot that I had not used previously, like the Tilemap, RigidBodies or Navigation. And I learned a lot about those tools that I will be able to apply in future projects. 

When we started the jam the past friday we wanted to make a horror game in which you had to blink so that you could move, and ther would be a few monsters in the dungeon trying to get to you that could only move whenever you moved. We would make some puzles hiding some keys so that you could open doors, and some toggles that would trigger reactions... You know the kind of game right?

But while testing the alpha versions on saturday we realized that only moving while blinking felt somewhat bad, and we tested a different control for the blinking, putting cooldowns so that you could not blink very fast, and making the blinking a independet system that was handled by timers and the player had no control about. As such we came to realize that the best option would be to make the player move by themselves and to keep the blinking automatic. And whenever the player was blinking a single monster could move to follow the player, but being extremely fast. Thus making this from a puzle dungeon crawler into a big tag game with a big scary yellow-y monster. 

About the development. 

Tilemap Usage

Since the beggingin given the design of the game we thought to use tilemaps to create the world, but I had just a bit of experience using tilemaps and as such I had to learn a lot. Fortunately there are some very wonderful people making tutorials that have helped me a lot. I will link them in the later part of the post so that it may help someone else in the future. 

The basic setup of the tilemap was pretty straightforward, just dropping the tilesheet in the tileset, make everything 16x16 pixels and you could start painting the map. But I wanted to use what in older versions of Godot was called autotile, nowadays is called terrains. Once again going through a tutorial I learned how to paint the terrain and define the corners and sides of the tiles in the same terrain so that the engine could choose what to use. 

In a point in which I needed to use a tile above another tile I saw that I was in need of layers, fortunately the engine keeps providing, define a layer in the tilemap right sidebar, and choose in which layer you're painting on on a dropdown. 

I had a problem with the terrain definition because I believe I painted some of the sides wrong in two terrains because sometimes you can find a corner missing. But I had no time to stop to check whatever happened there. But I'd love to revisit this issue in the future. 

While we were working I started seeing what tiles made sense to use as terrain and what tiles did not make sense. For example, the walls are painted cell by cell, I defined that a column of the wall was a single tile instead of 4, but I needed to do it by hand. In the other hand the bars were painted as a terrain. 

The tilemap allows you to paint Collision shapes in the tiles, making it so that you could go through half of the tile, we used that for the terrain in which you can push a rock, so that you could not drag the rock outside of the area. 

After fiddling with it more I realised that it didn't make sense that the characher couldn't go behind the bars, so I gave collision to the lower part of the bars. While building the level I had to create alternative tiles, which is a copy of a tile but it can have a different collision shape, or navigation, thus creating walls that could be walked through to put doors in them. 

Navigation

I'll  preface this section saying that I have never before worked with navigation, But I must say that is quite fast to implement for a small thing, but I can see that it could be a pain to implement for something bigger if not done carefully since the begginging. When I painted the navigation layer for the enemy I chose to let it go through the areas to push the rocks, the normal terrain and the bridges. I marked this with the navigation layer, and I chose to make the enemy unable to go through the holes in the floor. 

When we got to the point to let the enemy out of their jail I started seeing issues with this approach for the following reasons. 

1. I had used the base terrain for the background out of the maze, and the navigation agent was trying to go through the walls.
2. The last point was also caused by the fact that in a different layer of the walls there was the same tile, the basic one. I had done this to make sure that everything was black when expected. But after realizing this I had to create a new layer for a background, a a new black tile without navigation layer so that the Agent could not try to walk through it. 
3. The collision box of the enemy was bigger than the bridges, and thus we had to make it so that the enemy could go through the bridges. 

I must admit it was quite fun seeing the enemy navigation agent trying to guide it through the void. And fortunately it was also quite easy to fix. What I realised at this point was that the enemy was tarribly fast, and it could catch up to the player in two blinks. So I spent a while trying to get the perfect speed. Though I believe in the future I'd love to make different difficulties with different speeds. 

Physics

This was maybe the less painful part of them all, as I had used parts of this before, although in 3.x versions. First thing I realized what that the KinematicBody was no more and there we had a CharacterBody, but it was pretty much the same for the purposes of this game. I must admit that I love the easiness with which you can define the collision layers and masks to chose with what parts will you collide. It's one of the parts in which I had nothing to worry about. Later down the road I'd end up making up layers that I had not foreseen and not using a few of the ones I though we would need. But in the end hindsight is 20/20.

We had the sunday a funny bit designing the map and Afroskeleton, the artist said that for a puzzle he missed a one way ramp, so that the player could only go through one direction, and I said, 'If you want it I can have it in 5 minutes, just give me the art'. And lo and behold, I had a prototype ready in a few minutes. Just chech an option and go rotate the object accordingly. 

Other than that we had a few times in which I wanted to go into the game and kick the rocks into dust, because I didn't know how to make the game into a grid-based game and make sure that everything only moved one tile in the direction. and as such when we wanted to push rocks around I needed to create something, and there I was out of my comfort zone. 

First I tried with RigidBody, which is a body that can't move by itself and is applied forces. Makes sense right? Well it was a thing certainly. I spent quite a lot of time fidling with it so that it would resemble the idea we had for it. But in the end it was quite terrible, it slipped out of the area, and you could not control the direction quite well. 

Finally we remade the rocks from scratch using a CharacterBody and making it so that the player had an area before them that detects the rocks and pushes them in the direction the player is going to. This worked but created a bug in which the rock sometimes got stuck in the area and followed the character even though we didn't want it to. But sadly we didn't have more time to fix it. 

Learnings

In the end this is a jam without prices and about the learnings and getting outside of your comfort zone. And I tried that. I slept less than usual and spent a lot of hourse before the computer. When I got to bed on sunday I had 3 hours of sleep before getting up to work programming more and my body hurt, but I believed it was worth it. 

What I learned though?

1. How to work better with tilemaps, and how to draw the terrains better. although I need to recheck this part. 
2. How to use tilemaps to paint a level with different shapes and collisions embeded. 
3. How to implement simple pathfinding using A*
4. Making nodes keep track of other nodes in the instance via exports so that the can connect to signals automatically o check if a body entered in an Area and check if it's the specific body that is expected. Even to make some doors only open if the player had picked up a specific key. 
5. We need to give feedback of thing happening out of the player vision. This game has a component in which things happen without the player seeing it, and they may miss them if not done correctly.
6. I need to learn more about level design, as it was done singlehandedly by my teammate. 
7. Finally I learned that I need to learn quite a lot more than I know already so that the next jams I can make better games. 

For the future

There are a few pending issues that I would like to revisit in the future to make it a better experience for everyone. But if I can provide the time to do so I'd love to keep the jam version as is so that we all can compare my learnings. 

Pending issues

• Terrains badly configured in the tilemap making some combinations wrong or missing
• The rock sometimes gets stuck in the player following them to places unintended
• Making the game really grid based

Links

Tutorial about tilemaps

Tutorial about pathfinding

Another tutorial about pathfinding

Last words

I'd like to give my thanks to Afroskeleton, for his help through the weekend and his patience. I know that I may not be as knowledgeable about gamedev as he is, but he is always a love of a person and I love to work with him. 

His work with the art, music and the idea made all of this possible and the ambience was all his. And I must admit that I like a lot the result of the jam. 

Thank you all for this weekend! I'll be playing all opf your games this week.