Feature Addition: "Room Object"

For Ashley && Tokinsom

Brief Summary:

Feature Name: "Room Object"

Features;

• "Room Object" is an object that is imported into a layout, in the same way you would import a sprite or tilemap.
• Camera can be bound inside them and cannot scroll out of them (Bound/Unbound scrolling)
• Dynamically loading/unloading portions of a layout based on room objects. They'd be triggered with existing events, such as the player colliding with them or being within a distance of them. - Updated From Tokinsom's comment.
• Because room objects would effectively turn off all other parts of the layout, memory overload and performance issues on extreme sized layouts would be a thing of a the past. But that's an educated-guess at best.

Another Plus+ is that developers could see a vast majority of their playable game in fewer or even one layout, I can also imagine there being less loading screens to visit since it would be possible to put the game on one layout.

The room to room transition would act just like normal camera scroll transitions in a single layout, thus simplifying things and allowing a Super Metroid like transition to be made by just adjusting the camera speed and adding a black fade layer, yet the previous room object (part of a single layout) would reset and freeze as if it were another layout.

Frequently Annoying Posts:

• P:Arrays are better! They give you a lot more control and customization! I am against this because I do not want Room Object to replace Arrays and Strings!!!!! A: "Room Object" is a feature addition it is not intended to replace other features or remove them.
• P: The issue seems to be a visual and code/data disconnect. People want an easy visual, yet high level of control. At least not from what I have read and see. What is proposed does not make this possible. An easy visual solution just cant give the control needed for the instances where the proposed tool would even be useful. Not in a basic sense of keep these rooms loaded. Don't load these rooms. All of it is one layout, etc etc. It seems to miss the whole point of wanting rooms, and I cant see it being useful from what I have read so far. A (copied from ErekT's reply to this): As I see it, just the visual aspect itself is important. It's relatively easy to structure a non-linear path between layouts when you have just a handful of them. But what if you have something like a 100 room arrangement and only a right-hand list of layouts to organize them with? There's no visual overview of how the rooms are connected within the editor, which makes things tricky. Of course you can draw the entire map structure out on paper, arrange sections of the map within separate layout folders to keep it less cluttery and so on, but yeah...
• P:I can see how this would be useful but can certainly live without it. I'm sure there are higher priorities on the list. A: I'm sure there are but that could be said for a seemingly infinite number of things, such as the post this is replying to.

RULES OF THIS TOPIC THREAD

1.

Do not post to disagree with the feature just because you don't see any use you personally have for it.

If you can do it some other way and prefer it, then fine.

If your post is intended to be a negative contribution please keep it to yourself.

2.

Keep posts Relevant to this topic.

3.

If you have ideas to improve this Object please post them,

if you questions about using it that have not been answered please ask them.

It's important for Ashley to get an idea of how this would be used and in what way so he knows how to better implement it.

Honestly you made this sound much more complicated than it is and added a bunch of unnecessary features..

I'd describe it as dynamically loading/unloading portions of a layout based on room objects. They'd be triggered with existing events, such as the player colliding with them or being within a distance of them. Very simple, really

The camera boundaries, timescale, and fade stuff can and should be done with existing events, making transitions more customizable or seamless if you wish. (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.)

A way to, I would think, handle that while still having a good control over it, would be that maybe rooms acts like container that you defined partially(sort of):

When you create the room, all the objects inside will be created at the relative positions to the room (something I actually tried, and failed to, do with events combined with layouts, maybe did not tried enough, or did not understand the purpose of Json objects strings.)

You could pick objects that are related to the room object instance you want

When the room is destroyed, or that an action "clear room" triggers, all related objects are destroyed (from my understanding of C2, if an object that was not included in the layout view is destroyed while there is no more instances of it, its texture will be unloaded from the memory)

When an object is destroyed however, the room associated with it will not be (saying that because I compared them to containers, and I know people would have brought that up..)

So the room could basically be:

A rectangle (or other shape but for now, lets not be to complex) that when a action "load room" is triggered, would create instances of ennemies, grounds, tilemaps or other things, relative to a predefined status (like if the room was done in a layout like view, each instance saved, then created at runtime relative to the room position and potentially size, but position would be fine).

One current workaround for that would be a tilebackground room object, and a careful event creation of the objects with a carefully crafted function, the specificity of the Room object I defined would help a lot in that (as the create room function, and easier handling of positions and data via an edit room like layout view would make it really easy).

The camera shall not be controlled by bounding to the current view by defaut I would think, but since you could always do a manual camera handling if you wanted, it is not that big of a deal..

For when you want to try to implement it in events.

If foo set scrollx to clamp(yourvalue, lowerbound, upperbound), set scrolly to clamp(yourvalue, lowerbound, upperbound.)

It just dawned on me...

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)

We can then use the position and size of a sprite, tiled background, or 9-patch object to fill in those parameters (acting as these "room objects")...and like I said earlier, transitions and such can be done on our own with existing events.

What do you think? Just trying to make this easy on Ashley.

Tokinsom and Aphrodite

I love you guys, you word and phrase these things so much better than me.

Tokinsom 's first comment, not to be a tool, but does that mean I could perhaps take a peek at your engine? )

Tokinsom 's second comment, we can do that? I guess that if we combined that re-load layout zone and destroy all objects outside layout zone with Zone based camera movement (with a little tweaking for those smooth transitions of course), we could make what we've been talking about. Would that work?

Really glad I got to be the muse for this idea

It seems like a metroid/castlevania type game could be approached through room objects, but what about something like a GTA game, where you can walk from one end of the world to another in a single go (no transition seperating areas). How do you handle that?

TiAm Exact same way! You can simply load & unload nearby zones (likely a grid of equal sized squares in this case) based on their distance from the player. Unless you code a transition it will be seamless. (Check out some videos of Megaman X: Corrupted, it loads/unloads parts of the world in a very similar fashion and it's all seamless.)

Ah, I see...so, you have everything arranged on your main layout, then you store the data for that area (tilemap, objects, etc) in an array or dictionary, and spawn chunks in/out depending on the player's proximity.

So...what would be the most elegant way of dividing up a complex layout and storing all that data?

Eh? No, these features completely eliminate the need to do that because C2 already handles layout data and object creation far more efficiently than we can with events. All you need to do is specify which portions of the layout are loaded/unloaded and the rest is done for you as usual.

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.

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.

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.

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.

Tokinsom

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

[quote:5m8igu0r]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...