Hello there everyone! I’ve made some nice progress on the game over the last month and a half so it’s time for an update. I’ll be going over the process I went through to design out the levels in the game, starting to actually build the levels in the game and then dealing with changing levels as the player progresses.
Drawing Out the Levels and Rooms
So as I mentioned before my process for designing out the levels all pretty much happened with pencil and paper – OLD SCHOOL STYLE. I know there are more advanced ways to design out a level on a computer, but for how my brain works I just found good old pencil and paper to be the fastest and easiest way to get things down.
My first step was just drawing a bunch of boxes that connected to each other by lines (I had mentioned this in the last blog). Each box signified a “room” in the level of the game, what the focus of each of the subsections of the rooms was (platforming, fighting, both) and what next rooms it connects to.
Once that was all in place it was time to start actually drawing things out for each room box I had mapped out. My artistic skills are terrible, but thankfully all I really needed was a rough guide for what the rooms were going to contain that I could follow when I actually started building things out in Godot.
So stick figures it was, lol. After about a month or so of drawing everything out (200 rooms total) I felt I was in a good place with my stick figure designs. The process also changed my mind on a few design decisions I was thinking of – but I don’t want to spoil anything too bad on that lol.
The Build Out
So now that the drawings of everything were all done it was time for the actual build out in Godot. The process so far hasn’t been too surprising, as I had already built out some stages for boss fights and puzzles previously. It mostly follows the same logic for each room: build the box of the room with the floor, walls and ceilings, then place the platforms and traps, then place the enemies.
Once all that is done it’s testing time. The longest part of the process I’m finding for building out the rooms is just playing through them over and over again to see how they feel. There’s a lot of adjustment that happens once you go through that – either by changing the way one platform sections flows or swapping out enemy types or adding enemies, etc.
At the moment I have 7 rooms built out (of 200) and the entire first “area” of the game is completed (for now). No doubt things will change as I run through and test it more.
Moving In-between Rooms – Harder than it Looks
Now that the initial rooms are built out I’ve decided I’m going to pause on building out more levels until I have these 7 initial rooms completely done – including background, cut scenes, functional saves, etc. The reason for this is that as I was coding out the way the player will be moved from one room to the next it became apparent that the way you code out something as seemingly simple as that (it wasn’t) can actually effect design decisions of the game on the back end. Particularly stuff related to how the game is structured in the engine. I’m sure I’m going to get more surprises on how things need to be built out the more features I add to the levels, so I figured now is a good time to stop and work all of that out before I progress more. I’d hate to spend time building out 200 levels just to find out I need to go back into each one individually and restructure everything – ugh.
Speaking of ugh, I discovered that coding out moving in between rooms (or scenes as we call them in Godot) is way more complicated that you’d think it was. As the game is designed out I want to carry over the player from one scene to the next – instead of having a player character in each level already loaded and then dumping the previous player character. The reason for this is that there is a bunch of information on the player character at all times that would be too cumbersome to transfer over to a new player character each time they change a room (i.e. health level, current camera zoom setting, selected special abilities).
So my choice was to keep the player character static at all times, dump the current level, upload the new level and then place the player character in the new level. This isn’t the “standard” way of doing things as I’ve read, but I think it’ll work best for me.
Figuring out the code for doing something like that was nuts – including getting a loading screen to show while the whole process is taking place in the background. After spending an entire weekend and watching/reading about 15 tutorials thankfully I was able to figure it out – and as of Saturday it seems to be working as ended.
Sticking with Godot 3
Part of the problem of finding the correct tutorials to guide me on this is that I’m still using Godot 3 (currently 3.5.2, but will switch to 3.6 when it comes out). The newest release for Godot is 4. I downloaded Godot 4.1 and tried porting over the game – but it was a no go. Unfortunately I’m so deep into development into the game at this point (it’s been 3.5 years as this point I’ve been working on it) that the way the game is built and coded out is now very specific to Godot 3. There’s enough different with the functions and way you code in Godot 4 that in order to transfer the game order I basically would have to rewrite huge amounts of the scripts for the bazillion scenes that currently exist for the game. Not gonna happen unfortunately. So I’m sticking with Godot 3 for this project.
I am a bit nervous about total support for Godot 3 being dropped in the future (as this project still has yeaaars to completion) and how that’s going to effect my ability to port the game to consoles – but as it is there’s not much to be done about it. Will need to cross that bridge when I come to it.
Well that’s it for now! As always check out my social media pages in the footer if you want to see some live video of the game in action!
Thanks!
-Charles