Feature Addition: "Room Object"

Discussion and feedback on Construct 2

Post » Tue Nov 18, 2014 2:59 am

In the end i'm indifferent on the How. The issue I have right now is that gargantuan seamless worlds are not effectively doable with different thematic areas.

Room objects, Asset bundles that can be un/loaded, layout stitching, XY load/unload... many solutions are available. But someday having one would be fantastic.
B
92
S
18
G
9
Posts: 2,455
Reputation: 15,113

Post » Tue Nov 18, 2014 3:12 am

A bit of a sidetrack: I tried creating an extremely large layout (64,000, 48,000) and populating it with an extremely large number of objects (~64,000). Here's the capx:

https://www.dropbox.com/s/p4meia45sk0a5 ... .capx?dl=0

A few things I noticed:

1. The resultant runtime.js file, even after minification, is huge (over 6mb). It looks like the main culprit is the x/y coordinates for placed objects, which retain way too many fractional parts. Example:

9293.955078125 -- (14 chars)

which could be

9294 -- (4 chars)

Couldn't there be a system wide option to round object placement to the nearest integer?

2. The resultant game slows down badly, mainly because I made my objects too dense in places. It runs much faster when minified and exported. However, I notice that draw calls take up a lot of the cpu, especially when moving around. This seems consistent between browsers, even when in WebGL mode. I may be simply hitting the wall w/ my HD4000.

3. The game takes a long time to start...having to generate all those objects no doubt.

To summarize...I just wanted to see what happened with the system being what it is now.
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Tue Nov 18, 2014 3:15 am

I had thinking this question before. My solution is to maintain a "living window",
- objects outside this window will be stored into a data structure and destroyed
- when living window moved, stored objects in this living window will be created

Here is the plugin of the solution.
I split whole layout into grids, and the living window is defined by composing of some grids.
Last edited by rexrainbow on Tue Nov 18, 2014 3:17 am, edited 1 time in total.
B
110
S
28
G
280
Posts: 4,488
Reputation: 156,568

Post » Tue Nov 18, 2014 3:17 am

@TiAm Yep. And none of that will be a problem with the features proposed here because only a small part of that gargantuan layout will actually exist at any given time.

@Jayderyu I don't follow. With these features you can make as many area types as you want and still have them seamlessly connect.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Tue Nov 18, 2014 3:27 am

@Tokinsom

Ah, I see...at first I thought you were talking about how to do this with the existing capabilities. Now I understand you...

I think everything we've talked about in these threads can be achieved with 2 simple actions:

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


This sounds perfect. So, we can have zones that define what is 'inside' or 'outside' the active area. Then we can define what to do when objects goes outside that area (destroy, save state and destroy, don't do anything to them, etc), and what to do when object comes into the zone (load state, create with default settings, etc). So, in most cases, we would just create one of these 'zones', define it's size, and pin it to the player.

Now that sounds good...:)
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Tue Nov 18, 2014 3:34 am

Feels like you're headed down the rabbit hole with the memory management bit.
You have to take whats doable for both webgl, and canvas into account.
Rex's solution deals with that to some extent.
Image ImageImage
B
172
S
50
G
183
Posts: 8,440
Reputation: 115,599

Post » Tue Nov 18, 2014 3:38 am

@Newt Ideally the layout data would not be parsed, but split into separate files based on the layout zones. I'm not sure how Ashley would feel about that, though.

@RexRainbow I would prefer to see an official implementation of this but your plugin certainly looks promising. I'll have to look into it further.

EDIT: Ok I've been messing around with the GridFreezer plugin for a while now and I'm not sure if it's really a suitable replacement...Unless I'm missing something...

-You can only store one object type per GridFreezer instance, and have to specify it with an event.
-Your "rooms" have to be the same size.

If there could be a way for it to store all objects within a room instead of specified instances, and a way to for each room to have its own size, then it could probably
work..

This is what I managed to come up with.
Notice what happens when you change the size of a room. Not really sure what to do about that.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Tue Nov 18, 2014 7:51 am

This topic has two sides to it. The I don't know how to transition rooms/ layouts side. And the we need better memory and world managment side. I'm only going to talk about the memory side of things. As that is my main concern.

I feel no matter how you look at this, it will boil down to data driven world creation, be it arrays, dictionaries, xml, in the end it does not matter but some sort of room storage would need thought up. For the non-technical just ignore that sentence.
But with data driven creation the issue becomes the textures and memory.

One big concern of mine, is how will textures be loaded and destroyed from memory? A big part of this is being able to create and destroy the world. I can see how the cpu/gpu get immediate benefits.
But issues I come into with my own projects, cpu and gpu issues are easily avoided with dynamic data driven creation/destruction. Strings stored in arrays, or xml parsing.... But memory is where everything falls apart.

