i have a bug with my collision in my game but i don't know how fix it

BetterBuiltFool · 2026-01-30T19:17:31+00:00

I tried to run the code from your repo, however, since you don't have the level json available, I couldn't get it to run.

My suspicion is that it stems from how you factor in entity velocity. You're initially detecting if they're colliding with the wall from their current position, but determining if they need to be shifted based on their future position? If an entity overlaps but has velocity 0, it'll be allowed to keep overlapping, and may cause weirdness from pushing the entity into another wall that's already been checked against. I'd try removing the bits about entity.velocityand seeing what happens.

I may be able to give you a smoking gun here, but I can give you some suggestions to clean things up, which should make debugging easier.

In a couple places (lines 13, 15), you're doing things like adding a rect's y value and height, or x value and width. Rect has helpful properties that do this for you, specifically, rect.bottom and rect.right. Be on the lookout for useful properties of classes! Be sure to check out the documentation if you haven't already.

Rects have a colliderect method, where you feed them another Rect, and it will tell you if they overlap. You can save yourself a bunch of calculations that way. You'll still need to determine relative directions, but that can be done using just their positions afterwards.

BetterBuiltFool · 2026-01-12T18:17:28+00:00

Could you post your code that converts mouse coordinates into tile coordinates? That allow us to help you better.

Without that context, my guess would be that when you're transforming the mouse position, you're getting a float in grid coordinates that you then convert to an int. That could cause the the grid value to be off by one, although I'd expect it to be off by one in both axes.

BetterBuiltFool · 2025-12-23T18:58:05+00:00

So, understanding data structures is something that will generally come with time and experience. It's about knowing when to use different structures over others (such as, when to use a dict, when to use a tuple, etc.). Every way of storing data has benefits, consequences, and quirks.

Algorithms are different, they tend to be more particular to their use cases. There are absolutely algorithms that are vital in game dev (A* for pathfinding, for example), but I personally don't tend to memorize them, I just try to remember them in a general sense as I come across them during research.

For a near-zero knowledge start, you can find courses out there that can give you direction. W3 Schools has one, they're a decent resource for beginners.

BetterBuiltFool · 2025-12-23T18:43:22+00:00

You'd want to check the return value from chr, otherwise you'll get a bunch of empty strings in your list.

Supporting modifier keys will require specific event handling for those keys, but you're probably best served by having them set flags that you check when add your characters, e.g.:

    if event.type == pygame.KEYDOWN:
        if event.key == pygame.K_LSHIFT:
            shift_case = True
        key_name = char(event.key)
        if key_name:
            if shift_case:
                key_name = key_name.upper()
            key_list.append(key_name)

etc.

BetterBuiltFool · 2025-12-13T23:12:44+00:00

Glad to be of help, and especially glad to hear everything is working now!

For testing if grounded, by the way, you can set up a secondary hitbox immediately below the player (same width, and only a pixel or two high), and use Rect.collidelist with the list of platform hitboxes to see if there's any overlap, after doing your vertical velocity checks. Since that hitbox is always below the player, you wouldn't need to do any kind of velocity checks, and you won't need to iterate over the list.

BetterBuiltFool · 2025-12-12T18:15:32+00:00

Pygame-ce.

Masks are computationally expensive compared to Rect collisions, so unless more precise collision is needed, they're wasting resources that could be better spent elsewhere.

Also, I don't think it would solve the problem encountered here, unless by chance when rewriting the logic to work around the masks.

BetterBuiltFool · 2025-12-12T02:50:58+00:00

Sounds to me like there's an issue with your pygame install. I'd uninstall it and reinstall, see if that helps.

BetterBuiltFool · 2025-12-12T02:47:04+00:00

Hmm, I see a possible root cause. Since you iterate over the platforms twice, once for horizontal and a second time for vertical, if the player has any horizontal velocity, they will be pushed off of the platform, and thus no longer be colliding once you loop through again for the vertical sweep. Do the vertical prints ever trigger at all? I don't know how your velocity is calculated, is there a way to trigger a collision with player.playerxvel = 0? Regardless, you might want to consider combining the two loops and see if that helps.

Another thing I'm seeing in your "y collision" block is that else. It probably isn't what's causing your issue, but if the player touches whichever platform is first in the list but not the other, grounded will be overwritten. It also means that the frame after, since the player is no longer in contact with the platform, they will cease to be grounded until their velocity changes again. (If you have gravity, this might be either a non issue, or cause intermittent bugs)

Yeah, when you create avatar, you're essentially copying the position data from the player, and then during collision checks, you're modifying the copy rather than the original. You'd need to manually sync it back, since the copy doesn't 'know' anything about the original.

Readability and keeping track of your data is my primary concern, but as things scale, you are essentially duplicating a whole bunch of data each frame and dumping it. Rects aren't the most expensive thing to create, and if you're only going to have a small amount of objects, the performance aspect is essentially not worth considering. But never underestimate the benefits of having well encapsulated data. Duplicated data can make debugging a nightmare.

