If each enemy type has one animation and they are not too big, then you can probably use one sprite for all enemies.

If there are multiple animations per enemy (for example, idle, walk, attack), they may be difficult to manage when they are in one sprite. Then make different objects and combine them into a family.

Another thing to consider is memory usage. A single sprite with many heavy animations can use a lot of memory. So if your game has different enemy types on different levels, I would definitely suggest keeping them in separate sprites to save on memory.

Hi! Thank you for your answer, as always you're quick and respectful.

The enemies I'm making won't use many sprites, and they are somewhat small.

But I'm planning to create a different type of enemies. I'm not planning to add many enemies in one level, however.

Most of the enemies won't use heavy animations. The "Idle" can be just one single frame, and the "attack" the rest of the frames (which usually are max 5).

Hello! I have a short question that came to my mind and I wanted to know your opinion.

I am starting to make enemies for my game. I'm building different types of enemies, however, they all have some things in common, like physics.

I was considering making one single object called "enemy" with all the necessary behaviors which automatically go on or off depending on the enemy (set in the form of animation). However, I was thinking to make this choice purely to make things "faster" or easier for the game to process.

Do you think I should make one enemy for each object, and maybe group them as a family?

Thank you!

Make the sprite particles as an image with many image points. Whenever the vacuum close to the image, spawn "particles" with those image points and destroy proxy image.

A proof: dropbox.com/s/aae40il0m4w6hsa/dust_proxy.capx

Thank you so much for this solution alextro! I love the idea, and it's perfect for the game. I've partially implemented it with the rest of the game, and I could decrease the CPU usage from 26% to 17% without changing the design of the dust. Lovely!

I'll keep you updated, but in the meanwhile, thank you for this game design help!

There's nothing wrong with using the CPU. The CPU is there to be used. Are you running into slowdowns? 7000 objects still seems within the realm of reason, although the line of sight checks could be causing you issues, as those have collision checks. With so many objects moving, some fps fluctuations would probably be reasonable and hardly noticable.

The first thing that comes to mind is to add a condition filter out only the objects in range first to check line of sight on, then you're only checking on a few hundred at a time. Actually I'm not sure if collision/los checks can be optimized this way, so it would be nice if someone else could confirm.

Why are you trying to make this work on low end platforms? If you want to target low end platforms, you don't do something that would push any limits in the first place. If you want to make a game about being able to collect thousands of dust particles, your idea by nature is not targeting low end platforms. Also, how do you define low-end? The computer you're working on? The cheapest phone you can buy today? A tablet from 10 years ago?

Here's a quick example that runs fine on my machine at 10000 objects. I'm sure you don't need to cover the entire screen so you should be able to do with significantly less. Another simple option is to lower your target resolution, so you just don't need as many objects to fill the screen in the first place.

https://www.dropbox.com/s/4rrawizdr9404nb/vacuumexample.c3p?dl=0

Thank you for the kind suggestion. The idea is about using a vacuum cleaner that collects dust, so I am not sure I would change that concept. I am not focusing particularly on low-end platforms, but I want to use them to troubleshoot and see what can be improved for more platforms. For example, I have asked a friend of mine to lend me his low-end PC, and the room with the richest amount of objects can run at 60 fps with ~80% CPU, which is according to my previsions.

Comments like yours help me remember to keep my resolution as low as possible, despite my ambitions in some matters. My idea was to make bigger rooms with details, but I think there are other ways to do it. Maybe small rooms are interconnected or rooms with fewer details, as you mentioned.

pcgamer.com/what-is-microstutter-and-how-do-i-fix-it

Basically, on a 60 fps sync, even though your system is capable of 60+ fps, if for whatever reason it fails to render any given frame on time for 60 fps (this can be a memory issue sometimes, or simply high load, background processes or overhead, there are many possible reasons that can cause this), it will skip that frame resulting in an effective 30 fps (half) for that instant, which is very noticable as stutter. Over the course of a second, it might only skip one or two, resulting in the 59, 58 fps you sometimes see. This is an oversimplified explanation, and there is a lot more you can read about if you want.

For one thing, frame buffering is a type of vsync that should minimize these issues, but I'm not familiar if that's implemented on the software side or hardware side as far as Construct is concerned, so check your graphics card settings.

https://www.nvidia.com/en-us/geforce/technologies/adaptive-vsync/technology/

Also see if you can enable adaptive vsync on the hardware side, that could be another possible simple fix.

Yes, I have adaptive vsync turned on!

I wonder, however, how this can affect other people who play my game.

For example. Maybe I find a way to fix this issue with the frame, but it may be just for my PC, because it's dependent on the screen Hz and other factors.

EDIT: I have come to a realization that this had to be done more than a year ago...... And it's probably a principle I didn't consider because I was of a different approach.

By comparing other Construct 3 short projects like Kiwi Story, segmented boss fight, Demonoire, etc, I noticed that all these projects use widely the tilemaps, in particular for aesthetic matters but also for other things as well.

My game doesn't use it. Yes, all the "objects" in the game that make the map are real objects.

This also explains why the objects seem not to move properly when the camera follows the player (just a fraction of a millisecond, but enough to notice it).

I imagine this also explains the high amount of CPU usage.

In my mind, I probably had the idea of making a map as I used to in some 3D map makers - place the object and move it however you wanted. But if this isn't the best case for the game, then I should better use only tilemaps, right?

I mean, technically speaking for Construct 3, an object with no collision, no effects, no anything still acts differently compared to a group of tiles, am I right?

