Project Mario

[Josh @ Dreamland]

One of my talking points from a long time ago was a plan for the ability to specify additional parameters in objects that can be edited visually through the room editor. These would come in four basic types:

• Point: A coordinate, (x), (x,y), or (x,y,z), visualized with a marker in the room editor.
• Angle: A single angle scalar, visualized by a vector pointing away from the instance.
• Instance: A single instance, which is selected from other instances in the editor, visualized with an arrow leading to that instance.
• Resource: A resource integer, for any resource of a particular kind. Displayed and set in the status dialog on hover.
• Number: A numeric literal given at the user's discretion. Displayed in the status dialog on hover.
  • Selection: An integer chosen from options in a combo-box. Presented in status dialog.
• String: A string literal. Displayed and set in the status dialog or visually on hover.

This allows you to set a number of options in the room editor that you'd otherwise typically do through the instance creation code, in an ugly fashion. The combination of which of those settings you want would be read from some markup file read from each object, which would be used to populate default values and combobox entries. My choice of format would be either YAML or JSON (if contention was high for whatever reason, we could dynamically convert between these at the user's preference).

An example of each category:

• Point: A start and end coordinate for elevators, enemy AIs, etc, etc. Perhaps a "path of zero or more points" option would be in order.
• Angle: A firing angle for turrets or other static AI.
• Instance: A target character or destination teleporter. This is more useful than a point where the target point is on an instance that the developer may move.
• Resource: A path to follow. A sprite to use. An object to fire as ammunition. A timeline to start. I mean, really, the list goes on and on.
• Number: Speed? Difficulty level? Max mana? Exp points? Amount of gold in the chest? Yes.
  • Selection: What kind of enemy is this? What does this entity do when you approach? What... canned effect does it display upon explosion?
• String: Sign text. Finally, you can set sign text without hassle.

The beauty is that the majority of these can be given a toggleable visual representation in the room editor, which could be configured as needed from the markup. Such as a green arrow or a really transparent arrow or whatever. Coupled with my other proposal for an overworld resource, you could lay out all of Super Mario Land trivially. And Metroid II would be simple, too. Their major downfall in simplicity is that an artist actually painstakingly laid out all those tiles by hand, back in the day.

Couple that with the improved build mode and the compile time reflection we've discussed exhaustively, and you can edit your level live with automatic tile generation. The setup time obviously continues to grow for this shit, but the beauty is that you no longer have this effort barrier that makes you not want to work on other levels.

[Josh @ Dreamland]

Missed your post due to pagination mishaps, Harri.

Look at your examples. Everything that took you only X lines of code in GM/ENIGMA/whatever was a built-in feature of the two. Largely because of your code, I'll add and acknowledge, but that doesn't change the point. ENIGMA is conducive to audio manipulation and path plotting. It has bottled code for them with which you are intimately familiar as the author.

Your circuit example is the only thing there that doesn't relate to ENIGMA's central purpose, so of course it took you thousands of lines. It involves recursion and keeping track of what kinds of elements you are rendering. Look at the JDI code that renders ASTs as SVGs—a somewhat similar operation. It's a few hundred lines. Of C++. And its only dependency is the generic SVG elements code: another hundred lines. And that's with me rounding up to the next hundred and including the license. Without that, we're at 335 lines to render an AST to an SVG, all-inclusive. I'll grant that including the headers that lay out the structure of "what is an AST node" brings the line count up significantly, but we still don't reach a single thousand lines.

I wouldn't even attempt that in a classless language.

[Rusky]

TheExDeus: You could always have made your own 2D components in Unity (in a much nicer language than GML), it was just geared toward 3D with the builtins. I could easily pull the same kind of crap on GM by showing a bunch of 3D stuff that you'd have to implement from scratch that Unity has built in. This is unrelated to my point. My point is that once you'd done that (and while you were doing it), Unity would provide much better tools for designing, iterating, and debugging. I don't really care what's possible or even easy to implement the first time, I care how easy it is to model data, visualize, tweak, iterate, etc. GM fails here; ENIGMA has the potential to be a lot better with build mode, Josh's post above, etc.

Some other interesting ideas for property editors would involve animation stuff.

[Ideka]

1) They are destroyed when you change the room by default. You have to make sure to set them all to persistent. PITAA (pain in the ass alert).
2) When set to persistent, they behave as if they were allocated with new/malloc, so you have to manually destroy them when you don't need them anymore. Otherwise you'd be leaking memory. Leaking memory in Game Maker. It's so ridiculous it even sounds funny. PITAA.

