Preface

This week flew by a bit faster than I realized, so I didn’t get to work on ChompChomp too much. (I may have also gotten a bit sucked into one of my favorite games again). But I think next week should be far more interesting. Not only that but I got stun locked on an annoying issue for the first bit of the week and then decided to throw myself into a new area of the game that I know nothing about.

So the second half of this article is like my stream of consciousness as I think about and work out stuff in my head. It’s a bit rambl-y but hopefully a bit interesting as well since I think it’s fun to think about & share my thought process on!

Anyway let’s dive into this weeks update.

HitBox Saga

Alright so this is what stunlocked me for the first half of the week. Flipping a Hitbox.

The Problem

Alright so while I was doing some scripting & cleaning things up a bit I realized in the script attached to Bruce there was a function called _physics_process and one called _process, which I thought I should look into in case I should be using them both, as currently I was using pretty much only _physics_process. A quick bit of googling later I realized that I should in fact be using _process for most of what I’m doing. The difference between the two is that _physics_process is called every physics frame, and _process is called every frame. That means that unless I’m doing stuff relating to physics (like changing speed & whatnot) it should live in _process.

I moved some stuff there and left some stuff relating to changing Bruce’s speed in _physics_process but I realized that moving the code to _process made bruce super fast since it wasn’t framerate independent anymore. I also turned on a setting that shows hitboxes when running the scene.

The speed issue wasn’t hard to fix, I just needed to also incorporate the time since the last frame when doing math to make sure the speed isn’t depending on the framerate, and that just looks like this:

velo = ((dir * speed)*delta) / 2

That fixed it! And it did the classic “fixing one thing shows another issue.” The hitbox was not flipping with Bruce. So way back towards the start Bruce looked very funny when rotating, to remedy that I flipped him vertically when he passes as certain point. That makes his rotation look a lot more natural, but I never had hitboxes on so I didn’t realize the hitbox was not flipping with him.

This happens because Bruce, as a sprite is actually not perfectly centered. And he shouldn’t have to be really, otherwise all art would need to have like an even length on both sides and whatnot which is a silly rule. But that means when he gets flipped, an uneven portion of his body is now on the other side of the center. And the hitbox is not a child of the sprite, it’s a child of the “player node” (it has to be) so it doesn’t flip with him.

Tinkering Time

It was time to get googling and try stuff. So the line that was flipping Bruce was this:

animated_sprite.flip_v = true

And I thought “Oh I can just do that for the hitbox,” and nope. That method doesn’t exist for collision shapes as it might somehow impact physics (from my understanding). So time research solutions and try a bunch of them!

Move the hitbox up/down whenever Bruce flips so it stays correctly aligned? ❌

There’s two reasons why this didn’t work, the first is that Bruce rotates, so it’s not as simple as adding & subtracting from the Y value of the hitbox, and it would have to go in more than one direction since Bruce isn’t facing only up or down. The second reason is that Bruce is going to change size, so the distance the hitbox moves would need to be re-calculated all the time, which isn’t necessarily hard but doesn’t sound like a solid solution.

Invert scaling on the hitbox? ❌

A lot of things have a scale property, and when you invert the scale of something it actually sort of ‘flips.’ For example if something was 10 units tall, inverting the scale would make it -10 units which essentially flips it (from my understanding). Now this works on the bite hitbox, since the parent of the bite hitbox is an Area2D which scales. But the body is under the “player” node and it has to be as the CharacterBody2D node needs a shape. For whatever reason, scaling the body directly (which is a CollisionShape2D) didn’t work, it seems to scale from the center so it just gets bigger or smaller. I also tried scaling the parent player node but this had some weird unintended side effects and would squish Bruce in weird ways.

I might re-visit this method later as in my head it sounds like the ‘right’ way of solving it, but for now I gave up on scaling it to flip it.

Have a second hitbox and toggling when flipped? ✅

One solution I saw online was to have a second hitbox for when a sprite is flipped and to simply toggle it on & off when it’s flipped or not, and initially I thought this wouldn’t be a good idea since it means more resources being used, but I guess if it’s toggled off it’s not using much (hopefully). So I tried this and it actually worked pretty smoothly from the get go.

The gray hitbox is inactive, but when Bruce flips it becomes active & the other one becomes inactive!

You’ll never guess what happened next…

This revealed yet another issue. :)

Now it looked like Bruce was stuttering when he moved.

I quickly realized this definitely had something to do with the _process vs _physics_process bit though and after moving things around it was fixed, except now there was yet another issue, it looked like Bruce was stuck in some sort invisible box when moving.

move code -> realize hitbox not flipping -> try things -> fix issue -> visible stuttering now -> fix stuttering -> stuck on invisible walls now

I checked and there was nothing else in the scene, no walls that I had hidden or anything, and I didn’t remember changing anything that could have caused this…

And then it hit me

So in space, objects in motion will move at a constant rate forever until they hit something never speeding up or slowing down. The only way we can tell something is moving in space is the background of stars, we see the background move and know that said object is moving. What did this scene lack? Any sort of reference point! Bruce’s speed was constant & there’s no object to look at to see that he’s actually moving. I quickly printed Bruce’s position aaaaand:

False alarm! There’s no magical invisible walls, Bruce is just moving at a constant speed & so is the camera which gave the appearance of him being stuck when he reached his max speed & maintained it.

Ok! Onto some more interesting stuff!

Map Making