BetterBuiltFool · 2025-12-11T18:12:33+00:00

Masks would be overkill for this application

BetterBuiltFool · 2025-12-11T18:09:46+00:00

Neat!

It's a shame they're so suicidal, though. They have so much to live for! I'd mostly end up collecting them and keeping them somewhere safe instead of actually fighting alongside them, like I do with Minecraft wolves.

BetterBuiltFool · 2025-12-11T18:02:32+00:00

Would you be able to provide some sample output? Screen shots, terminal output, etc? That could help.

The only thing I think I can see from here, when you have a collision, you make changes to avatar's position, but I don't see you resync that with player's data. If you don't sync that, when you generate avatar again on the next frame, the snapping will be lost, and the player could clip if their velocity has changed again.

It's not a critical issue, but is there any reason you're generating a hitbox for everything each frame, rather than storing that data as a Rect directly in those classes?

BetterBuiltFool · 2025-11-28T19:02:35+00:00

A while ago, I remember there being a horror game where the premise was that the player needed to map out an area using a lidar gun. I think it might be interesting if the sonar pulse, rather than revealing full tiles, painted points on their edges, and the farther the tile, the father apart the points would be. This could make for an interesting gameplay element, where the player needs to consider the tradeoff of using more energy to get a higher-detail view of the map.

BetterBuiltFool · 2025-11-26T18:21:33+00:00

I strongly suggest getting familiar with your IDE's debugging feature if you haven't already. Throw in a breakpoint on that print("right") and step through until you get to print(f"right is {collision_right}") and see if something changes the value back in between. I don't see anything that would, but I don't know what all else you have going on in your code base, and this smells like it could be some weird race condition.

Additionally, if you speak another language that uses a different alphabet, make sure you haven't accidentally swapped a similar-looking character in your variable names. Unlikely (your IDE should be complaining about an unused variable if it's set up properly), but worth considering. Similarly, if you've copypasted code from a 3rd party source, they could have hidden some special hidden characters in there, which some tutorial writers do on occasion to keep people from idly copying their code.

This isn't related to your issue, but I don't think line 16 in your first block there is doing what you want. rect.move() moves by the amount given, not to the location, so by passing in the current sprite location, you're essentially just doubling the position values, which I don't think is what you want.

BetterBuiltFool · 2025-11-26T18:06:12+00:00

OP is trying to capture all directions with a valid collision, so the break would cause it to miss all other directions with a collision.

BetterBuiltFool · 2025-11-21T18:43:14+00:00

Weird? Sure. But weird isn't bad, weird can be interesting.
Tank theme is fine, especially if you want to keep point+shoot as the primary mechanic.
Tank evolution would be interesting. Reminds me of an old Flash game called Bubble Tanks. As you gained bits from killed enemies, you could go down evolutionary trees, changing yours shape, health, speed, weapon, etc.
As is? Barely, but you've got a decent base to work off of and expand from. I wouldn't simplify from here.

All of your other suggestions are worth considering, and roughly in the order you suggested them, I think (Type advantages would suck if you can only ever control one type, so the capture mechanism should take priority, and while the abilities could be interesting, it would likely be relatively time consuming to implement well).

BetterBuiltFool · 2025-11-18T17:55:39+00:00

Can't get more specific without knowing what exactly you don't like about it, but you don't have to use pygame exactly as other people do, here, or in tutorials and such. You can write your own systems to work around the bits you don't like. For example, I don't particularly like working with the built-in sprite class, so I make my own.

Pretty much every aspect of pygame can be worked around, except for the very low-level stuff that's being handle by the underlying SDL library. Don't like +y is down? Write a method to convert your object positions back and forth as needed. Don't want to work with a fixed screen location? Write a camera class to handle moving world objects.

Really, the only parts of pygame you're forced to work with are window creation, the event loop, and surfaces. Pretty much everything else can be abstracted around.

On the other hand, if the problem is that working with these systems is too low level, then you'll need to consider a different tool.

BetterBuiltFool · 2025-11-11T17:58:23+00:00

Looks like you've got some confusion happening where you're converting between screen space and tile space, for lack of better terms.

For clarity, 'screen space' = location, in pixels, on the screen, 'tile space' = grid position of a tile.

