### **Introduction** ___ Hey guys! How are you doing? Today I’m here to post for the first time on my new account! I used to post content here on Hive Gaming about RPG Maker around two years ago — my account was @teteuzinho. I was developing a game in that engine and shared some content here, but I ended up dropping the project and started focusing on another one with proprietary graphics. Right now, I no longer have those projects — my hard drive died (the second one I had bought, lol), and those two projects, along with others I had been working on after I stopped posting, were unfortunately lost to the void. But the reason I stopped posting was because I was unemployed and needed to find a job here in my city. Now that I’m more settled, I decided to start from scratch with a new account and post something I enjoy doing. About two months ago, I came across another engine with the same concept as **RPG Maker** — making game development easier without the need for direct programming — called **GDevelop**. Even though the concept is similar, **GDevelop** is much more complete, and the possibilities are huge, unlike **RPG Maker**, which is more limited. I also used **Game Maker Studio 2**, but since my goal is to develop games as a hobby, I didn’t want to invest more time learning that engine. Well, now let’s get to the main topic of this post — the game I’m working on. ___ ### **Frogario Bad Adventure?** ___ As you read in the title, the game’s name is Frogario Bad Adventure! Why this name? Well, there’s no big mystery — it’s a mix of Frog + Mario (very creative, lol), and this will be a pretty troublesome adventure for Frogario! This little ninja frog will face obstacles that may seem simple but require a fair amount of precision from the player. This version I’m sharing has only one level, but it’s fully playable. I plan to create more levels and improve the level design, which is pretty terrible in this version. Now I’ll show a bit of the development process, but if you want to give it a try, [click here](https://gd.games/alucardy/frogario-bad-adventure-) to be redirected to the game’s page. You can play it directly from your browser. **Note:** The double jump is disabled on some platforms to increase difficulty, but I didn’t add any warning about that. The game page displays ads, I disabled them in the settings to prevent ads from showing, but they are still appearing here. ___ ### **Development Process** ___ The first thing I did was look for the assets I’d use in this project in GDevelop’s own store — they offer a lot of resources, from sprites to music and sound effects. I’m using a set of public domain assets created by [Pixel Frog](https://itch.io/profile/pixelfrog-assets). Even though they’re great, I felt like some things were missing, like trees, bushes, and rocks to decorate the environment. After searching for these resources in the store, I couldn’t find any that matched Pixel Frog’s art style, so I decided to create them myself. ___

https://files.peakd.com/file/peakd-hive/alucardy/EoCj9gJRiqgrtgFGNirKBDS9rPpSN5hC9aYzxSbqimbUiYuVzpbhG96jKByJk527iau.png

https://files.peakd.com/file/peakd-hive/alucardy/Eoa17epEYPpGtBuqX2q5ZyDNaUDLouEg8GPTxknEvkQUgfR4GGC2kU4DdRKcAGikxKo.png

___ This was my first attempt, but the result wasn’t very pleasing. This more detailed type of tree doesn’t really match the simpler graphics. I’m not a Pixel Art professional, but I honestly didn’t like the final result. I tried removing some details and creating a simpler version, but that didn’t turn out great either. Because of that, I decided to go with a different, more minimalist style that I felt blended better with the existing art. ___

https://files.peakd.com/file/peakd-hive/alucardy/EoAc9yC7Pr3uGDCtHJyeNERk3JnfA8JZ7S6wKGmt541o9iMBdKhDp2UVU3wwsViHdmR.png

https://files.peakd.com/file/peakd-hive/alucardy/EoyPVMvzaXrXJfr9YKfaqE5W43b57oWiTnrdnjW2pQNSLWJSA1Tr1EAQKwf9CKnEXdo.png