So you are arguing that GM destroys objects and frees memory by default and when you don't want it to do so, then it doesn't? Because how and when do you think it should do so?

How it's done is fine, because they are objects. Game objects.
As for classes... how about treat them like every other variable ever? Destroy them when they go out of scope.

Even if we implement structs or classes, they would still be inside objects. And that means you would have the same imaginary problem.

So if you did and I were to do:

Code: [Select]

var a;
a = SomeClass();It would just create an insolvable memory leak? That doesn't sound good.

So yeah, you basically have to wait one fucking step for your "class" to be actually fully instantiated, not to mention take care of all of this boilerplate when creating a new "class". MPITAA (major pain in the ass alert).

I used user defined events for that. You can call them instantly and don't have a 1 step delay.

That's a good idea (though still a PITA), I hadn't thought of that.
You know what would be better though? How about actual classes.

[TheExDeus]

One of my talking points from a long time ago was a plan for the ability to specify additional parameters in objects that can be edited visually through the room editor. These would come in four basic types:

I like that. I do also like that GM:S allows setting basic transformations for sprites in the editor as well. Sadly as LGM is in Java and it's not that great at rendering things, then editors side of the implementation would probably be an ass. And Robert is the only one who would have to probably do that.

Look at your examples. Everything that took you only X lines of code in GM/ENIGMA/whatever was a built-in feature of the two. Largely because of your code, I'll add and acknowledge, but that doesn't change the point. ENIGMA is conducive to audio manipulation and path plotting. It has bottled code for them with which you are intimately familiar as the author.

I will admit the audio part is totally done by 3rd party solutions. But the path thing was totally done in ENIGMA/GM without built-in motion planning functions. We only have A* for path-finding. I needed RDT, Feedback, Vertical Decomposition and other algorithms. I also needed to show them step by step with closed/open sets and so on, and so I had to reimplement A* in pure GML/EDL as well. And even then it took small amount of code. Like RDT implemented even in such "high-level" languages as C# in .net takes several hundred lines of code, while the same implementation in ENIGMA took me only 140 (actually even less than that). My professor was even impressed how easy it is to write all of that in ENIGMA. I have also implemented FastSLAM, Markov Localization, Bug (those are easy everywhere, but not 32 lines of code easy), Hough-transform based map stitching and so on. And none of those took me more than few hundred lines. In any other universal tool/language they would take a lot more (unless the tool wasn't "universal" and was specifically targeted at these things. Like if you use Matlab, then you don't need to implement Kalman filter or anything like that. It's already there).

Your circuit example is the only thing there that doesn't relate to ENIGMA's central purpose, so of course it took you thousands of lines. It involves recursion and keeping track of what kinds of elements you are rendering. Look at the JDI code that renders ASTs as SVGs—a somewhat similar operation. It's a few hundred lines. Of C++. And its only dependency is the generic SVG elements code: another hundred lines. And that's with me rounding up to the next hundred and including the license. Without that, we're at 335 lines to render an AST to an SVG, all-inclusive. I'll grant that including the headers that lay out the structure of "what is an AST node" brings the line count up significantly, but we still don't reach a single thousand lines.

It didn't just let you make an element and then save as SVG. It was a graphical WYSIWYG program. I just did "Export all scripts" in GM and had a total of 5090 lines (about 200 or so hundred are with the GM's "#define script" stuff, but I will ignore that) and 2653 of those lines were to implement all the drawable elements. They could of been external in either svg format or whatever, so it doesn't really count. That leaves 5090-2653 = 2437 lines of code for the actual logic of the program. The objects had in total about 1490 lines (just added up all "Show information" dialogs for objects) and that is total of 3927 lines of code for a tool that renders everything using vectors that can be placed, rotated, colored with text being parsed to allow subscripts, superscripts, greek letters, electrical symbols etc., and can render to transparent png, svg (that also preserves the same text features) with working Ctrl+C, Ctrl+V and Saving/Loading in a custom format. And of course the whole thing is visual as well. Your basic SVG implement was 82 lines, while mine was a total of 296 lines of code, but allowed much more (like transformations), so it would basically be the same.
So I don't see how a program like that could be less than 4k lines in any other programming language or tool. And surely not in C++. I will port it to ENIGMA later and post it EDC or the forum. The only unsupported functions it used was "variable_exists()" in some places.

