A weird, specific bug in my game

Post reply
0 favourites
  • 10 posts
From the Asset Store
UI Click Sounds
$4 USD
20 high quality click sounds, ready to improve your game's UI instantly
Levi Vilas Boas's avatar
Levi Vilas Boas

  • I've been making a space themed, semi-roguelike as a passion project for about 1 year (6 months actual work). Before I explain the bug, i need to explain some strange choices I made in the game for some reason:

    - Ships are split into:

    - The ship

    - The turrets

    - The barrels on the turrets

    - The bullets shot from the barrels

    - These are part of a family called "FullShip"

    - I used block code in this game instead of JS

    - There is a separate ID system from the UID, where every ship has a unique ID. All of the sprites in FullShip use this ID system. This is used for enemy > player AI, checking if a missile is out of its parent ship's range, etc.

    - I only used around 3 basic behaviours in this game, which was somewhat stupid, but that shouldn't be too much of an issue in particular

    Anyway, the main bug is that when a ship is destroyed, after a split second there is a small chance that every single bullet on the map gets destroyed. Due to how some parts of the game works, not only is this frustrating to look at, but can ruin certain moments. The REALLY weird bit is that when I disabled all the code that destroys a bullet (including code with families), the bug still happens. I created a separate build in which I found that the bullets were certainly being destroyed.

    So, what's the deal here, Have I not given enough info or is this bug just too vague?

    Tagged:

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • This is that complex, probably unnecessary system

    All of the ships in the game will post their important information to this array which is just a glorified global variable. This is used in several cases where "picking" gets confusing, like having two enemy ships communicate with each other.

    AITargetID is for enemy AI to find where to focus their AI onto.

    TargetID is for turrets to find which target to fire at

  • Oh, and that "IsDead" variable is used for ships which are "dead" and need to update certain variables before dying

  • Unfortunately this is in the realm of impossible to debug from screenshots.

    If all the bullets are getting destroyed then you’ll want to look at all the places you destroy them. Or maybe you have a behavior that destroys them like fade.

    Logic wise I’d say the hot spots to look at are your events around the waits and the else events. Maybe the logic is doing something unexpected.

    If I end up with events that don’t work as expected I try to isolate it, and maybe incrementally re-build it a bit at a time while doing tests as you go.

    Events have a fair amount of hard to follow edge cases so I’m often either just using stuff I fully understand or doing extra tests while I implement stuff.

    Anyways, good luck

  • You have lots of events that run on every tick. Not only this is bad for the performance, but also makes the code very fragmented and difficult to follow.

    You should use triggered events, functions and custom actions more.

    For example, there's no point to compare the health of every ship on every tick. You should do it in the same event where the ship receives damage. And if health<=0, spawn the explosion, destroy the associated bullet in the same event. You could also get rid of isDead variable. 

    Ship custom action Damage
... Ship subtract damageAmount from health
... If health<=0 : Spawn explosion, spawn Gear, destroy Ship, pick and destroy bullet etc.

  • Thanks for the advice. For know, I'll follow some of the optimisation I didn't think of. In particular, reworking IsDead and making a custom action where the ship only checks health when it takes damage. Then, I'll update the results.

    Also, I haven't found any performance issues, but optimisation never hurts

  • Finally. I've rooted down the issue. It's a "for each" found when firing the bullet. I haven't pinpointed exactly why that in particular is an issue, however, its not as simple as that. Certain multi-barrelled turrets need delay on their fire to be effective, but when I remove the fore each, the delay doesn't work. This is because of the "delaytime" variable being a system wait. Now i understand why the bullet's being cleared was slightly delayed. This post isn't necessary, but I just want to express my joy after identifying an "unsolvable" issue to me.

  • The way you are using timers is a bit unusual. The main purpose of the Timer behavior is to replace the "wait" action. Starting a timer and then using a "wait" action right after defeats its purpose. Instead, you should use the "On Timer" trigger.

    As I mentioned in my previous comment, avoid running too many events on every tick, especially loops. Use triggers, functions, sub-events. This will make your code more predictable and easier to understand.

  • I think I must have posted in a confusing way, because I'm currently trying to replace the wait with timers to avoid confusing bugs like that one

Post reply
  • 10 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)