ENIGMA Forums

General fluff => Announcements => Topic started by: Goombert on November 05, 2013, 05:44:33 pm

Title: Project Mario
Post by: Goombert on November 05, 2013, 05:44:33 pm
(http://i.imgur.com/4VzwDZ3.jpg)(http://i.imgur.com/QdefsMm.jpg)
I have recently managed to get the Project Mario game I made open source working in ENIGMA. Above are the screenshots of how good I managed to get it.

There are a few anomalies still, zwriteenable causes it not to work in OpenGL3, the start menu's do not render correctly, and there are still collision glitches except now they cause the game to crash.

You can download the latest version from the original topic.
http://enigma-dev.org/forums/index.php?topic=1161

I would appreciate if you guys could download and test this for me to ensure it's working as good as I have got it. You will need to update the engine either by redownloading the Portable ZIP if you are on Windows or updating through git.

It would also help if you guys could modify the settings.cfg configuration file and let me know what the highest FPS you can get is. I get around 150-220fps with a %50 reduction in RAM usage from the Game Maker version which uses 93000 K where ENIGMA uses 40000 K
Title: Re: Project Mario
Post by: fervi on November 05, 2013, 06:02:20 pm
Quote
There are a few anomalies still, zwriteenable causes it not to work in OpenGL3, the start menu's do not render correctly, and there are still collision glitches except now they cause the game to crash.

Time Traveller?

Line 135, position 9 (absolute 7524): Unknown function or script `ini_open'

Fervi
Title: Re: Project Mario
Post by: Goombert on November 05, 2013, 06:03:27 pm
fervi, I am not sure about it compiling for Linux or not as it uses a lot of the Windows specific features from Game Maker 8.1, however, go to Build->Settings and select "Extensions" and enable ini file system, it allows ini file reading/writing on Linux.
Title: Re: Project Mario
Post by: fervi on November 06, 2013, 11:55:31 am
Quote
.eobjs/Linux/Linux/Run/Universal_System/CallbackArrays.o:(.bss+0x0): multiple definition of `enigma_user::keyboard_lastkey'
.eobjs/Linux/Linux/Run/Platforms/xlib/XLIBmain.o:(.bss+0x40): first defined here
.eobjs/Linux/Linux/Run/SHELLmain.o: In function `enigma::OBJ_obj_gamestate::myevent_beginstep()':
SHELLmain.cpp:(.text+0x1e33a): undefined reference to `enigma_user::current_time'
.eobjs/Linux/Linux/Run/SHELLmain.o: In function `enigma::OBJ_obj_gamestate::myevent_gamestart()':
SHELLmain.cpp:(.text+0x2b476): undefined reference to `enigma_user::current_time'
SHELLmain.cpp:(.text+0x2b492): undefined reference to `enigma_user::current_time'
collect2: error: ld returned 1 exit status

Fervi
Title: Re: Project Mario
Post by: Goombert on November 17, 2013, 06:48:00 pm
fervi, ok the first issue was a mistake I made with fixing that constant for Windows I need to commit this, but just apply this fix...
enigma-dev/ENIGMAsystem/SHELL/Platforms/Xlib/XLIBmain.cpp
Line #42, replace it with...
Code: [Select]
  extern int keyboard_lastkey;
And the second issue there is that constant variable not being implemented for XLIB, so just go find it in those objects it says and replace current_time with 1, since my game don't actually use it for anything yet.

Ok, I got the projection functions fixed and the start menu working properly. This was the pull request.
https://github.com/enigma-dev/enigma-dev/pull/524
Title: Re: Project Mario
Post by: time-killer-games on April 01, 2014, 08:29:08 am
Robert, I asked this a while back if I could use your editable to make a precise 3D collision engine based on your code, sorry for the major delay, To give you a heads up, I completed it but lost my modified gmk so I'm just going to do it again. It shouldn't take but roughly two days now, because this time I'm already familiar enough with your code and how it works. I'm un-banned from the GMC, as of recent news, (anyone who's wondering my username over there is 'Samuel Venable' now), so I'll credit you when sharing the engine on both the GMC and YYG Sandbox. :D I'm still very impressed you made precise 3D in GM without any DLL, Ididn't know that was possible until I tested it hands on. Though I'm going to add a means to convert the regular gm models to collision models so people won't have to do it manually, as well as a way to detect collisions directly from code, so the collision models won't have to be stored as an external include file.

So as to why I posted this, how should I credit you? You are still banned from the GMC. I can't link to your profile here because I can't advertise ENIGMA without breaking the rules. Do you have a website or contact email you wouldn't mind sharing? I'd like to include this in the commented credits. :)

Cheers. :)
Title: Re: Project Mario
Post by: TheExDeus on April 01, 2014, 08:52:57 am
Quote
made precise 3D in GM without any DLL
Just FYI 99% of things are possible in GM without DLL's. They might be slow, but possible. That is why I loved GM's idea so much, because I could make anything I ever wanted in it (starting from Diablo2 clones to ray-tracing engines with reflective surfaces) and it wasn't really that hard (compared to much lower level languages). People who think GM is limited think that way only because themselves are limited.

Same of course with ENIGMA.

P.s. 1% you couldn't do is connected to stuff done by OS. Like you can't implement your own window_minimize() function in GML.
Title: Re: Project Mario
Post by: Ideka on April 03, 2014, 08:31:41 am
People who think GM is limited think that way only because themselves are limited.

Same of course with ENIGMA.
Right. But consider:
Quote
[...] I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
(From http://www.paulgraham.com/avg.html.)
Title: Re: Project Mario
Post by: TheExDeus on April 03, 2014, 01:42:10 pm
I wasn't arguing whether language X is better than language Y. I was just saying that "GML/EDL is limited, because just look at the games made in them" argument is wrong. I have personally never encountered many limitations in GM. If I can make a Diablo2 clone, a Bastion clone or any other type of 2D game, then I don't see how they are limited. They have clearly succeeded, as they are 2D game tools. Right now slowly going into 3D.
And I don't believe in this "Power continuum", because never language X is totally better than language Y. Every language has it's own uses. I now program in C++ daily and while it might be higher in the "power continuum", it is still not my number one language when I need to make a 2D graphical program. Actually I might never make a 2D game or a program in anything else than ENIGMA.
Also, "feature" doesn't mean "better". Python has a lot of features and is higher level than C++, yet I dislike that language to the bone. It's not better in anything. Except maybe in eduction just because it's easier. But then again you could just use GML/EDL for that.
Title: Re: Project Mario
Post by: Rusky on April 03, 2014, 05:00:33 pm
I don't think it's wrong to say GM's design makes it easier than some other designs to make sloppy games. Obviously it doesn't force it or even make it too hard to avoid, but neither is it anywhere near the best possible design.
Title: Re: Project Mario
Post by: Goombert on April 03, 2014, 05:10:55 pm
I agree more with what Harri told me the one other time, that GM provided a basic abstraction framework that allowed more advanced things to be done through extensions. GM served as a good windowing and basic platform that could be easily extended. That I found to be a good argument, sadly it's no longer true about GM.
Title: Re: Project Mario
Post by: Ideka on April 03, 2014, 06:13:08 pm
I wasn't arguing whether language X is better than language Y.
Good. Me neither.
I was just saying that "GML/EDL is limited, because just look at the games made in them" argument is wrong.
I agree.
And I don't believe in this "Power continuum", because never language X is totally better than language Y. Every language has it's own uses. I now program in C++ daily and while it might be higher in the "power continuum", it is still not my number one language when I need to make a 2D graphical program. Actually I might never make a 2D game or a program in anything else than ENIGMA.
Also, "feature" doesn't mean "better". Python has a lot of features and is higher level than C++, yet I dislike that language to the bone. It's not better in anything. Except maybe in eduction just because it's easier. But then again you could just use GML/EDL for that.
From the same essay:
Quote
Or how about Perl 4? Between Perl 4 and Perl 5, lexical closures got added to the language. Most Perl hackers would agree that Perl 5 is more powerful than Perl 4. But once you've admitted that, you've admitted that one high level language can be more powerful than another. And it follows inexorably that, except in special cases, you ought to use the most powerful you can get.
Paul Grahm really knows his shit, and I think he makes a good argument (the whole thing is worth a read, btw).
When you say that "every language has it's own uses" (sic.), you're probably thinking about things like "Java is good for multi-platform because the .jar is platform-independent", "C++ is good for performance-critical stuff because it's fast" or "GML is good for game development because it has a whole environment (GM) dedicated to it". Forget about all of that. These are all properties not of the languages, but of their most popular or only implementations. I'm talking about languages on their own.

Anyway my point was that even though you can get pretty much anything done in GM, its language is rather limited, as you should clearly be able to see, being a C++ programmer yourself.
I have personally never encountered many limitations in GM. If I can make a Diablo2 clone, a Bastion clone or any other type of 2D game, then I don't see how they are limited. They have clearly succeeded, as they are 2D game tools. Right now slowly going into 3D.
Well, you could probably do that with any turing complete language. You could do it in assembly if you really wanted.
Title: Re: Project Mario
Post by: time-killer-games on April 03, 2014, 06:45:53 pm
Oh no, we're getting off topic again
(http://curezone.com/upload/Parasites/Strange_Poop.jpg)
Title: Re: Project Mario
Post by: Rusky on April 03, 2014, 07:13:14 pm
The problem with PG's essay, although his points about relative power of languages and "blub programming" are good, is that he then concludes that Lisp is the most powerful, which is basically him walking right into his own blub programmer description. Lisp is his blub. :P
Title: Re: Project Mario
Post by: TheExDeus on April 03, 2014, 07:15:57 pm
Quote
I don't think it's wrong to say GM's design makes it easier than some other designs to make sloppy games. Obviously it doesn't force it or even make it too hard to avoid, but neither is it anywhere near the best possible design.
Any engine that is easy to use will allow sloppy games. You can create a window and draw sprite using few lines in Python as well (including the right libraries of course) and that usually ends up as crappy pac-man's as well. I don't think GM's design is the reason there are sloppy games (as in GM's design is bad or limited), but I think it's because of it's simplicity. If you write in C++ 95% of new people trying to make a game will fail to draw a triangle (especially in GL3 and above). Even if they use ready made graphics engines it's often very hard to do in C++. In that case people will give up before they can even make a sloppy game.

Quote
I agree more with what Harri told me the one other time, that GM provided a basic abstraction framework that allowed more advanced things to be done through extensions.
Yeah, and with that I also meant to show that high-level/low-level thing going on with GM's design (and specifically GML). It's easy to make what you want, but you actually have to make it yourself. Like all the engines I have ever touched are either in two groups - very high-level - implements everything you would ever need, their own AI, specific scripting, function for drawing GUI's that are different from functions drawing on textures etc. And the other ones are very low-level - if you want to draw text, then create a texture, load the file, specify texture coordinates, draw the quad, maybe even write a shader to draw that quad etc. GM somehow managed to be in between both of those and I always admired that. I am yet to find an engine that allows me to write text on screen using one line of code (without any other lines) and the same time make my own 3D ray-tracing engine. Like try making a ray-tracing engine inside UE4 without recoding their whole source.

Quote
Anyway my point was that even though you can get pretty much anything done in GM, its language is rather limited, as you should clearly be able to see, being a C++ programmer yourself.
I truly don't see that. I don't find "different" to be the same as "limiting".

Quote
You could do it in assembly if you really wanted.
True. You could do it even writing only 1 instruction for a million times (on a one instruction set computer http://en.wikipedia.org/wiki/One_instruction_set_computer).
Title: Re: Project Mario
Post by: Ideka on April 03, 2014, 08:10:24 pm
Quote
Anyway my point was that even though you can get pretty much anything done in GM, its language is rather limited, as you should clearly be able to see, being a C++ programmer yourself.
I truly don't see that.
Really? So you never found yourself missing, say, classes, when programming in GML? Or static-typing? Or exceptions? Or how about some sequence type that you can actually pass around without having to bother to clean up after you don't need it?
Wouldn't you at least agree that, if GML had these features, you could get more done in less time, structure your programs more efficiently and/or write more robust and understandable code with it?

Quote
You could do it in assembly if you really wanted.
True. You could do it even writing only 1 instruction for a million times (on a one instruction set computer http://en.wikipedia.org/wiki/One_instruction_set_computer).
Right. So either you're going to argue that assembly isn't limited (even if it lacks such things as, say, variables and functions), or your "GM isn't limited, I could use it to remake Bastion" argument is invalidated.
Title: Re: Project Mario
Post by: Darkstar2 on April 03, 2014, 09:23:12 pm
Wow nice debate :D  Off topic indeed, but I read something and feel I should step in and add my 2 cents. :P

First, I think saying that the simplicity of GM and the likes are reasons why there are more sloppy games is not entirely true in my opinion.  Sure, like there will be more of them made with a fast engine than a sloppy game written in several tens and thousands lines of C++ :D

The reason for sloppy ass games in GM is not really due to its simplicity and speed really, who said GM was simple? It can be as complex as you want it.  There are some very advanced stuff you can do with GML and most people don't even use a fraction of its capacity. 

That said, I think the biggest reason people make sloppy games is lack of skill.  Skill goes far beyond the coding part but the  content.

You can be a good coder, but if you lack creativity and all the areas that make a good game you are useless.   If you can't draw sprites, design graphics, build your own unique content to your game, then you are stuck ripping other people's gfx or using stuff you find online or copying the same fucking clones of games.  Some people lack the skill and resources to make good content for a game and/or don't have the necessary software or know that there are many free  software out there,but still without skill you go nowhere.

So you can give anybody the fastest engine and easiest to learn language, if the person does not have the skill and foundation, forget it.  You can have all the materials but if you don't have the right designer and planner you go nowhere and at that point you just do some random shit.

Here's an example of such concept.....

FPS Creator.  How more easier can you get in making your own 3D FPS right ? just clicking prefabs and building levels........Or 3D GameMaker, another
ready made pre-fab game creation just click and build type.  Well people still make shitty games with those even though not a single line of code is necessary, again, going back to the same arguments as above, lack of skill.

True that YYS has some limitations and they removed raped some windows function and some of the stuff they do is sloppy at best, BUT.....with people the right skill/talents they could make really good games, mind you not optimal performance/speed, and there are limits, but still people could do far FAR better with GM than the utter shit that it's currently made.

So provide someone with an engine and full turn key approach to game making, they still will not be able to making anything half decent without skill.

Same for someone starting from scratch using coding.

And BTW, using the slower approach has not stopped people from making really REALLY bad games, proof is all out there.....and there are bucket full of games that are really shit that were not made with GM or any similar game engine :D

Just thought I'd add my 2 cents :P

Title: Re: Project Mario
Post by: TheExDeus on April 04, 2014, 10:32:06 am
Quote
So you never found yourself missing, say, classes, when programming in GML?
Not at all. Objects are classes in GM/ENIGMA. They at least fulfill most of the requirements classes are used for.
Quote
Or static-typing?
Dynamic types aren't really bad. GM had a great system for detecting undeclared variables anyway and it worked like a charm. But this wholly is the programmer preference. And it sure as heck doesn't make the code smaller as you actually have to type more in static-typing. It doesn't make a language limited in any way. Just different.
Quote
Or exceptions?
Never been a big fan of exceptions. I almost never use them in C++ either. And GM just doesn't require them. Like how exactly this makes a language better:
Code: [Select]
  ifstream file;
  file.exceptions ( ifstream::failbit | ifstream::badbit );
  try {
    file.open ("test.txt");
    while (!file.eof()) file.get();
  }
  catch (ifstream::failure e) {
    cout << "Exception opening/reading file";
  }
Than this?:
Code: [Select]
file = file_text_open_read("test.txt");
if (file == -1){
  show_error("Cannot load the file!",false);
}
while (!file_text_eof(file)) { file_text_readln(file); }
file_text_close(file);
It's actually easier to understand the GML version than the C++ one. And even in C++ I never use extensions, because, for example, file.good() returns whether you successfully opened it. So GM's lack of exceptions is also not a limitation. It's just a different.
Quote
Or how about some sequence type that you can actually pass around without having to bother to clean up after you don't need it?
You mean std::containers? I guess the fact that we don't have reference counters or out of scope garbage collection is a limitation. But it's not necessarily a language problem, but the implementation problem. This is harder to do because scopes are not as strictly defined as in C++. But this is the only of your examples were I agree it could be done better and could be considered a limitation. Garbage collection is a little problem with GM/ENIGMA.

Quote
Wouldn't you at least agree that, if GML had these features, you could get more done in less time, structure your programs more efficiently and/or write more robust and understandable code with it?
By the examples I given no, I don't think those features would make GML any better (except for reference counting). But EDL does support (or plan to at least) some of the features together with GML. So you can give types if you want (that doesn't make it statically-typed of course). You can technically make classes and structs as well (but I think they currently don't work because of parser bugs). But using the features won't make your code smaller (it will probably make it bigger) or more understandable. They might make the code more efficient of course, but that is not a limitation of the language, but the parser/compiler. GCC wasn't built to compile parsed EDL into super optimized exe.

Quote
Right. So either you're going to argue that assembly isn't limited (even if it lacks such things as, say, variables and functions), or your "GM isn't limited, I could use it to remake Bastion" argument is invalidated.
I don't argue that. It's just that you took assembly as an example and I made a step further. It's not really relevant to the discussion.
Title: Re: Project Mario
Post by: Ideka on April 04, 2014, 12:58:24 pm
Don't tell me GM objects are the same as classes. They're not. You can make them work as classes, sort of, but it's a pain in the ass.
I didn't say dynamic typing was bad. But don't you think it'd be good if you could specify something like "this function should always take one int" and then the compiler telling you if you ever call it wrongly? Don't you think that might help you find and squash some (potentially subtle) bugs?
Exceptions carry more information than a -1 return value. An exception might be able to tell you not only that the file wasn't loaded properly, but also why. Also if your examples were inside a function, you could catch the error from outside with exceptions.
Quote
You mean std::containers?
Maybe. Not necessarily.
You can make your own containers in C++ because C++ has -guess what- classes. Actual classes.
Quote
I don't argue that. It's just that you took assembly as an example and I made a step further. It's not really relevant to the discussion.
So you accept that if GM isn't limited, is not because you can use it to remake Bastion. Otherwise you'd be making no sense.
Title: Re: Project Mario
Post by: TheExDeus on April 04, 2014, 02:13:34 pm
Quote
I didn't say dynamic typing was bad. But don't you think it'd be good if you could specify something like "this function should always take one int" and then the compiler telling you if you ever call it wrongly? Don't you think that might help you find and squash some (potentially subtle) bugs?
It might, but it would also mean I need to have several functions for several data types (or templates in C++). But if you use templates, then it wouldn't trow an error when you tried to pass one 'string' instead even though you only want it to take double, int, long etc. So saying "function takes one int" wouldn't make it necessarily better. You get some, you lose some. And so the way GM does it isn't a limitation.. it's just a different (I get a feeling I have to say it too much in this topic).

Quote
Don't tell me GM objects are the same as classes. They're not. You can make them work as classes, sort of, but it's a pain in the ass.
For what kind of things wouldn't it work correctly? There are subtle differences, but they are essentially classes. You have constructor, destructor, parenting, overloading (when using parenting), they have data in them, functions in them (thou in this case it would be "User defined event", as "functions" are "scripts" in GM and they are not tied to objects). The biggest difference really are that in C++ classes you have member functions, while in GM you cannot have them inside the object and you need to use "User defined event" to simulate them. That is actually a downside I think we should fix. Basically allow having script like resource inside the object. It would probably be creatable as a custom event (Robert you think it might be feasible?).

Quote
You can make your own containers in C++ because C++ has -guess what- classes. Actual classes.
If you used an object as the container, then it would be a lot more trivial to implement garbage collection.

Quote
So you accept that if GM isn't limited, is not because you can use it to remake Bastion. Otherwise you'd be making no sense.
Bastion was just the example. Because originally this wasn't about the specific of GML. It was the specifics of GM and how people create crappy games with it just because its "limited". I pointed out that it is not because GM is limited. It's because GM is just easy to use.

To expand on my point about "limits" is the FPS creator Darkstart mentioned. There are also RPG creator and so on. THEY are limited. They are limited because they allow you to do make basically only 1 type of game. Even if they have some kind of scripting language (like RPG creator) even then ALL of the games made in it will look and play basically the same. And I just wanted to differentiate between GM (which doesn't have these limits) and these creators, which have.
Title: Re: Project Mario
Post by: Ideka on April 04, 2014, 03:09:39 pm
OK, here's why using objects as classes is a pain in the ass:
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.
3) They have a bunch of variables by default that are probably useless to you but can't be disabled. Some of them you have to be careful not to use because they may have undesirable effects when modified (like hspeed affecting the x variable). PITAA.
4) You can't pass arguments to its "create" function. Instead you have to do some BS like:
Code: [Select]
with (instance_create(0, 0, SomeObject)) {  // (Don't forget the required x and y parameters that you probably don't need but have to specify anyway.)
    some_variable = 3;
}
And then if you actually want to use these values, you can't do it in the create event because it's executed before the content of the with. So you have to do some OTHER BS in step like:
Code: [Select]
if (!variable_local_defined("recieved_parameters")) {
    do_something_with(some_variable);
    recieved_parameters = true;
}
And I'm actually not even sure if that works (and it definitely doesn't work in ENIGMA), I usually add this in create:
Code: [Select]
alarm[0] = 1;And then in the alarm 0:
Code: [Select]
do_something_with(some_variable);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).
5) No member functions. Sure, you can use scripts and call them like in C but... PITAA.
6) No multiple inheritance. Not really a PITA but a limitation nonetheless.

Quote
Bastion was just the example. Because originally this wasn't about the specific of GML. It was the specifics of GM and how people create crappy games with it just because its "limited". I pointed out that it is not because GM is limited. It's because GM is just easy to use.
I agree with that. I'm talking about a different kind of limitation here.
Title: Re: Project Mario
Post by: Josh @ Dreamland on April 04, 2014, 04:07:04 pm
Data structures are important, but Game Maker does offer a C-Like interface to them. Yes, it uglies up the code, but what HaRRi is arguing is that it isn't a limitation in the strictest sense.

I consider the missing structures to be GML's greatest downfall. With those, a user could work around GM's other major flaws, including my personal pet peeves:
1) The inability to name script parameters. This encourages documentation in the ugliest way possible, but otherwise damages code readability.
2) The unavailability of virtual methods in classes. Game Maker offers user events, but these also cannot be named, and there is a strict limit of 16. Emphasis: limit.
3) The lack of proper encapsulation. This only really aggravates me when creating a data structure gives you a sequential integer that must be freed when you are done. We can't do anything to make your life easier; we have all the same problems as C for new users. Close your files, or you'll run out of file handles. Delete your data structures, or you'll run out of memory. If we had data structures as objects, they'd be freed when they left scope.
4) The lack of a well-defined passing convention. Want to pass an array? Create a list structure, pass the ID. See problem list in (3).
5) The inability to hold non-integer objects, thereby constraining the number of object types you can offer–creating them is a pain in the ass.

If you don't miss structs, Harri, then my guess is that A* is the most complicated algorithm you've ever written in GML. Because if you had to store more than three values for any given node or grid cell, you'd quickly go insane. Three values in a grid requires three grids. N values in a grid requires N grids. Each value requires a call to ds_grid_*, which is bulky and ugly. Enter map. Now it's also slow.

If we wanted an iterator for them, we could have ds_map_iterator_*, so that you could construct iterators and work with them by integer. But now we need an array of iterators. What a joke. This puts burden on developers, so it doesn't happen, which puts burden on users, because now their code is slow because it's doing N log M operations for N variables in M objects. This is on top of the already obnoxious overhead for accessing a variable.

This also further exacerbates problem (3). Your iterators wouldn't have an owner, and so you'd need to explicitly denote you are finished with an iterator so the system can destruct it. Now your code is illegibly hideous; ISO C++ is officially prettier than your "high-level" GML.


The rate at which your code blows up is a good metric for whether there are limitations. A rope ladder leading to the moon does not, in itself, remove a limitation. Yes, you could climb to the moon, but the resources required would be insurmountable. Yes, you COULD write a compiler in GML. But I'd advise you to instead do something more fun and productive, like cutting off your limbs in one-inch increments. Even if you managed, it'd run like shit. Even if you compiled it with ENIGMA. Why? Because your code is bad. Even if you can't see it. Being low-level in nature (ie, being a pain in the ass to use), does not imply you will have faster code. Allocating and freeing iterators yourself through those functions would make the code slower, anyway, because now we need to dereference more than just the current frame to figure out where your iterator is to dereference it and figure out where your data is.


And that concludes my rant, for now.
Title: Re: Project Mario
Post by: Rusky on April 04, 2014, 04:11:27 pm
GM has crappy games because it's easy to use... and harder than necessary to make good games with. This is the limitation that matters. There are new tools (and alternate conceptions of existing ones) that other game engines have or could have that GM does not, that make it easier to focus on the game design and polish and spend less time on bookwork. GM is actually relatively low-level as far as describing game behavior goes.
Title: Re: Project Mario
Post by: Josh @ Dreamland on April 04, 2014, 04:19:34 pm
The things you are suggesting should be high-level would remove the "programming a game" aspect of programming a game. We could go the stencyl route and include be_a_green_koopa(), be_a_red_koopa(), be_a_block(), be_mario(), be_link(), and fly_around_in_circles(), and then, of course, include a UI to pick which of those you want to call as tiles. But I have this crawling feeling you'd quickly notice a shift in the sorts of games made in ENIGMA. Yes, they'd all behave well; yes, it'd be easy to develop games; and yes, we could easily predict all behavior for purposes of, eg, rewinding time. But somehow, I think interest in the project as a development platform would actually dwindle.
Title: Re: Project Mario
Post by: Rusky on April 04, 2014, 04:28:07 pm
I was thinking more along the lines of Unity...
Title: Re: Project Mario
Post by: Josh @ Dreamland on April 04, 2014, 05:05:06 pm
I find Unity has too much emphasis on certain game features, too; the most obvious being that everything's 3D. In a game design class I took as an elective, other teams used Unity (my team was the only one that did not). We were the only team with a 2D menu, not because we did less work, but because making a 2D menu in Unity was more work for the other teams. Multiple groups mentioned this specifically. They might have just been dumb—one of those teams was trying to draw a targeting reticle as a 3D sprite and doing (lots of poor-quality) math to figure out how to make it appear the right size on screen.

But anyway, if you have a specific example that doesn't over-constrain the sort of games ENIGMA can make, I'm interested in hearing it.
Title: Re: Project Mario
Post by: Rusky on April 04, 2014, 05:17:31 pm
Unity just happens to have been built for 3D, and they only recently tacked on 2D. The features I'm talking about apply equally to 2D and 3D games.

I'm thinking in particular about components/multiple inheritance/whatever you want to call that system for better reuse of entity behavior, along with the editor interface that goes with it- nice visualizations, build mode, rewinding, etc.

Some of these are simple to add to ENIGMA without changing the GM-like base, such as build mode, and some are not.
Title: Re: Project Mario
Post by: Josh @ Dreamland on April 04, 2014, 07:49:20 pm
Build mode, as in the context of the original ENIGMA build mode?

Behavior components are simple enough to add. But be careful how you refer to them. In EDL, we're dealing with two types of objects. The more obvious type is the "Objects" we inherit from GML, which all inherit from a base object that has eleventy godzillion locals, and is entirely event-driven.

For these, I was originally going to do so through multiple inheritance, but since everyone seems to like that ridiculous [snip=GML]event_inherited()[/snip] nonsense, doing so isn't straightforward. We can't really maintain a complete dichotomy between behaviors and object inheritance, because if two behaviors require an object to have mana, we want them to be able to pool mana, while if two behaviors require ammo, we want them to safely utilize separate ammo. If these behaviors were separate, an object would still need to have multiple parents in order to inherit these shared fields from multiple parents, anyway.

This does, of course, assume you would want to use behaviors for available weapons, which is fine by me as I am a fan of the concept of interfaces. It makes sense to do this, anyway, as you will want [snip=GML]with (obj_some_type)[/snip] to affect all objects inheriting behavior from obj_some_type, which makes much more sense of they're actually objects.


The second kind of object we work with is exclusive to EDL, and in fact, exclusive to the flavor of EDL for which I wrote the first half of a parser before my final year of college picked up. The new parser supports structures, which will support functions (I hadn't finished ENIGMA's function syntax before I got involved in the whole "Graduating" thing). These will support inheritance and virtual functions. While I had not considered it, ENIGMA already supports using C++ classes as Object components: It's how extensions currently work. It wouldn't be hard to allow doing the same with ENIGMA structures, if there'd be any point to it. For instance, if one of these were intimate with obj_mage, or whatever, it could be used as a magic weapon interface, and its children could be stored in an array of current weapons or assigned to different attack buttons. This would allow the child Object to have more control over how its behaviors are used, as well (the object has a weapon and assigns it to 'X' instead of inheriting a weapon that is fired with 'X'). As usual, it comes down to the "has a" vs "is a" problem, so offering both options would certainly help with that.


Now that I'm done ranting on that for the umpteenth time, I fail to see how that is a "high level" design concept, except by virtue of being higher than C. GM already has some high-level functionality. If you want a dumb-ass, dumpy, "high-level" approach to shit, use [snip=GML]my_object.behaviors += script_get_text(scr_my_behavior);[/snip]; then in the step event, [snip=GML]execute_string(behaviors);[/snip]. Done.
Title: Re: Project Mario
Post by: Rusky on April 04, 2014, 08:35:16 pm
I should be clear that my claims were about GM, not necessarily ENIGMA, which (as with the example of build mode) has plenty of room for improvement without (and with) breaking GM compatibility, although there are still probably a few things that would be nice but make it fundamentally different from GM.

The "high level" nature of these improvements is more to do with the editor interface and its static knowledge of the object's implementation than the capability of the API. Unity's property editors for component parameters, for example, supports a lot of visualization that GM (or for that matter ENIGMA) is nowhere near. Build mode is entirely an interface thing- it doesn't add any ways to organize the game itself.

"High level" here means things like direct manipulation and immediate results, not really anything to do with language constructs per se.
Title: Re: Project Mario
Post by: TheExDeus on April 05, 2014, 08:26:16 am
Quote
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? Rooms are the biggest scope (besides global) GM has. If you want something to go out of Room, then it is the same as declaring everything in global scope in C++... it will never be deleted until the program ends. So I really don't see how this is a problem. Even if we implement structs or classes, they would still be inside objects. And that means you would have the same imaginary problem.
Quote
3) They have a bunch of variables by default that are probably useless to you but can't be disabled. Some of them you have to be careful not to use because they may have undesirable effects when modified (like hspeed affecting the x variable). PITAA.
They wouldn't have any effects if you didn't use them. Like it doesn't matter what x/y position the object has or if its going left in 1000pixels/step. If you don't use them, it won't change anything. And the useless variables do take a bunch of bytes which otherwise could be free. I actually once (years ago) mentioned that to Josh and how we could make the default variables optional. Like maybe create a default variable manager in LGM and you could change for each object whether you want to use that variable or not. It should technically be possible to implement with just some #ifdef's in the code. There would be some problems when disabling x,y and then trying to draw default sprite. But that all of that could be checked in LGM's side.

Quote
If you don't miss structs, Harri, then my guess is that A* is the most complicated algorithm you've ever written in GML. Because if you had to store more than three values for any given node or grid cell, you'd quickly go insane. Three values in a grid requires three grids. N values in a grid requires N grids. Each value requires a call to ds_grid_*, which is bulky and ugly. Enter map. Now it's also slow.
Why do you need a grid for every value? I have implemented A* even in pure GML and I just did this:
Code: [Select]
grid = ds_grid_create(500,500);
for (i=0; i<ds_grid_width(grid); ++i){
  for (c=0; c<ds_grid_height(grid); ++c){
    ds_grid_set(grid,i,c,ds_grid_create(1,4));
  }
}
And now every node has 4 values. I could change that 4 to 1000 and that node would have a 1000 values. This is how I made all my "widget classes" in GM and ENIGMA. I have, for example, "scr_init_buttons()" which creates the larger grid (size of 0 at start) holding all buttons (as it is local, then I can have different buttons for different objects) and then I have "scr_button_add(x,y,"Text",enabled,toggleable,...etc);" which resizes the grid to add a button and in the second dimension add all the values. And then in draw I have "scr_buttons_draw()" which also take care of all the logic. Usually I created a "scr_button_execute()" which had a "switch(name)" in it that would add behavior to a button when pressed, but I could also just add a script callback to the scr_button_add as in scr_button_add(x,y,"Text",scr_to_execute_when_pressed) and then use execute_script(). So I essentially made a struct with not only values (data), but also functions. And it didn't take much more time than it would take to make it with structs or classes (maybe even less). Technically I could ditch grids and just use 2D array for that and it would be a little faster.

Quote
4) The lack of a well-defined passing convention. Want to pass an array? Create a list structure, pass the ID. See problem list in (3).
GM:S actually allows you to pass and return arrays from scripts. They even allow deleting arrays now, by just "= 0". So they have a way to differentiate. They even have it set up that the array is passed by reference if the array is not modified in the script, so it works a lot faster. Read more here: http://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/401_06_arrays.html
These functions also use arrays by reference: http://help.yoyogames.com/entries/28707818-Matrix-Functions
I personally think there should be a method to implement everything you want from C++ in ENIGMA, because the only difference is that everything has an integer ID instead of an address and a pointer. So even things like out-of-scope automatic deleting should be possible.
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.

Also, the GM way of returning an integer is actually like returning a reference. Because "b = grid;" wouldn't ever copy a grid, it would give b the same grid and thus be faster. That is why passing everything by reference actually makes calling scripts faster than it would be otherwise.

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

Quote
Unity just happens to have been built for 3D, and they only recently tacked on 2D.
But that is actually my point. If rendering 2D sprite correctly required changes by Unity DEV's, then clearly something is very limited. GM and now ENIGMA on the other hand allows you to code whatever you want. And that sadly creates feature and performance problems. Like we could also add shit-ton-of-stuff that allows you to make really cool looking 3D games just like Unity or UE4, but then you wouldn't be able to make ray-tracer or robot planner. Just like you cannot really make anything like that in Unity or UE4. You must choose - limited to certain things (like 3D), but do it really good - or - unlimited, but slower and harder. And while GM leans towards the latter I personally think it's the only tool which at least made a partial merge between the two. Because 2D games ARE EASY in GM. Any 2D game ever.

edit: Like would Unity or UE allow me make this:
(https://dl.dropboxusercontent.com/u/21117924/images/circuit_draw.png)
or
(https://dl.dropboxusercontent.com/u/21117924/Robotu%20Planosana/RDT.png)
or
(https://dl.dropboxusercontent.com/u/21117924/Mixer/mixer.png)
in the same tool with all projects taking from 100 to 1000 lines of code? Okay, the circuit drawer was several thousand, but that's mostly because the elements were hard coded and I didn't make an external format to load them. Otherwise it was also like 2-4k max.
Also, I didn't add any 3D stuff because I just haven't made much 3D in GM. The reason I showed them was not to make a point about 2D or 3D capabilities, but just to show that all 3 of those examples are totally different in every way. One is a sound mixer, another a tool to draw circuits (both with latex style text syntax and output to .svg files) and the other is a planner for robots. They are not "3D FPS shooter", "3D 3rd person shooter", "3D side scrolling shooter" and so on which are basically everything you make when using ready made 3D engines. Like the circuit drawer would probably be impossible or at least very impractical even when using 2D engines.
Title: Re: Project Mario
Post by: Josh @ Dreamland on April 05, 2014, 10:23:18 am
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:
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:
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.
Title: Re: Project Mario
Post by: Josh @ Dreamland on April 05, 2014, 10:32:53 am
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 (https://github.com/enigma-dev/enigma-dev/blob/master/CompilerSource/JDI/src/API/AST_Export.cpp)—a somewhat similar operation. It's a few hundred lines. Of C++. And its only dependency is the generic SVG elements code (https://github.com/enigma-dev/enigma-dev/blob/master/CompilerSource/JDI/src/General/svg_simple.cpp): 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.
Title: Re: Project Mario
Post by: Rusky on April 05, 2014, 11:59:05 am
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.
Title: Re: Project Mario
Post by: Ideka on April 05, 2014, 12:08:54 pm
Quote
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.

Quote
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.
Title: Re: Project Mario
Post by: TheExDeus on April 06, 2014, 11:15:27 am
Quote
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.

Quote
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).

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

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

Quote
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.
Title: Re: Project Mario
Post by: Rusky on April 06, 2014, 01:13:50 pm
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).
Title: Re: Project Mario
Post by: TheExDeus on April 06, 2014, 05:27:45 pm
Quote
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.

Quote
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:
Quote
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.

Quote
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.
Title: Re: Project Mario
Post by: Rusky on April 06, 2014, 11:13:51 pm
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.