TheExDeus: You could always have made your own 2D components in Unity (in a much nicer language than GML), it was just geared toward 3D with the builtins. I could easily pull the same kind of crap on GM by showing a bunch of 3D stuff that you'd have to implement from scratch that Unity has built in. This is unrelated to my point. My point is that once you'd done that (and while you were doing it), Unity would provide much better tools for designing, iterating, and debugging. I don't really care what's possible or even easy to implement the first time, I care how easy it is to model data, visualize, tweak, iterate, etc. GM fails here; ENIGMA has the potential to be a lot better with build mode, Josh's post above, etc.

Some other interesting ideas for property editors would involve animation stuff.

I am not of course arguing that GM or ENIGMA can't be improved upon. Of course it can. Especially in debugging. GM:S now has a lot better debugging interface than it had previously. We sadly don't have barely any. I don't agree with that "in a much nicer language than GML" though, as it's subjective (especially which one you meant - JS, C#, Boo?). But here it comes down to what has been discussed to death before - Unity, like many more purpose built engines, have A LOT built-in. The editor has a million tabs for everything. And I have said before (and it's partly what we discuss here) is that GM is "low-level" compared to Unity. And that is why it's for a long time been much more versatile. At the same time even with this "low-level" nature it's have been easy to use and easy to get things done. That is the only thing I have been arguing. I haven't been saying "Unity is shit, don't use it" or "Make next Crysis in GM". I am saying that GM does perfectly what it was meant for (which is 2D) and at the same time it's very good at everything else as well. Which is a lot more than what could be said about other engines.

You know what would be better though? How about actual classes.

Well let's hope with Josh's new parser they can be made. I for example want templates as well, but that is because I made the Matrix extension for ENIGMA which is implemented in C++ classes with templates. Of course I could have implemented it in EDL or GML and I wouldn't have this problem. I am not arguing classes would make GML/EDL worse. It's just that GML/EDL is not necessarily bad without them.

[Rusky]

I'm not talking about the built in features of GM or Unity or anything else. I'm not talking about how "versatile" they are, since Unity is at least as versatile as GM (all those "tabs for everything" are accessible from your own code, so it's strictly better). I'm talking about the interface to whatever features are there, regardless of if they're built in or user-created or whatever.

Unity has a nicer interface for that because it's higher level- you work in terms of reusable components so you can say (whether it's a built in or user-created component) "this object does this and this and this," whereas in GM you have to describe objects in terms of the implementation of those behaviors. In GM terms, you could describe this feature of Unity as something like multiple inheritance, with the ability to pass arguments to the parent.

Visualizing parameters to objects/components like Josh described is another example of being higher level. This does not, in any way, turn it into a less versatile engine. It makes it a more powerful editor because you can iterate faster, describe your intent more directly, etc. GM:S's room editor, build mode, etc. are examples of improvements in this direction.

One issue with GML that limits this kind of thing is the type system. Because everything that's not a string or double is hidden behind an index, the editor and debugger can't do much to help you out- they have no idea of that variable is a number, a ds_list, a sprite, whatever. Because variables are dynamically typed, the editor/language can't catch errors as early (you often have to wait until runtime when it's actually triggered and it's not guaranteed that that will happen even before you release the game). Not only that, but hiding most types behind indices (basically weak typing) means that many of these errors won't even be caught, but rather just cause weird behavior.

This kind of thing is why it's harder to make nice games in GM, and easier in something like Unity. This is why GML is an objectively less powerful language- you can describe the same results, but there are fewer/worse tools to get there (and make sure you actually are where you intend to be).

[TheExDeus]

Visualizing parameters to objects/components like Josh described is another example of being higher level. This does not, in any way, turn it into a less versatile engine. It makes it a more powerful editor because you can iterate faster, describe your intent more directly, etc. GM:S's room editor, build mode, etc. are examples of improvements in this direction.

Maybe it's not less "versatile", but it does make you go into one direction. Like they basically softly force you to make what the tool better supports for making. Same is true with GM, but until recently there was less of this. Like if we add transformation parameters (scale, rotation and so on for sprites) to instances in the room editor, then how would they help me if I want to make a code editor? Looking at that I will feel that this is not the tool for making that editor, while without them I will less forced on this idea. While in reality I can make a code editor in GM just like I can probably do it Unity. Built-in functionality is in no way a bad thing, but at one point it all turns into forced thinking about a tool.

Like if I said "Is UE4 the best tool to create ray-tracer?", "Is Unity the best tool into which to make a sound mixer?", "Is Source engine the best tool in which to make a electrical circuit simulator?", "Is Frostbyte engine the best tool to make a web browser?". For all of these answers are probably no. And it's a no, because they are not meant for that. And so making these things in those tools/engine will take you a lot extra work. While GM also might not be the best tool for these jobs, it is a tool that can do these jobs without much extra work however. Or at least less work than it probably would take in pure C++, C# or whatever. So I feel I might be very unclear on what my original comment (about "limitations") was referring too. Sorry about that. If you still don't feel what I might be on about, then I doubt I can be more clear about the mindset.

One issue with GML that limits this kind of thing is the type system. Because everything that's not a string or double is hidden behind an index, the editor and debugger can't do much to help you out- they have no idea of that variable is a number, a ds_list, a sprite, whatever. Because variables are dynamically typed, the editor/language can't catch errors as early (you often have to wait until runtime when it's actually triggered and it's not guaranteed that that will happen even before you release the game). Not only that, but hiding most types behind indices (basically weak typing) means that many of these errors won't even be caught, but rather just cause weird behavior.

This is true. I also would want a better debugging system where we could give a better feedback on what you are doing wrong. But I think we can do it transparently without asking users to give types to all variables. I believe we could even support structures and classes without breaking existing code. But I am not entirely sure and Josh should have a better input on this. I will post again my previous thoughts on this. Maybe Josh can comment:

Also, would it be worse if we actually returned objects or pointers? Like if "grid = ds_grid_create(10,10);" returned an actual grid object instead of an integer ID? Couldn't we make it work with that and be transparent? Because the only time it would break something is if user actually tried to use an integer as ID, like "ds_grid_set(0,10,10,"Ass");", but that is almost never used and is a bad practice anyway. I do remember some codes from like 2005 where someone actually relied on everything being an integer and doing things like:
Code: [Select]

grid = ds_grid_create(10,10);
ds_grid_create(20,20); //This is grid2 but no way to access it
ds_grid_set(grid+1,15,15,"ass"); //This actually accesses grid2

But as I said. No sane person should be doing this and it's not something we should necessarily support. I guess it was just way to save memory for a few variables (so variable grid2 isn't needed... yey a few bytes).
I think if we started returning real objects, then 99% of the games and examples would still work.