If the layout has 200mb of sprites and textures, it keeps those available even if not being drawn. If we have dynamic creation that "rooms" is hoping to achieve, we need a way to load different textures per chunk/room as needed. Without that, everything is pointless. You get a large map of different environments and we can do nothing to optimize.

Loading/destroying textures can have performance issues where people have to take a moment to pause and load new textures. Think minecraft chunk generation, very similar concept.

@Tokinsom
Having to load/unload/reset the entire layout for a room change sounds terrible for performance and gameplay reasons. 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?
-------

An "easy" solution is honestly if layouts had better transitions or options on how they interact. A layout is a room. Does everything a room does as is being discussed but without the redundancies. If these could transition nicely and had ways to better work together between layouts this discussion probably would not be taking place. Memory and textures would be handled. Rooms/layouts would be easier to chain together in nice seamless ways.

-------
The above "solution" does have its own set of problems though. Such as segmentation of level design.

Thats why I mentioned the entire array topic. It would do EVERYTHING you guys keep talking about. Without the redundancies of being a handicapped layout.
@aphrodite described the system I previously talked about rather nicely.

The "Room" simply needs to store object locations and types/ statuses like a container(array).(all of which is currently possible, simply the room object would make this easier and visual)
Drag the items into the room, a layout like object and it will remember where everything is, and what all the behavior states are set to.

In the event sheet, that room object would be called. When you do, you see all the objects events inside of that object. This gives easy control over that specific room.

Because all the objects in a room are associated with the room, you can destroy the room(or create) and all the objects also get destroyed(or created) Just like an array, you can modify, delete or add objects to the room without deleting or affecting the rest of the room.

Whatever the solution. Textures/memory still remains an issue.

For those set to believe I simply don't like this idea or what have you...
No it does not replace arrays. No rooms don't replace layouts. There is in fact a visual and code disconnect, most of what is being talked about can be done, simply not as easily as it could be. Get that self deluded fantasy out of your head. And stop going in circles about issues @nesteris not understand something I describe is one thing, continuously placing false words or beliefs into my mouth is something entirely different. I'm not against this idea of "rooms"...I fully support it, and would advocate this is an essential feature that MUST get implemented at some point. However, I want it done right. So yes, I am going to talk about all the flaws I see in it. Anything that I can see holding some1 back or creating a limitation I am going to bring up. If solutions to the flaws cannot be thought of, the system will be pointless.I don't want a half thought out feature implemented. Would you get in an airplane without landing gear? Sure it flies. But at some point it will come crashing down.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Tue Nov 18, 2014 8:15 am

@Tokinsom

Like turret behavior, rex_grid_freezer plugin could listen more then one object-type (but I had not tested multiple object-type yet).

The room - or "logic mask" in my plugin is configure-able. The size could be changed. You could also use hexagon grids in my plan.
Basically the room/logic mask is configured with a little larger then view port.
B
110
S
28
G
280
Posts: 4,488
Reputation: 156,568

Post » Tue Nov 18, 2014 8:30 am

@Tokinsom
I get glitches when I preview it in Node-Webkit, all the graphics look fuzzy.
When I previewed it in Waterfox it works normally but all the red lines from the 9-patch are either missing bits or popping in and out, also when I move from "room" into the next the previous area flashes for a frame or two.'
Bugs?

Also sent you a PM.
@Tylermon
Alright, my apologises for misinterpreting your previous comments. As for the current ones.

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.

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.

An "easy" solution is honestly if layouts had better transitions or options on how they interact.

Yes it would be nice, but sadly they don't so here we are. I am with you on that though.

The "Room" simply needs to store object locations and types/ statuses like a container(array).(all of which is currently possible, simply the room object would make this easier and visual)
Drag the items into the room, a layout like object and it will remember where everything is, and what all the behavior states are set to.

In the event sheet, that room object would be called. When you do, you see all the objects events inside of that object. This gives easy control over that specific room.

Because all the objects in a room are associated with the room, you can destroy the room(or create) and all the objects also get destroyed(or created) Just like an array, you can modify, delete or add objects to the room without deleting or affecting the rest of the room.


Pretty sure you just perfectly summarized what we want the Room Object to do.

And stop going in circles about issues
@nesteris
not understand something I describe is one thing, continuously placing false words or beliefs into my mouth is something entirely different.


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.

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

What I'm try to do at this point is just help facilitate @Tokinsom and the other greats to help improve upon the "Room Object" idea, so let's stop pointing fingers and do that instead. I left supposedly "putting words in your mouth" as you put it alone in the old thread, I suggest you do the same.




@rexrainbow
Since you obviously have experience making plugins, could "Room Object" be made into a plugin? Might be less hassle for @Ashley
Just an idea.



As for any confusion, I apologize.
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

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: ardhitosen and 5 guests