So it was Wednesday, and I was about to sit down and do some more work on ChompChomp, but I realized after fixing the hitboxes I didn’t have too much of a direction of what I’d do next. I did have my goals of making a school of fish, but it for some reason didn’t appeal to my brain. So I thought about what else I could work on, and it hit me. I mentioned it before too, but didn’t actually do it, that being the map / background.

So initially I thought I might do procedural generation, and while that idea is enticing for sure I think at least to start with I’m going to not do that. I can see myself going down that path and spending months on that alone haha and while that does sound fun I think it’s not the area I want to focus on for this game. There’s so many different areas of game development and map making is a huge one of them, but for this game and I think most of my games my focus will be on gameplay and mechanics. To me, a game that might not look great but feels amazing to play is far more appealing than one that looks good but feels awful to play (cough cough most modern “triple A” games). That’s not to say I plan to sacrifice the looks of ChompChomp or anything, just that I don’t wanna dive into visuals forever.

Inspiration & Direction

So to get started on that I looked at some inspiration. I checked out google images, subnautica, Dave the Diver, and a big source of inspiration for this game aside from agar.io - swallow the sea. I hadn’t taken a look at that game in a while and realized there was a lot I liked about it! STS (swallow the sea) is quite short, and subnautica is 3D and a whole different type of game but there were things to take inspiration from in both. I think subnautica’s atmosphere & ‘feeling’ while playing are nearly unmatched (I keep having to stop myself from writing too much about these games maybe I’ll do a subnautica review later!) and I like the art style of swallow the sea.

Taking a look at other games made me realize that ChompChomp can be whatever I want it to be. I think it’s fair to see a lot of people fear the ocean, or have this bizarre fascination with what lies in a territory completely contrasting to the land we live on as humans — myself included. Fun fact: before getting into programming I was dead set on becoming a marine biologist! I really love the ocean and all of the unknown it holds. It wasn’t for no reason that I decided to make a game about being an ocean creature! Anyway, while ChompChomp is going to be a fun sort of ‘play with homies’ game, I think I’m definitely going to try to lean into that primal fear instilled by the ocean depths.

The Setting

That being said I think I’ve decided on some aspects of the map! The ocean is vast, and there’s so many different underwater areas that on their own could be mistaken for another planet. So there’s a lot to choose from. The first thing that I think I’ve decided on is the scale of the environment.

There’s a smallish game series that goes by ‘Hungry Shark’ which is just about a Shark eating things as well, but there’s some missions to it & it’s entirely pve. One thing they did that I think is quite interesting is that their map goes all the way from the surface of the Ocean to the bottom. You can even jump above sea level and eat humans on land haha.

While I think that’s quite cool & kinda funny, I think I’m going to keep things entirely under water the ocean is cooler and sharks aren’t really man-eaters. Instead I think I’ll do something more like a coral reef as the upper bounds of the playable area that descends into the darkness of the deep sea. Additionally I like the idea of the ocean being like another world so for flora & fauna expect to see some ‘otherworldy’ things.

The Map Making

So there’s a built-in tile editor in Godot which I used to make the tiny bit of edges I currently have, and I think I’ll be continuing to use that for actually adding in the map. The question in my head at the time of writing is how I’ll actually make the map. I think I’ll need to make a tileset, probably for each biome. It’s going to be a lot of work but I can’t expect to get the results I want without putting in the effort and I really like pixel art as well.

Wait what’s a tileset?

Well I’m glad you asked! Games in general almost always have elements of the environment that repeat, 2D games in particular. A tileset is as it’s name, a set of ‘tiles’ that can be used to construct an environment. Since everything in 2D game is on a grid at the end of the day, it’s a lot easier to build things if you have a set of tiles that fit together to make something larger. It’s also much better for performance to have a set of tiles that can be reused rather than having a bunch of unique sprites. Imagine I was making platforms of different sizes, maybe I can do it with 3 tiles, one for each edge (left and right) and one for the center, which can repeat and be of any length. If I were to make a unique sprite for each platform I’d have to make a new sprite for each size of platform, which would be a lot of work and also take up a lot of space.

Here’s an example of a tileset I found for free on itch:

That might not look like much on it’s own, but it’s meant to be put together like a puzzle, and when you do you can make some really cool stuff with it like this:

So I think I’ll need some sort of tileset of my own + some non-tileset assets. Anyway this is going to be tough but also fun to do! I won’t show the full map to leave some things to find out for yourself when the game is playable but I’ll fully document at least the first biome and probably some other bits.

Anyway it’s time I wrap this article up, I’ve rambled too much and stalled it too long haha.

Wrapping Up

This article was heavily delayed, which sucks but things right now are quite busy and I still seem to suffering from a bit of brain fog from whatever I got sick with. I’ll continue writing these and do my best to make sure it’s weekly! I know this article was a lot more “thinking” and maybe a bit less exciting, but I hope it was still interesting! I think I cut this post a bit short but it’s fine as we’re not done with maps and I don’t even fully know what I’m talking about yet

Goals

I’m keeping my previous goals of course but my new top goal will be to work on a bit of the map. Not the whole thing, but that whole issue with invisible walls and whatnot made me realize I’d quite like to have things look & feel a bit more like a game and I think a nice environment will really help achieve that. It might be a bit early but ay it is what it is haha.

• Work on first biome! Bruce and the fishies need an environment to fit into!
• Size increase
  • Didn’t get around to actually increasing Bruce’s size when you eat something but that’s important so it’s next!
• Fish movement
  • Should swim!
• Fish clumping
  • Should swim in schools!
• More fish types
  • Different fish should have different stats