This kind of thing is why it's harder to make nice games in GM, and easier in something like Unity. This is why GML is an objectively less powerful language- you can describe the same results, but there are fewer/worse tools to get there (and make sure you actually are where you intend to be).

Depends on the result you want I guess. My previous "Is TOOL/ENGINE good at THING" should give you the idea what I meant previously.

[Rusky]

Visualization tools for arbitrary parameter types, like points, colors, shapes, paths, resource references, etc. doesn't force you, softly or otherwise, to make anything. For the specific example of transforms in the room editor, it's easier to do level design, but that's the whole point of the tool. I think as long as they're not cookie-cutter style (which the ones we're talking about are not), and especially if you can reuse them, make new ones, apply them to different scenarios, then it makes the editor more powerful and thus versatile rather than less. For example, it would be easier to use Unity to make a sound mixer than GM- the higher level tools let you see the mixer interface you're creating in real time, the visualization tools let you see how things are going to affect each other with graphs, etc. The high level constructs make things more versatile because you're spending less time in the low level details.

As far as the type system, I'm not really talking about statically declared verbose types. One idea that would keep 80% compatibility with GM is just to give all values their own type, but keep everything dynamically typed and scoped. This way the debugger would know what stuff is, more errors would be caught (with descriptive error messages), etc. The next change would be static scoping so you get less runtime "variable doesn't exist" errors, real autocomplete on object members, etc. Finally, using statically-decided types (with type inference and/or picking the type through the GUI so it's not verbose or annoying) would give you nice visualization tools in the runtime, even better autocomplete (because you know the types of variables in the editor), etc.

The point of these changes is not to force or encourage you into a specific way of doing things. It's to give you more direct, immediate access to your end result. This makes the loop between "try something, check if it works, go back and tweak it" much smaller, in many cases reducing it to simply seeing something onscreen in the editor that directly corresponds to the behavior you're describing. This makes it much faster to try things, lets you notice more possible cases you have to handle, and lets you explore possibilities you otherwise may have never even thought of. There's still tons of room for GM to be better at general purpose before it starts specializing more.