Making big games on C2

Discussion and feedback on Construct 2

Post » Sun Feb 22, 2015 9:56 pm

glerikud wrote:
jobel wrote:>Enemy On collision with Rock
AND Enemy is OnScreen --- DO THIS


As far as I know, the engine works in a way that it checks collisions for every object every tick.
The "Enemy On collision with Rock AND Enemy is OnScreen" event will only trigger when an enemy is collided with a rock and it happened on screen. The engine still checks for collisions for every object (not sure for the objects off-screen), but you can turn off this by setting the "Collisions" setting to "Disabled" in the object's properties.


Yes exactly, shutting off collisions when not on the screen will definitely improve performance. There's a good tutorial on that. I just was trying to explain it in simple terms don't process objects that are not on the screen. Better to get the UID of the specific object you want or only deal with the ones the player can see. The question was "what is dealing with per-instance objects?".
B
97
S
32
G
16
Posts: 1,200
Reputation: 16,682

Post » Sun Feb 22, 2015 11:19 pm

Making large games: those lengthy, or full of features or both, is absolutely doable as long as you understand how C2 works, what does work best and what the limitations are. Plus you need a lot time and grit. I've made some insanely complicated state machines in the past, that worked 100% and along side each other. And hope to finish those currently alpha programs, but with time I've learned that keeping it simple is healthier for your project and your sanity. :D

In terms of optimization, if your game is very dynamic, ( and I wander what you guys think about my way ), I'd personally would rather go with:

Every X seconds
For each object:
-distance() <= xxx
-- Set collisions ON
-- Turn movement behaviors On
-- set FX On
Etc
-Else
-distance() >= xxx
--Trigger once
-- Turn movement behaviors Off
-- Set collisions Off
-- set FX Off

The reason I went with Distance instead of Is on screen, is because I'd rather have the moving objects doing their thing before I see them to avoid awkward moments where you can see static object for a moment "turning itself" On.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
89
S
30
G
22
Posts: 1,985
Reputation: 20,099

Post » Mon Feb 23, 2015 1:35 am

megatronx wrote:The reason I went with Distance instead of Is on screen, is because I'd rather have the moving objects doing their thing before I see them to avoid awkward moments where you can see static object for a moment "turning itself" On.


sure for movement stuff that makes sense... but other AI behavior that is less visible OnScreen works.

I mean, it all depends on the game and what your objects are doing when not in the players viewport.
B
97
S
32
G
16
Posts: 1,200
Reputation: 16,682

Post » Mon Feb 23, 2015 1:30 pm

megatronx wrote:Every X seconds
For each object:
-distance() <= xxx
-- Set collisions ON
-- Turn movement behaviors On
-- set FX On
Etc
-Else
-distance() >= xxx
--Trigger once
-- Turn movement behaviors Off
-- Set collisions Off
-- set FX Off


Hey thanks! This is very nice. I might even add some physics settings in there too, changing the stepping/performance to lower depending on the object's speed and disable them when the object has stopped. I've been planning on having some physics objects on the background that would shake and fall if you ran past them, jumped, etc.
B
21
S
7
G
4
Posts: 233
Reputation: 3,474

Post » Mon Feb 23, 2015 5:52 pm

megatronx wrote:Every X seconds
For each object:
-distance() <= xxx
-- Set collisions ON
-- Turn movement behaviors On
-- set FX On
Etc
-Else
-distance() >= xxx
--Trigger once
-- Turn movement behaviors Off
-- Set collisions Off
-- set FX Off


Is there much of an optimization difference between turning movement, collisions, etc off rather than just setting the object's timescale to 0?
I'm currently using using timescale myself, and figured if the object was essentially paused it wouldn't take up any cpu overhead, but am unsure if that is the case.
Be sure to check out my Metroidvania game, A Hole in the Earth
B
59
S
24
G
3
Posts: 359
Reputation: 5,683

Post » Mon Feb 23, 2015 6:43 pm

Um, collisions would still be checked every tick, so thats a nope.
Also "for each" with distance() is contrary to most optimizations, even done sparingly, as its a loop, and the filtering method of "is on screen" should do all of that.
If you need to check a bigger area than the viewport check the objects xy's, like objectx< scrollx- n, and objectx> scrollx x+n, and objecty < scrolly-n, and objecty> scrolly+n.
Perhaps a better method would be in a behavior similar to the Line of Sight. @Ashley ?
In fact that behavior may serve better in some situations.
Image ImageImage
B
169
S
50
G
170
Posts: 8,291
Reputation: 108,726

Post » Tue Feb 24, 2015 11:11 am

Construct 2 already has a very efficient collision engine using collision cells. Read the link for more info.

Putting conditions after a collision test does not change the number of collisions tested, and putting conditions before a collision test can disable the collision cells optimisation and actually result in more work. So I'd just trust the collision cells system to do its job and make collisions fast, you can't really beat that by events (other than not testing collisions at all). Also if you don't test any collisions, then disabling collisions has exactly zero performance impact.

Also note "For each object" obviously does per-instance work, so will not scale well with very large numbers of objects, even if it's ostensibly to make things faster by turning off features.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

Post » Tue Feb 24, 2015 11:23 am

@Ashley

so what approach would be the best for i.e. big platformer level,
with i.e. 100 enemies, each with "Platformer behavior"?
B
18
S
7
G
1
Posts: 783
Reputation: 4,247

Post » Tue Feb 24, 2015 11:42 am

Ashley wrote:Also note "For each object" obviously does per-instance work, so will not scale well with very large numbers of objects, even if it's ostensibly to make things faster by turning off features.

do you have any advice how to work around "For each object" ? i have the feeling that in many cases you cant circumvent "For each object" events. For example in a turn based game im working on i have to pick the NPCs whos next, for that i needed an "for each object"-(UID=Turn) event.
B
38
S
11
G
5
Posts: 485
Reputation: 5,340

Post » Tue Feb 24, 2015 4:07 pm

szymek wrote:so what approach would be the best for i.e. big platformer level,
with i.e. 100 enemies, each with "Platformer behavior"?

I have no specific advice. It should work OK whatever you do.

fldr wrote:do you have any advice how to work around "For each object" ?

The only way to avoid per-instance work when picking objects in events is to start the condition with a 'On collision' or 'Is overlapping' condition, which uses the collision cells optimisation. All other conditions will pick from the full instance list (across the entire layout). Alternatively, completely destroy objects that are far away instead of trying to deactivate them with events (since you will need per-instance work to figure out if you need to reactivate them yet).
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 2 guests