GameMaker-Bugs
GameMaker-Bugs copied to clipboard
YoYoGames
Remove Room Inheritance
Is your feature request related to a problem?
Room Inheritance has many fundamental issues with its functionality, complicates general development of features and the Room Editor, and there are far better ways of achieving the same results.
Describe the solution you'd like
Remove the functionality of room inheritance.
We are adding this Feature Request ourselves as we would like to remove Room Inheritance going forward... this is your opportunity to tell us what you are actually using it for, so we can work out what needs to be done to replace it.
Personally, I never used it, so it wouldn't really affect my workflow that much. Might also have something to do with the fact that Room Inheritance had a reputation for being broken, so I didn't really touch it. An alternative would be polishing up the Room Inheritance so that it's actually usable, so either fix it or ditch it.
If it's removed, then the project converter tool will need to propagate inherited data to rooms themselves, so that no existing data is lost.
Also, I guess it would be good to figure out what makes people want to use room inheritance in the first place, and whether these needs are properly addressed by an alternative.
One thing I can think of is having a consistent set of layers, which then can then be used to place elements via Room Editor; when it comes to that, an alternative such as e.g. building layers from code won't address placing things via Room Editor. Another option would be adding layers manually - on paper the time spent on adding layers should be negligible compared to the time spent placing instances and the like. But manual adding is more prone to typos, which can be especially troublesome if layer names are used in code for further processing.
Although the idea for inherited rooms is fine, I think overall it is confusing, as rooms have so many moving parts. There are some use-cases for inherited rooms, but one could live without them with building just single room, where all base layout is done, and then having separate layers which are deactivated/ activated according to the need. Like start of the room deactivate all instance layers which are "act specific", and then only activate whatever is required.
I would like a rework or remove and replace it in a future with a better system. Something that would let us control in the parent room how each parent layer should behave in the child rooms would be great.
For example to control if a layer should inherit the instances that are there or not, and only inherit the layer name or the depth.
This could work for organization purposes, and when we need for example to rename a layer in the parent, all child layers would be renamed too. And we wouldn't need to rename or change the depth of layers on tons of child rooms manually...
Ummmm... I'm kinda torn on this one. I know it's quite buggy right now, but my current long-term project absolutely RELIES on it! So removing/changing it in the near future (ie: the next 6-12 months) would seriously impact my project. Yes, I can stay on the last version that still has it, but with the way the team is adding new features and functions to GameMaker, I'd rather not do that and miss out on all the good stuff!
This, however, is a very selfish attitude and - in general - I think the feature was never correctly implemented and has several bugs/edge cases that make it difficult use predictably. So, if the best way forward is to remove it and replace it with something new, then I guess that's fine. It's potentially a very powerful concept (and the present limited iteration has certainly made my life easier on my current project), so I don't think it should just be removed. Something "better" should take it's place...
That said, if you can simply fix the current implementation then so much the better, imho, but I have a vested interest in it not changing too much... 😅
Current thoughts are too leave it (Room Inheritance) in the current room editor but in the New Room Editor (which we are designing / thinking about now) we are thinking about removing it completely.
You would be able to use the current room editor for your current project.
Current thoughts are too leave it (Room Inheritance) in the current room editor but in the New Room Editor (which we are designing / thinking about now) we are thinking about removing it completely.
You would be able to use the current room editor for your current project.
Interesting. This sounds like a good way to go and definitely gets my support.
I used it extensively in my last project but I think it just made things more complicated. Being able to copy layers, camera settings etc easily from one room to another would be more useful.
I gave room inheritance a shot last year. It's never quite worked right, and for every project since, I've simply had a "prototype" room that gets copy-pasted every time I need a new level. In the ideal world, I could see the feature doing some good if (a) all the bugs were squashed, and (b) the UX was changed to make it far more intuitive, especially to beginners. But given the amount of effort that would take, I'm in support of removing the feature going forward and calling it a well-intentioned but failed experiment.
I kinda like the ideia of Room Inheritance, but the current state of the feature is too buggy.
Also, I guess it would be good to figure out what makes people want to use room inheritance in the first place, and whether these needs are properly addressed by an alternative.
I've been using it for creating cutscenes. It's made a lot easier for the rest of the group to just inherent the template room and setup the cutscene behavior. But I think with the upcomming Prefabs and GUI Layers, the Room Inheritance will be obsolete for real.
I personally never need to use Room Inheritance, so I'm fine without it. There are better ways to deal with the situation, which for me make me feel like I have more control over things, which is what I particularly prefer.
Kill it! I think a much more useful feature would be putting rooms inside of other rooms. This would be similar to a composition vs inheritance tradeoff. That might also be a big ask tho..
As others are saying, the current implementation of room inheritance is unreliable. That being said, I believe the concept is close to gold. There are many occasions where I'd like have a common view size across all my rooms, perhaps a background layer or in the future, a shared GUI layer. This means that any change to the parent room, will be inherited to all the child rooms, allowing for resolution and other changes to be done quickly. This is what I'd like to see from room inheritance. A simple way to change parameters across multiple rooms at once. I could nested parent rooms being useful also. For example, a level game where you might have a parent room for all the levels to set a common resolution/view. Then you could have a child room, which is parent to levels 0-9, giving them a particular theme and background, and another parent for levels 10-19 and so on. Could make development easier for these such games.
I stopped using room inheritance due to how buggy it is, and now I use a template room that I duplicate instead. However, it'd be nice to have some way to edit layers for all rooms at once, since right now if I ever want to add/remove/rename any layers, I have to go back and do it in all my existing rooms one by one. I imagine this sort of mass layer editing could be added in a way that's not inheritance, so I'd like to see that. Something like how you can select multiple assets and edit properties for all of them at once in the inspector, but for rooms
I have a very bad experience using it. It created a ton of issues and problems for me and therefore I decided not to use it at all for any other project.
I feel like all of the things room inheritance was originally intended to allow you to do (creating user interface layers shared between rooms, template rooms, etc) now have better solutions elsewhere.
If rooms had event callbacks and had their own struct which we could access via dot access on the room, I would argue that room inheritance is needed...but I am also of the mindset that things like layers should be their own type that is untethered from the room, and that cameras and views should also be stored in a way that is not attached to rooms before even entertaining the idea of rooms being more object like.
So I agree, the feature should be gotten rid of and maybe revisited in the future if rooms become more like objects/structs
I didn't used it because it is too buggy to begin with
Maybe just change it to "template rooms" that don't inherit anything more than the "structure" of the room, so i.e:
Have a template room with all the settings, objects and layers I want to use on children rooms so i can just press a button like "Create room from template" and have it all set.
Nothing about inherance of IDs or parent rooms with somewhat same ID, just a new room with new asset IDs, new layer IDs, etc.
I know this is something similar to what we already have, but maybe removing some features that make the rooms have some dependence on previous parent rooms so made this system so buggy will be a better solution than removing it
While I agree that room inheritance is borderline useless in its current decrepit state, I think it would be extremely useful if it were stable and complete. It just feels unfinished in its current state. If there are no plans to fix and improve it then sure, remove it, but I think it's a shame to lose it without anything to effectively replace it. My vote is to fix it and improve its utility.
I am currently using room inheritance, but I'm pretty new to Gamemaker. I am mostly using inheritance for shared UI layers, but from what others have posted here, it sounds like there is probably a better way (maybe just persistent objects created in the first room? I'm not sure).
I do really like the idea of room inheritance, but unless there were some fixes (or at least an easy way to force re-inherit on all rooms or children of a specific room) I will admit it's not very useable. I would say that's the only real feature that is lacking for me, some way to update children after making changes to a parent, which is currently a very tedious process when you have a lot of rooms.
I think removing the feature for the new room editor is a great compromise, it'd be nice to avoid breaking existing projects. Once I learn a little more I'm sure I could transition my projects away from room inheritance, and others could likely do the same.
I've tried using it at some point to hold layers with backgrounds and default room settings. But there were a lot of bugs because fo it so I hade to drop it. Instead of room inheritance I'd prefer if there were something like prefabs from Unity. It can do the same thing, but they are easier to reuse and can be stacked.
(╯°□°)╯︵ ┻━┻ Throw it away. I've never used it. It's easier to make objects which change their appearance based on some variable, or event to replace tilesets, than to manage room inheritance.
To keep it backward compatible, on project opening, main room should be duplicated, and then any changes to "inherited" room applied, so game would still work.
In my code library, I have a "rmEngineInit" room that creates systems objects, which is always put last in the room order every time it's re-imported into a project. To get around this, I make a child room of it, and put that child first in the room order. This is the main thing I use room inheritance for - I've tried using it for certain game rooms as well, but because the room size getting inherited creates issues it's not ideal in its current state.
In my code library, I have a "rmEngineInit" room that creates systems objects, which is always put last in the room order every time it's re-imported into a project. To get around this, I make a child room of it, and put that child first in the room order. This is the main thing I use room inheritance for - I've tried using it for certain game rooms as well, but because the room size getting inherited creates issues it's not ideal in its current state.
Sounds like you're solving event execution order issue here using it. That's one way to do that instead of using persistent objects I guess.
In my code library, I have a "rmEngineInit" room that creates systems objects, which is always put last in the room order every time it's re-imported into a project. To get around this, I make a child room of it, and put that child first in the room order. This is the main thing I use room inheritance for - I've tried using it for certain game rooms as well, but because the room size getting inherited creates issues it's not ideal in its current state.
Sounds like you're solving event execution order issue here using it. That's one way to do that instead of using persistent objects I guess.
I'm not sure I understand what you're saying - it uses persistent objects, they just need to be created in a room first.
Oh, sorry. Misread that. Was thinking you was using room inheritance to store system objects as default instances, and so they are always first in the creation order.
Oh, sorry. Misread that. Was thinking you was using room inheritance to store system objects as default instances, and so they are always first in the creation order.
Got it! Yeah I should also clarify: by "systems objects" I mean different helper objects I've set up like a cursor object, camera object, different GUI stuff, a debug controller, etc. Things that I use across a lot of different games! So having the room that creates them appear first in the room order is fairly important for this.
Room inheritance is a must have feature.
My project relies deeply on that as it has many rooms. It's a disaster having to update all manually every time I add or remove a layer.
It can't be that difficult for gamemaker to implement this.
"If room is modified then update all children".
