Feature Addition: "Room Object"

Discussion and feedback on Construct 2

Post » Mon Nov 17, 2014 9:39 pm

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:

    1. 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.

    1. 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...

    1. 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.
Last edited by Nesteris on Tue Nov 18, 2014 1:09 am, edited 1 time in total.
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 » Mon Nov 17, 2014 9:59 pm

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.)
Last edited by Tokinsom on Mon Nov 17, 2014 11:37 pm, edited 4 times in total.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Mon Nov 17, 2014 10:33 pm

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..
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Mon Nov 17, 2014 11:04 pm

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.)
Image ImageImage
B
168
S
50
G
169
Posts: 8,281
Reputation: 108,191

Post » Tue Nov 18, 2014 12:07 am

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.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Tue Nov 18, 2014 12:22 am

@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? :D (PM me :shock: )
@ 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 :lol:
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 1:21 am

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?
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 1:24 am

@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.)
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Tue Nov 18, 2014 2:42 am

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?
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 2:47 am

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.
Last edited by Tokinsom on Tue Nov 18, 2014 3:06 am, edited 1 time in total.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 13 guests