___ And this was the result I liked the most. I remember seeing this square-style tree in some game, but I can’t recall which one — still, I thought it would fit this scene really well. I kept it simple and avoided too many details so it wouldn’t look overdone, following the same style as the other assets I’m using. I considered adding some clouds and rocks, but I wasn’t happy with how they turned out, so I went with a background image I found in the store, created by [pzUH](https://www.gameart2d.com/freebies.html). Even though it’s not in Pixel Art, I liked the final result. To wrap things up, I’ll show a bit of the "programming" — specifically the double-jump mechanic I created. In game development, there are many ways to build a game’s mechanics, and even though GDevelop simplifies things, the principle remains the same. ___

https://files.peakd.com/file/peakd-hive/alucardy/EowEkRxnqYVK5wZiAKEKWCPcm59jxZ7gXsbUmDxUpatAEHPrbMgM5xyaTyXXgS6SNRy.png

https://files.peakd.com/file/peakd-hive/alucardy/23yd1qWnjGeXVmJrD9LiviThsZFrSzFSrTa5C8JgdgzxhArDrXi6SfpEe4NBDJcMthDiz.gif

___ Alright, in this first image, we can see a sequence of events that make up the double-jump mechanic. The first one we need to analyze is the **Jump** event **(highlighted in yellow)**. For this project, I used a built-in behavior called **Platformer Character** from the engine itself, which automatically sets up basic commands like running and jumping — so I didn’t have to write any code manually. In short, this sequence of conditions and actions in the **Jump** event only serves to trigger the jump animation and sound effect. If I disable this part, the character will still be able to jump, but the initial jump animation and sound won’t play. An interesting detail here is the condition that checks if **NinjaFrog is Jumping** — it’s not strictly necessary, but I chose to include it because I found a minor bug in the audio. It didn’t happen often, but it bothered me. The sound effect would sometimes play multiple times at random moments, so I added this condition specifically to avoid that and ensure the sound effect only plays when needed. Now, let’s move on to the sequence of events that make up the **Double-Jump** mechanic. ___ First, I created two global variables used in the initial sequence of events — **Double Jump Count (highlighted in yellow)**. You’ll notice that the first condition checks if the **Double Jump Off** variable is set to **False**. By default, I set this variable to **False**, which means this condition will always execute the action that adds **+1** to the **Double Jump Count** variable every frame. Inside this condition, I added two more conditions to prevent the player from using the **Double Jump** more than once, with a visual indicator. The first condition checks if **Double Jump Count** is **Greater Than or Equal to 100**, and the other checks if it’s **Less Than or Equal to 99**. As you can see, if either of these is true, the text indicating whether the character can use the double jump is updated. But these two conditions can only be executed if **Double Jump Off** is set to **False**. If I change this variable to **True**, no condition or action inside the main condition will be executed. I did this because on some platforms, the double jump is disabled when the character collides with a specific platform. For example: If **NinjaFrog** is colliding with the **Grass Platform**, I change the **Double Jump Off** variable to True. With that, the double jump can’t be executed. ___ If you look at the last sequence of events — **Double Jump (highlighted in yellow)**, where the actual **Double Jump** will be triggered — there are several conditions that need to be true for it to work. In other words, if any of them is **False**, the player won’t be able to perform the double jump. As you can see, there are four conditions, although there are five in total. I’ve disregarded the **Trigger Once** condition, which is also included in the other event sequences. Alright, let's break down what will happen. When you jump once, the logic is that you’ll start falling right after, so the first condition will be true. Then, when you press the jump key again, that condition will also be true. The third condition wasn’t part of the first version of the **Double Jump** system, but I discovered a bug where this sequence of events would trigger before the initial jump when the player jumped near the **last pixel** of the **platform’s collision**. To fix this issue, I added this condition, and with this new addition, the problem was resolved. Finally, the last condition checks if the **Double Jump Count** is greater than or equal to **100**. This allows me to control when the player can **Double Jump** by increasing or decreasing the variable value, or even disabling the double jump, as mentioned earlier. As you can see, once all conditions are true, the sequence of actions is executed. The image makes it clear what happens, so I’ll only explain the last action, which resets the **Double Jump Count** variable to **0**. When I do this, I create a **Loop**, and every time the player double-jumps, the count in the first event sequence is reset. Lastly, I created two additional conditions that will trigger after the **Double Jump** animation finishes. These conditions will ensure a smoother animation. The double jump animation isn’t complete, as the last frame shows the character lying down. So, I added these conditions to ensure the character performs a full rotation. ___ ### **Finalization** ___ Well, I think that’s it. I didn’t go into too many details to avoid making it too boring, plus I’m not the best at explaining. I’m not sure if you, who read up to this point, managed to understand anything I explained, but in the next posts, I’ll focus more on the creation of the levels and mechanics without delving into the programming part.