Feature Addition: "Room Object"

Discussion and feedback on Construct 2

Post » Tue Nov 18, 2014 8:54 am

@Tokinsom
@Nesteris

Is the request to bind instances on a "room", to create them or store/destroy them together?
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Tue Nov 18, 2014 10:05 am

@Nesteris
Having to load/unload/reset the entire layout for a room change sounds terrible for performance and gameplay reasons.


We're not resetting the entire layout, only parts of it.


1) Re-Load layout zone (x1,y1,x2,y2)
2) Destroy all objects outside layout zone (x1,y1,x2,y2)


I was referring to this which seems to imply having to load the whole layout, and destroy everything outside the zone.
That would make each room change become a full layout load, and need to destroy potentially many objects outside the zone.

Layout load region as you described sounds like a performance killer with larger more complex worlds taking longer and longer to load each time you need to go to a new room. I can't see layout zones being a good strategy in the long run.

It sounded like they would load the entire layout, choose that region, and destroy everything outside the region?


This might be different since it's a 3D game example, but Metroid Prime actually did the exact same thing you're saying is a bad idea.
You only had the room you were in loaded into the game and the rooms that were adjacent to it ready to take the player. The rest didn't exist. The loading of the rooms and such was hidden in the transitions i.e. The time it takes for the doors to open when they need to.


The issue is Construct still holds all the textures in memory. Even if a "room" only needs a grass zone sprites. The game still has the grass+arctic+interior+any other graphics the layout uses loaded in memory. If the idea is to have multiple rooms, this means many tilesets potentially being used. We meet very similar issues we already face. CPU and GPU load will go down, but memory usage would go up until people keep reporting games are crashing. You could have 60fps on a device with enough memory. And an instant unexplainable crash on a device with too little memory.

This is why a plugin won't work.
hopefully I'm wrong about how construct works and how memory is managed in layouts, but this is why it would have to be internally changed by @Ashley.

I apologize but I do remember you saying:
if that means sacrificing local variables. And removing layout persistency I am fully against the idea. Layouts would be obsolete

So yeah.


I am against that. I don't believe creating a layout inside of the layout is a solution. And that was the route things were headed in the other discussion. Many of the "features" being discussed were not necessary and caused many redundancies.

But anyway let's shake hands, be friends and not argue about things that will just waste time.
The important thing is that we both want this "Room Object" in Construct 2 and that it's done right.

However, do put words in my mouth and try to make me out to be the bad guy, you did say you were against it (something now the opposite) and I quoted what you wrote, if you want the link to that comment or even a screenshot I'm happy to provide.
And at first you advocated using arrays instead of this. So do not try to turn this against me.
I came up with the Room Object idea in the first place too :3


I support the idea, but was against the implementations. This thread has deviated away from the implementations of the old thread so I couldn't have been too crazy to think the implementations or direction discussions were going were less than ideal...

I still advocate arrays can do this to an extent. Memory issue aside, you can create and destroy entire levels/rooms stored in arrays/xml. Doing so is simply far more complicated than it needs to be.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Tue Nov 18, 2014 10:19 am

@Tylermon

1) Re-Load layout zone (x1,y1,x2,y2)
2) Destroy all objects outside layout zone (x1,y1,x2,y2)

Yes, they are the main ideas of my rex_grid_freezer plugin.
The problem is - how to indexing the saved instance for better performance. I split whole layout into grids, to save instances into these grids or load them all in a grid.
It might not fit your request I guess.
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Tue Nov 18, 2014 10:41 am

Is the request to bind instances on a "room", to create them or store/destroy them together?

@rexrainbow
Whichever saves more memory. Maybe you could think of a room as a customizable pre-set that you make.

I.e. Room Preset 1; Contains Missile Power Up (Persistent so it disappears and can't be farmed.) Enemy A and Enemy B.
Say the player went into this room, the missile and A-B enemies are here. Player takes missile and kills enemies A-B.
Player then leaves and re-enters, Missile is not present but Enemies A-B have been reset/respawned.

I think I'm just making it overly complicated, this might be better explanation;
Stores the binded instances on the room, when the player enters the room they're created, when player leaves they're destroyed.

Hope that was simple enough. I'm just pure bad at explaining, but that's why @Tokinsom exists.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Tue Nov 18, 2014 12:35 pm

Ok I need to point out that this method of dynamically loading/unloading parts of a greater layout IS NOTHING OUT OF THE ORDINARY. The whole reason I pitched it in the last thread is because Megaman X: Corrupted (and likely many, many other games) does it flawlessly. THE ONLY DIFFERENCE is that game's editor seems to save rooms in individual files, and textures and such are loaded/dumped on the fly (C2 should probably give you more control over this anyway).

Obviously we have to work within the confines of C2 until Ashley decides how to handle this, but it doesn't seem like anything too complicated to implement.

Finally, we do not have all the answers, but we have most of them. Less problems, more solutions!


@Tylermon You have valid points but also misunderstood part of what I was saying. No, the whole layout is not loaded and the rest destroyed every time you change rooms...Instead, only one room is loaded, and only one is destroyed. This can be changed to more depending on the game type, but would likely never be above ~5 rooms at once, which isn't that big of a deal. As for memory, I guess we just need a way to dump it manually, right?

@Nesteris The very first event sets the layout scale to 0.5 to view areas outside the current room (for testing). No bugs there. Just disable that event or increase it to 0.8 or something.

@RexRainbow Ok that's great, but I have no idea how to target multiple object types with 1 GridFreezer (I get javascript errors when I try) nor can I change the size of the mask at runtime depending on the current room size...if you're just using a grid then this doesn't fully qualify. Perhaps you can take a look at the .capx I uploaded and see what I did wrong? Unless you need to make some tweaks first.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Tue Nov 18, 2014 1:36 pm

@Tokinsom
Thanks, 0.8 actually did fix the red bars showing up weirdly, chucks of it were missing before.
Also
(I can show you exactly how I did it in my ZM engine; it's really not that hard...I was just being stubborn and didn't want to hand out my code, but I don't care now.)

Could I please see it? Been wondering about that and the player animations. I PMed you my email.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Tue Nov 18, 2014 2:08 pm

@Tokinsom

Thanks, I had fixed this plugin bug and fixed the capx, too.

Download rex_gridfreezer plugin and download fixed capx at this link. This capx is pretty cool, thanks for sharing.

Sorry that I had not tested the case of adding multiple object-type.
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Tue Nov 18, 2014 2:40 pm

@Tokinsom

I had played this capx.
The "room" will be created when player moves across boundary, it might not be smooth while player is stand at the boundary, only half of floor had been created.
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Tue Nov 18, 2014 2:45 pm

@rexrainbow

I tried your suggestion, I think that either you broke it or it doesn't work on my computer.

When I open it in Construct 2, it looks normal;
gridf.png




Then I go to preview it and get this;
gridf2.png



I then click okay and it looks like this;
gridf3.png




Any idea what how to fix it?
You do not have the required permissions to view the files attached to this post.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Tue Nov 18, 2014 2:48 pm

@Tylermon Unless I am wrong, objects will get loaded only when created if they are not physically in the layout view, however, what I am unsure about, which is also the main problem in theory of the current methods, is objects that are created only at runtime, do they get unloaded from memory when destroyed? (I remember seeing that indeed, in the case of created at runtime objects, they will be unloaded when they are destroyed, could be wrong though, but as long as we have no confirmation, we are making assumptions only.)

My idea of room objects is that it will create the objects at runtime, not by default, and som unload If my interpretation of it is the good one.

what-get-s-loaded-into-memory_t108895
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: dop2000, Lancifer and 3 guests