Rooms versus Panes (formerly Windows)

[luiscubal]

Disclaimer: This is NOT an operating system discussion.

ENIGMA uses rooms, a concept it inherits from Game Maker.
I'm going to ignore the issue of compatibility for now.

The idea behind Windows/Panes(a concept based on RPG Maker) is *NOT* to have a game with multiple windowing system windows. That'd be awful. I mean in-game windows/panes, such as dialogs and menus.
If you think about it, most games feature some sort of controls system, which I typically implement in Game Maker using the Draw event.
"Pause" is typically kind of an ugly hack, and so is keyboard management with menus.

Windows/Panes(along with focus) solve this problem by ensuring only the focused window/pane receives keyboard events(or something like having a "Global Keyboard Event" like what happens with the mouse). For RPGs, this means messages are incredibly simple to implement.
For some windows/panes, this might require some more effort, to ensure the world "stops" when e.g. pausing the game(set hspeed=0, etc.)
Still, simple compared to the situation of what we have in GM today, where I find myself reimplementing the system for some feature subset.

What do you think about this? Surely, Windows/Panes can be implemented using Rooms and Objects. But... what about doing things the other way around? Like implementing views using windows/panes.

Post made January 21, 2011, 06:12:48 pm was deleted at the author's request.

[luiscubal]

It is entirely unrelated to this topic. As I said, I mean "Windows" as in-game GUI controls.

[Josh @ Dreamland]

It isn't entirely unrelated. You presented a system in which keyboard events can be withheld depending on which context ("window") an object is in. Fede brought up a conflict.

Windows(along with focus) solve this problem by ensuring only the focused window receives keyboard events

What about keyboard_check_direct()?

The answer, of course, is that keyboard_check_direct would transcend this 'window' concept.

Surely, Windows can be implemented using Rooms and Objects. But... what about doing things the other way around? Like implementing views using windows.

Your 'window' system is more convenient than rooms, views, and objects. Views can not be done with windows, unless multiple windows can be in focus at once.

Anyway, I like the idea, and I see it as being easily feasible. I'll talk to Ism about it and we'll decide on an interface. Suggestions welcome.

[Rusky]

I think this would be a good time to start thinking about an extension system. This level of feature is best done in a library, possibly with extra support in the engine.

[Josh @ Dreamland]

I began development on an extension system a while back, with the intention of making paths, alarms, and local groups such as lives/health/score, extensions. Windows sound too fundamental to make into an extension; they're better suited to being part of the room editor.

Maybe if Ism could get the room editor to iterate a list of objects containing methods to manage and draw each component of the room... But then, how would the extension describe that it is a separate context into which instances can be placed? The room editor would have to have some understanding of a context anyway, which it would not gain from views (views are drawn as outlines in the room editor; instances can't be placed in them).

I mean, it's perfectly possible, I just personally think the solution is kind of ugly. The first method that comes to mind is to add a callback for every function of the room editor. The window extension would establish a callback for when an instance is placed in the room, when the room is being rendered, when the room is being loaded, and when it's being saved. If Ism thinks such a system would be acceptable, I'd be happy to write the back end to it.

[luiscubal]

I'm not sure I like having windows bound to the room editor. After all, some windows tend to be common across multiple rooms, so while some of them are room-specific others transcend that concept.
Consider, for example, a message window(RPG talk), the window in this case is closer to objects than to rooms.

That said, I also think views should be separated from the room editor.

[Rusky]

If extensions were able to create new resource types and include editors for them (as would be necessary for a path extension), how hard would it be to allow them to access other resource types, and allow built-ins to use them through some standard interface? Windows could have their own editor that would allow you to place instances, and windows could expose an instance-like interface to the room editor so they could be placed in rooms. They could react to events like instances, using that interface, in order to take over focus and so on.

However, making windows a built-in resource might make it easier to deal with pausing and focus-grabbing. If the normal GM-style room were a kind of window, using another window inside could be as simple as switching the game loop's primary event handler, bypassing the current room.

[luiscubal]

Pausing and focus-grabbing is weird, since not all windows would pause the game and focus-sharing...
But yes, an extension system like that could be better.
I am unsure if windows should contain instances or just Create/Destroy/Step/Draw events(perhaps with just plain GML?)...

[IsmAvatar]

I like the idea, and I'm happy to assist in any way that I can, as long as we can maintain some level of compatibility with GM - meaning that I expect the GM-compatible side to be implemented first, I expect it to continue to function throughout the entire process, and I expect an immediate way for the incompatible stuff to either be immediately convertible or markedly inconvertible (e.g. a variable says "Wait, this isn't convertible with GM. We'll need to extend into our own incompatible format"). Preferably the prior option, but I can understand that some concepts are too extreme/revolutionary to be convertible, and I want to be somewhat open to them.

Also, I like where the extension system is going as well; I expected it to come, considering ENIGMA's extensibility. Again, however, I expect compatibility to be maintained.

Why? Because it's a bitch to try and restore it later, and everyone will get lazy and it will never happen.


Also, I'd suggest another name, like Frames or Panes or Panels. A window usually has the close button and such.

[luiscubal]

I suppose "Pane" is a pretty good name.

[Josh @ Dreamland]

Okay. I think the best solution to this is to give added resources a render() method for addition into the room editor and a get_selector() family of methods to create and handle a combo box chooser. (And an is_instantiable() method for if it can be placed in the room at all).

By this method, Panes could have their own editor with some pane-specific functionality, and rooms could just instantiate them.

[IsmAvatar]

In Java, normally if you want to allow something somewhere, you have it inherit from an interface which defines any methods needed for that somewhere, rather than provide an is_ method. For instance, a component which may be added to a room can inherit from the org.lateralgm.ui.swing.visuals.Visual interface, which provides a paint(Graphics g) method (Java's standard render() method).

[Josh @ Dreamland]