If I turn the game by using mostly tilemaps, should I see better improvements?

Hello! So, this is a spiritual sequel to this topic. However, I want to focus on one particular part of the game I am working on, and I am all for ideas and suggestions to make it work well and possibly look good.

The basics: It's a game featuring a vacuum cleaner that collects dust.

The dust must be collected, so it's like dealing with multiple mini coins.

Mini coins mean mini objects in a single room, meaning it takes up a bit of space.

But that's fine: It's the core foundation of this game, after all.

But, also, I want that it doesn't break the game for a low-end platform.

In the beginning, the dust was exactly how you would think: small, and hideous, but unmistakable when put together with more pieces of dust, like the picture you can see here.

The problem was the count number: In bigger rooms, the number could go up to 7000!

That was a bit too much for the game. So I started making them bigger in a way to reduce the number of objects.

Up until now, this is how dust looks. It's pink due to a game design decision that is unrelated. As you can see, they have a big black outline (in the sprite, so no effects or add-ons), so now they are even thicker.

I can go down to 3000-1500, which is already a great improvement. But I have noticed that the CPU starts at 25%, and once collected all the dust it's at 12%!

I believe it's too much for mini objects. So I am trying to figure out what causes it, and how I can fix it, maybe by even changing the whole concept of dust.

For example, each piece of dust has Line of Sight and Move To behaviors.

This allows making the "sucking" effect that vacuum cleaners usually have.

I believe these can make a great impact, especially if they are overnumbered in just one room.

Could it be? For the sake of less CPU usage, do you think there is another approach to make the "sucking" effect?

I am afraid to continue changing how the dust works because I have noticed that they slowly turning more into coins and less into dust. I did try using canvases, like if the dust was "painted", but was, unfortunately, a bad experiment.

How would you make the dust that looks like dust but doesn't dust out the CPU?

Mini objects? Particles? Maybe a range where the dust you can't see is like "inactive"? Is it possible? I have heard it's a common technique in 3D worlds.

That is all. Thank you for reading, and I wish you a good day.

Vsync is a limit to only render as many frames as your hardware can display per second, because additional frames won't be shown anyway. In Construct, a frame, or tick, is basically a run through all your events before repeating. If you turn it off, then your device will try to do that as fast as it can, regardless of what can actually be displayed. So of course it will use up all the processing power it can.

Yes, it makes sense. I have seen the game running at over 500 fps with full ticks on.

However, I've noticed that with v-sync on, the 60 fps are not stable, at least not immediately. How come?

You mean the framerate was set to "unlimited"? Yeah, that option should only be used for stress-testing.

Check the refresh rate of your monitor - if it's high like 120-240Hz, as an experiment try reducing it to 60. See if this improves the CPU usage even further.

Now that you mentioned, there is a motivation I turned off the v-sync.

I was just about to check now, the game has less than 35% of CPU usage, 3% of GPU Usage and 60 fps - but they are not fixed. Sometimes it's 57 or 58, and you can see the stutter coming from the game. Maybe my hope is that, by lowering the cpu usage, I won't see this stutter again.

(The screen is already at 60Hz).

Hello. I'm about to make a quick topic since it's over 6AM here but I'm testing my game and I want to optimize it however I can.

A premise: yes, I have read all the articles which talk about optimization.

The game I am making is a top-down puzzle game featuring a vacuum cleaner.

The game is mainly supported by these groups of objects:

- The player, which is followed by a trail made of particles

- the dust, which is made out of semi-small pink coins (the pink is tinted directly in the sprite).

- the room, which contains a good number of aesthetic objects.

Now, I have read how to optimize most of the features. For example, I have reduced many events and removed all the unnecessary "every tick". I was able to make the dust bigger to reduce the amount of it in the room. Deleted many redundant terms and unnecessary values like "wait for 0.000x seconds".

Overall I was satisfied of the result. Until checked the CPU Usage: Over 95%, while the GPU was just 7%.

Now, the CPU is holding all the calculations. It makes sense that it can't be less than 20%.

But 95%? I thought it was too high.

So I made a test, one of those that help you to find out "whodunnit", or which part of the game is stressing the CPU.

So I've started by removing event sheets.

Alright, I have found 2-3 event sheets that take a lot of calculation.

From 95 to 80% of CPU usage.

The room now only has two event sheets, one is used to seeing the percentage without going into debug mode.

Let's start deleting some assets.

Ok, by removing particles I get from 80% to 77%. The gpu dropped from 7% to 5%.

Let's remove all the tiled backgrounds. Not much happened.

Let's remove collisions and other invisible objects. No much happened.

Let's remove the dust: from 77% to 70%. Ok, I definitely need to look at how the dust works in-game.

Now, let's remove all the necessary objects to make the room functional: from 70% to 68%.

Lastly, let's remove all the assets: From 68% to 65%.

Now, thanks to this test I now know where to fix most of the features. But one question pervaded me: Isn't 65% a bit too much?

For a top-down, pixel art game like mine, generally speaking, what is the possible amount of cpu required? I mean, we are talking about a 2D game, not a CryEngine cinematic game.

I checked what, according to the debug tests, makes the game so heavy with the cpu.

The engine and the "draw calls" seem to be the cause of this number.

Considering I am testing a project directly from the editor... does it mean the "draw calls" shouldn't be this heavy after exporting the game due to the compression?

In any case, How else can I do to make the CPU usage as small as possible?

Thank you for reading!