Wehbe’s Endless Platformer Devlog May, 2022

Share 🡵

These are development notes for May, 2022.

Performance

This month I revisited some aspects of the game to try and find ways to squeeze out some performance, because the current performance made it too laggy on some devices.

I found some chocking issues! A lot of the geometry was using standard settings and was thus unoptimized for the longest time! For example, the golem enemy characters in the game were each generating around 60 000 vertices, which is crazy.

How can a basic design, that almost looks like just a couple of blocks thrown together, generate this much geometry?

When I created the enemy back in 2021, I wasn’t really concerned about making anything “perfect”. The idea was to just get something done quickly, as a placeholder, to focus instead on designing the overall gameplay first. Then in the future I would dive in and create all the characters, level art, etc more properly.

So I just threw stuff together without thinking much about it. I used built–in geometrical shapes that come with the Godot Game Engine. Now, these shapes have a standard setting. For example, a capsule shape has a standard setting of 64 Radial Segments and 8 Rings. This gives me way too many polygon details for a basic character. Even if the character had this high definition details, they wouldn’t be visible because of how far away the camera is.

Now, the golem character is made up from six of these capsules.
One for the body.
One for the head.
One for the left eye.
One for the left eye pupil.
One for the right eye.
One for the right eye pupil.

After reducing the Radial Segments and Rings for each object/capsule, I managed to reduce the vertices from 60 000 down to 2000. All without affecting the look/design of the golem.

However, I am pretty sure I can reduce it even further to around 600 vertices once I design it properly in the future.

Making these changes made me think, “heey, wait a minute, what about the player character?”.

Lo and behold, I discovered the same issue. But even worse.

The player character had, not six capsule shapes, nope, it had eight shapes. And even–EVEN worse, I discovered I had increased the total Radial Segments and Rings for whatever reason I can’t remember. But it seems like I was being lazy while designing the hair and found that increasing the values would give me the results I was looking for!

Instead of spending an extra minutes or two to solve the design problem properly! Shameful laziness!

My excuse back then was, again: “hey, I will fix everything later once it is time to design stuff in Blender”. But I don’t think that’s a good excuse that justifies 130 000 vertices on a simple blocky character—yikes!

After applying the same fix as I did for the golem enemy, I managed to bring down the total vertices from 130 000 down to 9000 vertices. I could have brought it down to around 3000, but then the shapes would be way too blocky. And because it is the main character it does make sense to have it higher in quality than everything else.

Now when I hit the play button and start playing on the first level, I am getting a total of 30 000 vertices. I was getting 240 000 before these changes!

Up next was the level itself… not much could be done here because everything is made up from basic blocks. But I played around with the batch size and managed to squeeze away 6000 vertices. So now the first level generates 24 000 vertices.

This is literally ten times less than what I was getting originally. So instead of 240 000 vertices, I am now getting 24 000 vertices, just by doing some minor changes.

Hopefully these changes will make the game more playable on mobile devices.

Quality of life changes

Some issues were discovered that made the game an annoyance at times. I’ve been putting these issues on hold in favor of gameplay content and working on my other projects. But the issues were getting on my nerve lately as I have been playing my game and showing it off to family and friends. So I decided to dedicate an entire weekend just to work out these issues.

Gamepad and keyboard not working

Players have been complaining about not being able to navigate the options menu when using their gamepad or keyboard. The workaround was to use the mouse to apply all the settings before using the gamepad or keyboard to play. This was of course an oversight on my part when I developed the options menu, I was play–testing using the mouse and expected it to work just fine for keyboards and gamepads.

I was completely and utterly wrong!

Implementing the functionality to navigate the options screen using gamepads and keyboards was definitely not an easy task! A lot of code and logic had to be written just to make it work, which took a lot of time to figure out as well.

I basically refused to give up, I want my game to feel like it was made to be played using gamepads, so naturally there had to be ZERO resistance/blocks/annoyances when players played the game using their gamepads.

But it was also worth the trouble because I learned some new solutions that I can migrate over to my other projects!

Anyways, some of the design issues were: how would people prefer to navigate a slider and then return to the button menu or move down to the next setting?

For example, when you push the right key on the settings button, the focus goes towards the audio volume slider, now if you push the left key in hopes of returning back to the settings button, you’ll instead lower the volume!

In this special case I mapped it so that when the slider is focused you’ll have to push the UP key to return back to the settings button. However, this is not the case for the other buttons in the settings menu.

If the Toggle Fullscreen button or Toggle Touch-controller button is focused/selected, and the user push the left key, then they are taken back to the settings button.

This might be confusing for some, but I hope it’s such a small issue that people will see past it. And hopefully people will see the logic behind it.

However, I’m hoping people will naturally just go down the list of settings, and go back when the focus is on a button and not on a slider.

No feedback when changing settings

Is fullscreen on, or is it off? Is the touch-screen controller on or off?

There was no way to find the answer to these questions, the player had to either check the edge of their screen to see if there was any visible border, which meant fullscreen was off.

As for checking whether touch-screen controls was on or off, you had to start a new game!

Yikes.

Now, although these are minor issues, it still caused an annoyance, and, for some, it even lowered the quality of the game!

I didn’t quite know how to resolve this because I’ve not figured out the art direction of the game yet. So, dedicating a lot of time to the design of the menu interface seemed like a waste of time since I would end up re-designing everything in the future anyways, once I have decided on the art direction.

The solution was a simple one, well at least it communicates the necessary information the player needs, and that’s the most important thing right now. Below you’ll see the primitive, yet effective solution:

RED = OFF
GREEN = ON

Simple, eh?

It’s not the prettiest looking design, but I think it works for the time being.

Anyways, that’s all I could work on for now. Hopefully I will find some time next month to continue fixing issues before I develop new things for the game.

I’m also working on a new patch-version-system-thingy to make it easier to keep track of what version the game is. I thought I was being clever by calling each version by the time of the date the game was updated. But it’s beginning to become difficult to keep track of it all using this method. Instead I will have to study up on industry practices and revise all my games.

An update with all these changes will be announced once I have patched the game. Hopefully by the end of May or June.

Any thoughts about this update? Comment down below!

Leave a Reply