Pages: [1]
  Print  
Author Topic: LateralGM extensions; official proposal  (Read 1885 times)
Offline (Male) Josh @ Dreamland
Posted on: January 28, 2011, 10:42:56 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
Once ENIGMA has its own format, it will finally be possible for it to include its own resources in outputted game files. That being the case, it is time, as Luis indicated earlier, that LGM offers a less painful method of defining custom resources.

Notice: I am in no way an expert on Java. I speak in this thread solely on authority of designing the C++ backend to potential extensions, which here is not much authority at all. My suggestions are to be taken not as a suggestion for the Java code behind the mechanism, but as the overall concept of the goals thereof.

That said, I think we should first define the goals simply in terms of what has been shown to be needed thus far (namely, by Luis's "Panes" extension proposal and my "Libraries" proposal which will conclude this message).

Before that, terms. For the purpose of this message (feel free to adopt them for your own), the following lexicons will be used:
"Loader" refers to the mechanism which will load extensions to the LateralGM interface.
"Extension" refers to a single unspecified object the Loader is loading.
"Component" refers to an interface element, such as a button or a graphic.
"Node" refers to a resource tree Component.
"MDI" refers to whatever the fuck that Java thing is that houses all the other editor windows.

  • The Loader must allow the addition of a Node or group of Nodes (represented by a folder) into the resource tree.
  • The Plugin must be informed when a tree Node under its control is double clicked. (original proposal said this job was the Loader's)
  • Each extension will be responsible for tracking its own data and creating its own UI elements in the passed MDI context.
  • Each Extension will be given the opportunity to save or load its data when the rest of the game is doing so.
  • Extensions will be given a method of identifying themselves as being instantiable in other resources
     
    • Take, for example, a 3D mesh resource. It would inherit from a class that can be assigned to a GM object as one assigns a sprite or mask.
    • An Extension that can be instantiated in room will be allowed to be placed multiple times, visually.
         
      • Such an Extension should provide a method to obtain bounding box information for placement and clipping, as well as a method to render itself in the room.
      • Extensions that can be instantiated in GM objects should provide a method of obtaining an iconic preview, as sprites do.
  • Extensions must be able to supply a unique ID and a C-structured or easily restructured dump of relevant data to the output executable. If the ID is not unique, backend plugins (Namely, ENIGMA) will be unable to determine what structure they are looking at, resulting in undefined behavior (like segfault). The data must obviously be easily structured per the C spec (like POD) so that ENIGMA can work with them.
  • A method must be provided of accessing any complicated UI Components to the Extensions (Namely, the JEdit class and the GML syntax highlighting context, which should be easily extended or swapped out in a specific JEdit instance). (original proposal said this job was the Loader's)

I have not decided how the C++ backend should be extended, aside from that it must share a list of extension IDs.

What I have decided on is a new resource that will be added, in addition to Panes. R4's introduction called for a resource dubbed "Whitespace" and renamed to "Definitions." Both names suck. I now propose that this be a tabbed, C-code resource, basically offering what simple C IDE's offer (tabs and a code editing pane with simple features).

This proposal is likely incomplete, but I have work tomorrow and should be sleeping. Comments welcome. Comments from Java programmers especially welcome.
« Last Edit: January 29, 2011, 09:37:17 PM by IsmAvatar » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #1 Posted on: January 29, 2011, 09:50:27 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
Updated with better terminology. Replaced "System" with "Loader", as per its defined job. Replaced "Object" with "Component", Java's name for widgets. Added "Node" component, e.g. nodes in a tree, for more proper use when referring to tree nodes.

I like the idea so far. My biggest concern is that it's difficult to visualize/maintain a 3-tier architecture. I feel very strongly that the 3-tier should be made an integral part of the spec.

For instance, the top-most tier of our Mesh resource would be the MDI window for editing it. The lowest tier would be the data backend of the mesh, and would not contain any special functionality aside from basic necessities for the format. The middle tier would contain all the functionality, like, say, rendering it. Perhaps a separate middle tier would provide the reading/writing of the data.
Logged
Offline (Male) Josh @ Dreamland
Reply #2 Posted on: January 29, 2011, 11:14:55 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
I appreciate how you left the MDI definition untouched.

Anyway, I agree with your outer tiers, but I fail to see how the logic tier doesn't encompass the read and write functions. Thinking I had the concept wrong, I went to Wikipedia, and its example basically confirmed it; they gave the example of a cash register. The presentation tier was the display (the Mesh GUI), data was the sales database (the vertex buffer, metrics, and resource name); the logic tier added it all together for the display. The display is just an output, as saving is. The logic tier would simply provide an accessor for standardized access and, at your option, for writing. You can justify it either by asserting that the GUI and a save file are no different (multiple display tier entities) or by simply calling it allowing a method to merge the extension's data tier into the parent's. Doesn't matter to me anyway, really.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #3 Posted on: January 29, 2011, 11:28:21 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
The MDI definition is accurate... Apparently it stands for Multiple document interface, but really it's just a window house, kinda like how an IDE is just a fancy text editor (because "Integrated Development Environment" is just linguistic masturbation).

As for data storage, it certainly could go in the logic tier, I was just concerned because the functionality tends to get rather large, and can be conceptually separate. In fact, even the graphic demonstrating the register system shows it somewhat separated:
http://en.wikipedia.org/wiki/File:Overview_of_a_three-tier_application_vectorVersion.svg

But you say logic tier, and then you describe the presentation tier o.O
Either way, whatever works, I just want it separate from the backend data, and figured it's usually large enough to keep it separate from anything else. I can kinda envision it as an alternative presentation tier implementation, although the logic tier would be mostly unused for that.
Logged
Offline (Male) Josh @ Dreamland
Reply #4 Posted on: January 29, 2011, 11:44:45 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
I meant you didn't elaborate on "whatever the fuck Java uses..." :P

And where did I say logic then describe presentation? The logic tier adds shit before it makes it to be presented. I was trying to compare screen presentation to output file presentation; literally for presenting data to later instances or to ENIGMA.

That is the very image I as looking at.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #5 Posted on: January 30, 2011, 12:15:29 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
...

Not that I care, but if I have to dissect it, let's start with this:

"The display is just an output, as saving is. The logic tier would simply provide an accessor for standardized access and, at your option, for writing."

Here you compare display to saving, and then mention the logic tier.

"GUI and a save file are no different"
Again comparing GUI to saving. You're making it sound like the presentation tier, but you keep making it sound like it's logic tier.
"I fail to see how the logic tier doesn't encompass the read and write functions"


But again, it doesn't matter whether it's logic or presentation. I was just trying to convey that it's rather large and self-functional, so it probably shouldn't just be dumped in with the other functions.
Logged
Offline (Unknown gender) luiscubal
Reply #6 Posted on: January 30, 2011, 09:05:37 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
Would this be good enough?
Code: [Select]
public abstract class Resource {
    public abstract JComponent createEditor();
    public abstract void save(OutputStream stream);
    public abstract void load(InputStream stream);
}
Logged
Offline (Male) Josh @ Dreamland
Reply #7 Posted on: January 30, 2011, 10:33:55 AM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
I'm saying that the save file and the GUI are both part of the Display tier. The Logic tier is responsible for preparing the data for the display. In Wikipedia's example, it sums it. Here, it'd put it into a Java-ready, file-ready, or C-ready format.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #8 Posted on: January 31, 2011, 12:32:25 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
luiscubal: That's exactly what I don't want, because it immediately lumps everything together without separating the 3-tier architecture.
Logged
Offline (Male) Rusky
Reply #9 Posted on: January 31, 2011, 11:55:06 AM

Resident Troll
Joined: Feb 2008
Posts: 960
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
Another name for that three-tier setup is model-view-controller. There is a difference between saving and the GUI- the format is just the model and doesn't interact with the user. The GUI has to handle user input, modify the resource and in general do all kind of manipulations that are not included in the file saving code in all but the most trivial systems.
Logged
Offline (Female) IsmAvatar
Reply #10 Posted on: January 31, 2011, 03:01:22 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
Code: (Java) [Select]
//P is the properties, essentially solving the data tier. Resource is the Logic tier.
public abstract class Resource<R extends Resource<R,P>, P extends Enum<P>> implements
                Comparable<Resource<R,P>>,PropertyValidator<P>
{
 public abstract R makeInstance(ResourceReference<R> ref);
 protected abstract PropertyMap<P> makePropertyMap();
 public abstract Kind getKind();
 public BufferedImage getDisplayImage() { return null; }
}

//Presentation tier. Becomes visible immediately after instantiation
public abstract class ResourceFrame<R extends Resource<R,P>, P extends Enum<P>> extends MDIFrame {}

Add another abstract class for saving and loading?


This is basically the way LGM is already set up, except that we currently handle all saving/loading in two classes, GmFileWriter and GmFileReader. This means that we'll simply need to split up the file reading/writing into individual resource saving/loading.
« Last Edit: January 31, 2011, 03:09:38 PM by IsmAvatar » Logged
Offline (Male) Josh @ Dreamland
Reply #11 Posted on: January 31, 2011, 03:08:35 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
Works for me.

Do as you see fit, Ism.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Pages: [1]
  Print