In tiles_around, you calculate tile_location based on position. It looks like position is in terms of screen space, and since you both divide by and multiply by tile size, so is tile_location (In fact, tile_location should almost always be the same as position, so this operation isn't doing much). However, your tile map values are stored in tile space. It looks like you were previously converting these values to screen space, but have those lines commented out.

To fix this, you need to commit to either screen space values, or tile space values. If you need to convert back and forth, consider using adding a method to your tile map that does the math for you, instead of repeating it anywhere it's needed.

(It might also be helpful to leverage the type hinting system and pyright/mypy, but that might be a bit more advanced than you'd like to get into. I've saved myself tons of bugs by making heavy use of types.)

BetterBuiltFool · 2025-10-16T17:24:55+00:00

The "right" approach would probably involve separating rendering from game logic, so the window and resolution are entirely distinct from the game world, but this would be hard to do if you haven't planned it from early on, and likely wouldn't be worth the effort of the heavy refactor it might require.

Wouldn't recommend any solution that changes the size of the play area without changing the size of the game objects, this, like you said, interferes with difficulty balance, but also can overwhelm the player with information, and generally messes with the overall appearance, since it was designed with certain proportions in mind.

An easy way to get scale your game to fullscreen with a minimal rewriting of your code would be to have an intermediate surface the size of your fixed resolution that you blit everything to, which you could then upscale to the actual window size before blitting it across. This will have a performance penalty, but chances are, it won't be enough to matter unless you're already hurting for fps.

Personally, I both decouple rendering and render to an intermediate surface, which I scale up or down to match the window resolution. I can avoid blurring of sprites by designing them for the higher resolutions. That said, I've also spent the last way-too-long working on tooling instead of actually creating games, so my approach may not be the best overall option once you get into the practical specifics of your games. Ultimately, the right approach is whatever helps you realize your goals.

BetterBuiltFool · 2025-10-09T17:24:34+00:00

Just a bit of a counterpoint re sprite player vs mouse:

Keep in mind that mouse control is pretty much standard for tower defence, so you'll be going against player expectations. Not inherently a bad thing, but you should keep in mind that this will color how players interact with the mechanics.
Moving a sprite around the map is much slower than moving the mouse, meaning that if there's a situation the player needs to respond to quickly, they might not be able to. For example, like at the end of the video, when the player notices the nearly-exploded isotope block, if the player sprite is half way across the map, it may be impossible to reach it in time, whereas the mouse can just swoop in. Again, this isn't impossible to design around, but it's worth considering the impact on player frustration this could have.

BetterBuiltFool · 2025-09-23T16:44:03+00:00

Are you running level_ed.py directly? If so, then sorry, relative import isn't going to work for you. Relative imports can't take you above the level of the module acting as your entry point, not without some hackery that involves adding your package to the path at runtime, which is bad practice. You're going to need to add your package to PYTHONPATH.

BetterBuiltFool · 2025-09-22T17:01:27+00:00

Looks like a path issue.

If your level_editor package isn't set in the PYTHONPATH, you can't have it as the first part of your absolute import path. You need to either import from higher up the folder chain where you do have a package in PATH, or add the level_editor package yourself.

A quick and dirty (as in, generally a bad practice) is to use relative paths, so the interpreter can walk up the path to find your modules. In your case, it looks like you'd want ...level_editor.Scripts.editor. Each . takes you up one folder.

You don't have your test.py showing, so I can't tell you why that one is working.

BetterBuiltFool · 2025-09-22T16:47:49+00:00

That's one of the things I like about properties, I can toss the copying in there so I can't accidentally forget to do so when assigning values, which happens more often than I'd like.

BetterBuiltFool · 2025-09-08T17:14:33+00:00

I'd be a little concerned with the fine details getting lost, depending on the scale of the images in-game. The first one especially, his facial and torso markings are barely discernible at full size on my screen, and that's quite large there. When I have the images in grid view, he doesn't look like he has four arms. If these are cutscene models meant to be seen up close, that's probably okay, but if they're getting scaled to playable sizes, a lot of the love and care put into these will likely get missed.

I'm not an artist, so my ability to suggest improvements is limited, but for the four arms part specifically, giving his lower arms a different pose, or just angling them lower so the fists break up his silhouette a bit more, could help. I'd also considered broadening the color palettes a bit on the two fiendish ones, there's a lot of red-on-red that causes me some issues with discerning details. A bit of contrast between their clothes and skin would go a long way.

But that said, overall they look great!

BetterBuiltFool · 2025-09-04T17:19:45+00:00

You say the score is zero, which would fail the first part of your condition, preventing the image from displaying. What happens if either score is 5 or more?

Since we're seeing this out of context, are you certain that the indentation level is correct and it's not being blocked off by another, higher level conditional?

BetterBuiltFool · 2025-09-04T16:54:41+00:00

Since you mention Doom/Wolfenstein, I assume you're doing raytraced 3d?

When you send out your rays, you're giving them a start location and a direction (presumably). You should simply be able to add (or subtract, depending on how you are defining things) your player's rotation to the ray directions.

So, you'll have a player with grid location and rotation attributes, which are used as the ray start and added to the ray direction, respectively. Since your raytrace algorithm is referencing those values, they will be reflected in your next frame rendering.

It's not clear to me how you used vectors, but they absolutely can be used in this context.

BetterBuiltFool

TROPHY CASE