When attempting to fire multiple projectiles simultaneously using “Fire Projectile,” the action becomes momentarily sluggish when firing around four at once. Ideally, I’d like to fire about eight simultaneously. Is there a way to do this with minimal performance impact?
Currently, I’ve only set an image on the “Projectile” template and haven’t implemented any special behaviors.
This is a common issue in game development.
When generation processes are performed simultaneously, the load inevitably increases, causing a brief slowdown.
A common solution is to keep a stock of bullets constantly stored off-screen where they are not visible, and teleport them to hand at the moment of firing, but that can be a bit cumbersome.
Regarding this, I have submitted a feature request, and it should be implemented someday… hopefully.
For now, possible actions include:
Try changing the rendering method from Forward+ to the lighter (allegedly) Compatible mode.
Test play tends to be heavy, so try exporting once and check the app’s performance to see if it feels heavy.
Try reducing the size of the bullet textures.
Instead of generating bullets simultaneously, stagger their generation by 0.0017 seconds to reduce the number of outputs per frame.
Well, it’s obvious, but lining up a few enemies that shoot projectiles causes severe lag… Is there nothing we can do about this? At this rate, it’s becoming unusable…
From my local testing, lining up a few creatures and firing four shots each doesn’t cause significant performance drops… If possible, could you share the project with me?
Since redistributing the original material might violate terms, if a version with the image filled in is acceptable… The judgment is visualized, so you should be able to get a sense of the atmosphere.
I have checked this. Initially, it was functioning properly, but it gradually became sluggish. Upon investigation, I found that since “Delete Bullets” is not enabled, nodes are increasing infinitely, causing performance degradation.
If you enable “Destroy when off-screen” in the base settings for the Object Fairy Bullet,
there will be a slight stutter at the time of generation, but it will not become a critical performance issue.
I wonder… since the image has been filled in, maybe the processing load has decreased…
This is also a regular PC without even a dedicated GPU for work, so it’s not particularly high-spec…
You can monitor FPS, PhysicsProcess, etc. in the Monitor tab of the debugger menu at the bottom, so trying to add various things might help identify what’s causing the performance drop.
It seems to be lagging around there; upon inspection, when combined with enemy attacks, the Physics Process reaches 32, which appears to be the cause.
I tried a few things:
Turning off wall collision detection improved the situation somewhat, allowing me to maintain over 50 FPS, but object generation is still heavy.
Given this situation, there are two possible solutions:
Wait for the implementation of the lightweight bullet object (this is a high-difficulty implementation, so it will likely take some time…)
Try generating bullet objects using GDScript (I’m not yet detailed enough to provide advice on this, and it’s quite challenging… However, if I can write a script that handles collision detection and sends a damage signal upon impact, it might be feasible)
Hmm… this is the core of the game, so even a compromise might be a bit tough… If it’s lagging here, it’s likely to get even heavier once enemies are implemented.
While the issue at hand is “weight at generation,” implementing enemies means they also consume a bit of process memory, making it inevitable that the system becomes heavier…
We have confirmed this with the development team, but a fundamental solution seems difficult until lightweight bullet objects can be realized. Therefore, we sincerely apologize, but it appears that works of this style will have to be produced in the previous title or you will need to wait.
Even if the bullets are made lighter, the performance will still drop when four enemies appear at once… It’s quite a tough challenge for a development tool…
It shouldn’t crash with around 4 simultaneous spawns; it might just cause a brief hitch.
There is a possibility of performance drops if you attempt to spawn around 10 entities simultaneously.
Depending on the type of game you are making, since the heavy part is the spawning process, in a scrolling progression type, the objects would already be placed beforehand. For enemies, you could use enable/disable mechanisms, so it typically won’t be too heavy.
On the other hand, it is indeed difficult to spawn 10 enemies randomly at runtime. In such cases, you would likely need to pre-generate them elsewhere and then teleport them into place.
Apologies for jumping in.
Is Godot Engine itself capable of creating action games where not only projectiles but also dozens or even hundreds of enemy characters swarm and attack?
Honestly, it feels a bit disappointing that even on relatively modern PCs, creating 2D “swarm” games would be difficult, especially considering titles like Touhou Project run smoothly even on very low-spec hardware.
While flashy graphical effects are nice, what I, as a developer, truly hope for in a game engine is overwhelming performance and lightness. Next comes ease of use and clarity. Ideally, it would be a sequel that allows me to apply knowledge gained from studying Construct MV. Graphical aspects, honestly, come last for me—though this is purely my personal opinion.
Since I’ve been eagerly anticipating this sequel for months, I truly hope it becomes a god-tier tool!
Well, as Kome-san also commented, the foremost requirement for development tools is lightness. That directly impacts the scope of creation and the range of games that can be made.
“I don’t think generating four entities simultaneously would cause a drop; it might just cause a momentary hitch.”
“If it’s a scrolling action game, those would already be placed, right?”
Honestly, personally, I feel a certain naivety in these remarks. A “momentary hitch”… If such hitches occur frequently, it’s fair to say the game fails as an action title. If you fall into a pit and die because of a hitch, everything is lost.
Saying “if it’s a scrolling type…” doesn’t really answer the question. For example, if you have enemies of the same type that fire projectiles with wide-area laser attacks, and all enemies enter their defeat animation at the same time, then in the next wave, all enemies will fire projectiles simultaneously again. In that case, the game would suffer performance drops every time the enemies fire. Even excluding such relatively rare cases, I believe there are countless scenarios where you’d want multiple projectiles fired simultaneously, such as with turrets.
If it were “generating ten at once…”, I might understand the concern. But it’s only four. In Kirby, Waddle Dees can swing several projectiles with their beam attack; if that were more than four, it wouldn’t be implementable. I think this level of specification would frequently pose implementation challenges even in general games.
I understand that this is not what you meant, but I will provide an answer anyway.
I mentioned that the performance drop is only noticeable to a certain extent; specifically, the frame rate drops to 58–59 FPS when four projectiles are fired, which is generally imperceptible and thus not a major issue. That said, if it occurs every time, it may become noticeable, and it is certainly better if it does not happen at all.
The performance drop becomes clearly noticeable when around eight objects are generated simultaneously, but even then, the number is not excessive.
The reason this generation process is heavy is that the base object for the projectiles uses CharacterBody2D, which performs advanced physics calculations. We are aware of this issue and, as mentioned earlier, plan to address it.
However, releasing the game in such a state could be seen as lacking foresight, which is a valid point. It is also evident that you have put significant effort into developing the project, so your frustration is understandable.
We sincerely apologize for not meeting your expectations.
Regarding Waddle Dee, it is possible to implement this feature since there is no need to process everything as separate projectiles; the attack hitbox and sprite animation can be handled with a single projectile.
While Godot Engine itself can handle this, it would require using a different base node, such as Area2D, instead of CharacterBody2D, which is used by ACTION GAME MAKER.
Since nodes like Area2D do not include built-in logic for moving characters, you would need to implement all movement logic yourself. Additionally, to support a large number of instances, the processing must be minimized to ensure smooth performance.
Regarding performance, our immediate goal is to make projectiles light enough to support dense bullet patterns by implementing them as Area2D or Node2D objects. We cannot guarantee whether this approach will work for all objects (such as characters or enemies), but we will continue development to meet your expectations as much as possible.