16 replies to this topic

[Syynth]

So I know in the upcoming version of Game Maker tentatively titled "GM:Next", I have seen Russel and a few others mention an overhaul to GML will be coming. Additionally, I read that Mark Overmars will still be involved, and that things like D&D won't be going anywhere, but simply getting updated. With that in mind, and also the obvious trend that Game Maker is being marketed towards more serious or professional developers, I was made to think of some other tools I've seen (Adobe Dreamweaver comes to mind). If Objects (which personally I feel could use being renamed what they really are; Classes, but that's more of a preference) had both a 'design view' and a 'code view' option, it would allow for a much more effective workflow from a more serious development perspective, while not taking anything away from new and learning users.

In the 'code view', you would have something very similar to the script editor that is already in GM, but the code structure would look a little different to reflect the change. Now, I am unsure to what extent the language is getting overhauled, but depending on the scope of the changes, this code view could provide benefits ranging from a more familiar environment to programmers coming from other languages to the facilities that would be really necessary for an object oriented language. 'Design view' would then simply be essentially what the Object form is right now, with whatever necessary tweaks will already be coming with the language overhaul.

If only the syntax of the language is getting cleaned up, then this could simply allow the user to define a class with a name matching the object name, and override methods which match event names. I feel even this would be very useful, because if you need to add a variable while coding some functionality in the step event, you'd need only to scroll up a bit to the create event, instead of closing the editor, click the event, and reopening the create event, etc. While this might seem like a relatively petty thing to want to change, it will very likely affect how seriously a lot of developers coming from other languages view Game Maker.

On the other hand, if the language is getting some more advanced features (such as things along the lines of more OO concepts, like associating methods with objects, instead of scripts the way they are now), then this would clearly have the benefit of a very natural way of defining the method within the class. But more than that, if the default features that every Object in Game Maker currently has were put inside a class called GMObject or something similar, then each class the user defines would have a natural way of deciding whether or not to include that functionality in their object. This would allow for the 'cheap' objects asked for in this thread.

Well, what do you think? And do keep in mind, this is for discussing the addition of the code view functionality, not GML language features in general. That said, I would looooooooove for things to work in a more OO fashion, with methods, private/protected variables, polymorphism, etc. (especially because these features would allow for and encourage better design patterns in Game Maker in general; all public data is not what you would call professional )

And lastly, as I see it, the pros and cons of making these changes to Game Maker.
Pros: Improved workflow; more attractive to experience developers; allows GM to be easier to pick up coming from another language; can be implemented regardless of changes to language.
Cons: More work on GM Development team; if few changes are made to GML during the overhaul, could be seen as unnecessary.

And here are some mockups to basically convey the idea.

Spoiler

[Lune]

They way you have it right now would be worse for my workflow. I tend to put rather long codes into various events, so throwing them all into one file would make finding stuff difficult. That would be partially assuaged with code collapsing, which is a good idea anyway, but I'm still not sure how I feel about this.

Also, it looks like you're trying to do too much of what GM does under the hood. Author? Extends GMObject? The point of GM is to make code like that redundant. If you want to do that much work, you're free to use something like C# to make games. Hand-coding the low-level stuff isn't the criteria for being professional.

[Syynth]

They way you have it right now would be worse for my workflow. I tend to put rather long codes into various events, so throwing them all into one file would make finding stuff difficult. That would be partially assuaged with code collapsing, which is a good idea anyway, but I'm still not sure how I feel about this.

Code collapsing would indeed be an excellent addition to the script editor. That said, there's no reason the code view would need to be the default view, and it shouldn't change anything for you if you were to ignore it. But surely you don't fill every object with a thousand lines of code? Wouldn't it be nice if you were just coding a simple button or something like that, to have the option?

Also, it looks like you're trying to do too much of what GM does under the hood. Author? Extends GMObject? The point of GM is to make code like that redundant. If you want to do that much work, you're free to use something like C# to make games. Hand-coding the low-level stuff isn't the criteria for being professional.

Here is where I'm quite confused. I simply added a comment indicating that I was the one who wrote the code, as I do any time I write code anywhere, because I often collaborate with people on various projects, and I feel it is good practice. As for extending GMObject, that was really just demonstrating wishful thinking on my part. Telling your objects which other objects they inherit from is something you do in Game Maker already. All I'm asking for is the ability to have it all in one easy, text-editable place. I'm not asking for access to any low level functionality, nor do I think any really needs to be introduced. What I'm really asking for is a different interface for editting the same information that is more familiar and comfortable for a typical programmer coming from another language.

[Eyas]

If Objects (which personally I feel could use being renamed what they really are; Classes, but that's more of a preference) ...

I'm just going to respond to this portion because I take a slight issue with it, and I think it summarizes my opinion (especially regarding cheap objects, but also regarding this idea in a more general sense).

GM objects are not "just" classes. They are a type of class in the programmatical sense, sure, but they are exactly meant to abstract away all of that. More than being a class, a GM Object is an entity with a sprite that is capable of executing various pieces of code on certain events. An object is just what it sounds, something that is almost physical.. something you can interact with, and handles events. That's why we often see object names such as "controller" or "player" or "block" or "bullet" -- objects are often things, and when they are not, they are invisible "doers", "controllers", and "coordinators", but they always have roles and handle events.

You can use classes in ways that it doesn't make sense to use an object. Many times the "controller" object takes the place of multiple classes in a Java or C# program. Yet sometimes multiple GM objects can be represented by a single class in a Java or C# program that is instantiated differently each time.

To add a code view is not just to appeal to the advanced GM user, but it is also to break a paradigm. And even if it doesn't, it allows over-zealous yet beginner users to completely undermine GameMaker and its paradigm by moving to it too soon.

[Syynth]

Thank you for responding. However, I will have to respectfully disagree with you on a few points.

GM objects are not "just" classes. They are a type of class in the programmatical sense, sure, but they are exactly meant to abstract away all of that. More than being a class, a GM Object is an entity with a sprite that is capable of executing various pieces of code on certain events. An object is just what it sounds, something that is almost physical.. something you can interact with, and handles events. That's why we often see object names such as "controller" or "player" or "block" or "bullet" -- objects are often things, and when they are not, they are invisible "doers", "controllers", and "coordinators", but they always have roles and handle events.

I agree with a lot of this. The way Game Maker characterizes Objects does lend itself to being very understandable to a new audience, and that is wonderful, because it was designed largely as a tool for learning. Where I begin to disagree is your view on the real difference between GM Objects, and a typical class in another programming language. All of your statements regarding Objects are true, but what they seem to imply about classes isn't. A class can (and in other game engines, often do) all of these things.

You can use classes in ways that it doesn't make sense to use an object. Many times the "controller" object takes the place of multiple classes in a Java or C# program. Yet sometimes multiple GM objects can be represented by a single class in a Java or C# program that is instantiated differently each time.

I feel like this crystallizes pretty well where I disagree. It is true that things you can do in a single class in a Java/C#/whatever will take several Objects (to accomplish the given task reasonably), but using classes you can exactly mirror all functionality of Game Maker without going outside the bounds of very traditional, normal class design. I do realize there are differences between Game Maker and other game engines, but those are the result of various design decisions on the part of the engine's designer.

To add a code view is not just to appeal to the advanced GM user, but it is also to break a paradigm.

Now, this is an interesting point. On the one hand, you'll notice if you read my post, the code view could be implemented without making any changes whatsoever to the language. This means none of the paradigms should be broken, because nothing functionally has changed. Really, it would be the same as opening the object.gmx file (if you're using Studio) and working from there, because that's all the code view parser would compile to. On the other hand, I agree that it would encourage a shift in the way Game Maker is used, and it would also encourage a shift in the way the language is designed. I just don't agree that this is a bad thing.

Here's why:
You could implement a game engine in another language that works identically to GM by simply creating a base object with functions representing each of the events GM currently has. Your engine would hold a list of these objects, and update them by calling the appropriate functions at the appropriate time. In fact, this is how pretty much everybody does it. But what would your objects look like? Ultimately, they would have exclusively implementations of the methods in the base class, and would contain exclusively public data. Additionally, 'scripts' would be implemented as global, public functions accessible by all objects, or otherwise as a special method in the base class. If you're familiar with software design in any other languages, none of this should sound particularly appealing. I personally don't feel that this is in any way the sort of programming technique that should be encouraged in an individual planning on learning to take their knowledge elsewhere.

And even if it doesn't, it allows over-zealous yet beginner users to completely undermine GameMaker and its paradigm by moving to it too soon.

Lastly, I will have to say that while it possibly could stumble new users, that is a petty excuse for what could be an extremely valuable asset for the future of Game Maker. It is very clear from the price tag on Game Maker: Studio that this is a tool meant not just for beginners and hobbyists as it has been in the past, but now serious developers as well. I'm sure continuous integration would trip up a lot of new users as well, but that's obviously less important than having the functionality for people who are paying serious money for this product.

I apologize if any of my wording seems harsh, I don't mean any offense, but I believe strongly this would be a wonderful feature for Game Maker in the future. If you feel some of my views held here are incorrect, feel free to point them out. I am always open to discussion
Lastly, I hope you don't take my comments on the design of Game Maker to mean that I dislike it. I love using Game Maker, and I always have, but I feel that the design patterns which have cropped up (at least in my personal experience) are not ones that should be looked upon as great things (in terms of software engineering/design, at least).

[KeeZeeK]

Defining Events like if they are Functions*? This is my dream coming true! A new horizon for the GML developers is incoming...

*- I know that the events are functions, the objects are classes etc.

In my semi-professional indie game developer mind, write "funtcion Step()" is much more soddisfiing then clicking on a button and clicking another to add a step event.

A curiority: is there the possibility that we can make custom "functions" that can be executed, for example, every two steps? :D like the triggered events, but in code :D this is going to be an incredible update for game maker!

[Eyas]

Where I begin to disagree is your view on the real difference between GM Objects, and a typical class in another programming language. All of your statements regarding Objects are true, but what they seem to imply about classes isn't. A class can (and in other game engines, often do) all of these things.
...
I feel like this crystallizes pretty well where I disagree. It is true that things you can do in a single class in a Java/C#/whatever will take several Objects (to accomplish the given task reasonably), but using classes you can exactly mirror all functionality of Game Maker without going outside the bounds of very traditional, normal class design. I do realize there are differences between Game Maker and other game engines, but those are the result of various design decisions on the part of the engine's designer.

Sure, you can use a class exactly as you use an object (an object is a type of a class, after all, if you look at the implementation). But what I'm saying is that there is no 1-to-1 mapping between object and class, i.e. cracking open the existing view and giving access to a code infrastructure allows us access to things that we simply can't do before. We can now add new methods to objects, for example. But what are these methods? Our Java/C# mind tells us that they are just methods that you can execute at any time, but our GM background tells us these methods are 'events'. The resolution to this particular 'problem' is slightly simple; just as we have "user-defined events" that can be triggered at any time, we can have user-defined events with names more creative than user 0, 1, 2, etc. But I think this issue begins to highlight the problem of using GM for something it is not meant for.

Also, this gets us closer to a few other weird cases. For example, in GM, we use the "." symbol to access variables to objects, not events. When the events start looking like methods, will we want change what the "." does? Maybe. Doesn't it make sense? I don't know.

On the other hand, I agree that it would encourage a shift in the way Game Maker is used, and it would also encourage a shift in the way the language is designed. I just don't agree that this is a bad thing.

As someone who appears to be intelligent and experienced with software development in general, it is definitely not a bad thing. I am just careful about saying that GM/GML should inherit everything that is good about other languages, if it lacks it. Don't get me wrong, if this gets implemented I can do a lot with objects that is great.. but it brings me a step closer to realize I might as well have used Java/Python/C#/Unity, and more dangerously it might alienate beginning users.

There is something very particular about GM's roundabout definitions for certain things, it idiosyncratic use of the "." symbol, and the fact that it looks more procedural than object-oriented in some contexts, that made it incredibly easy for me to learn, and eventually learn other languages, and be where I am today. I have a feeling that this might begin to compromise this asset.

[faissialoo]

what I think you are doing is overcomplicating things with the syntax, I like the idea of a code view and design view though, but I think in script editor we should be able to collapse the script, like lune said. but keep the names for things the same, e.g what you wrote was:

//author syynth;
class player extends gmobject
{

@overide
function create()
{//some variables;
}

@overide
function step()
{//do some stuff;
}

@overide
function draw()
{//draw myself;
}
}

I would prefferr:

//author syynth
object=player parent=gmobject
{
event create()
{//some variables;
}

event step()
{//do some stuff;
}

event draw()
{//draw myself;
}
}

[Insert Name Here]

Create a way to edit objects in game maker while testing. The changes will take place in the game. This could also create a "variable list" showing what all non-zero/built in variables are set to.

[KeeZeeK]

I know that this is not the right topic, but... there's a way to see the "code" tab in GM8.0? I know it's not implemented but... big butt... idk what butt xD

[Syynth]

Sure, you can use a class exactly as you use an object (an object is a type of a class, after all, if you look at the implementation). But what I'm saying is that there is no 1-to-1 mapping between object and class, i.e. cracking open the existing view and giving access to a code infrastructure allows us access to things that we simply can't do before. We can now add new methods to objects, for example. But what are these methods? Our Java/C# mind tells us that they are just methods that you can execute at any time, but our GM background tells us these methods are 'events'. The resolution to this particular 'problem' is slightly simple; just as we have "user-defined events" that can be triggered at any time, we can have user-defined events with names more creative than user 0, 1, 2, etc. But I think this issue begins to highlight the problem of using GM for something it is not meant for.

But there really is a 1-to1 mapping. The important thing to remember is, there is nothing that necessitates that the user is able to define extra events that aren't already in Game Maker. Those could simply be flagged as invalid code by the debugger, and won't compile. Ideally I think it would be great if that were possible, but it's really something that's unrelated to code view.

Also, this gets us closer to a few other weird cases. For example, in GM, we use the "." symbol to access variables to objects, not events. When the events start looking like methods, will we want change what the "." does? Maybe. Doesn't it make sense? I don't know.

I would think so. Now do keep in mind, they have already stated they were making an overhaul to the language. Changes like this might be coming even if there is no code view. But in any case, this again isn't something that has to be in order for code view to work as a feature.

As someone who appears to be intelligent and experienced with software development in general, it is definitely not a bad thing. I am just careful about saying that GM/GML should inherit everything that is good about other languages, if it lacks it. Don't get me wrong, if this gets implemented I can do a lot with objects that is great.. but it brings me a step closer to realize I might as well have used Java/Python/C#/Unity, and more dangerously it might alienate beginning users.

But wouldn't it be great to know that with features like this instead, people could be coming to Game Maker instead of Unity? I mean, regardless of the changes there's no way that the current use patterns in Game Maker would have to go away. It only has the possibility to bring Game Maker up compared to those tools. I do see a lot of people viewing those as superior design tools to Game Maker, and some serious language improvements could really be the difference between Game Maker being on the same level as something like Unity as opposed to a stepping stone to bigger and better things.

Also, @KeeZeeK, I'm glad you're excited about the idea; Though I have no idea what you mean about the feature being in GM8. I definitely just used Paint to fake the image

[daspirit]

Although I also do love strict OOP with loads of features as much as the next guy, I think those are a bit too complicated for GM's users. If you wish to use those features, no one is stopping you from using C++ (though you'll lose all those helpful editors from GM which we love a bit more lol).

I was actually thinking that GameMaker should add a Struct folder, which does what it implies (though it could act more of it's C++ sense where it could have functions and objects associated with it). If they add this, then there could also be a Step and Draw code for each room (in addition to the Room Creation code). For the more advanced members, they could replicate GM's objects minus the variables they don't need through Structs and then create these Structs in the Room's code.

I'm not sure if you idea could really work, or how it would really work for that matter. How it will work is my main problem. Your idea could go well with my idea of Structs too (but then the Structs be better in a C# sense, where they only store data).

In my opinion, what we also really need are preprocessors (so we can make some code only work in debug mode and some other cool features such as const and constexpr would be possible), but let's leave that for another topic if anyone is willing to start it. Just saying, add this, and a good deprecation model, and GameMaker is set.

[KeeZeeK]

Also, @KeeZeeK, I'm glad you're excited about the idea; Though I have no idea what you mean about the feature being in GM8. I definitely just used Paint to fake the image

the image... IS A FAKE?!? oh lol Idk what to write/think/elaborate with the CPU/say...

[Syynth]

Although I also do love strict OOP with loads of features as much as the next guy, I think those are a bit too complicated for GM's users. If you wish to use those features, no one is stopping you from using C++ (though you'll lose all those helpful editors from GM which we love a bit more lol).

On the one hand, I think this is sort of the essence of the problem. By changing their product the way they have, GM's users now incorporates a larger audience. Not to mention, I also think it's missing the point to say that I could leave Game Maker and go use another engine. I doubt their intention is to have me spend several hundred dollars on GM:Studio, and then quit using it because storing data is tedious and counter-intuitive. And lastly, might I reiterate;

And do keep in mind, this is for discussing the addition of the code view functionality, not GML language features in general.

If you want my opinion of what they should do to the language, I think GM should adopt an ECMAScript based language, and find a way to make current GML a subset of the more robust scripting language, something similar to AS3 or JavaScript. This would stay very true to the way Game Maker works, which is that you're scripting the Game Maker engine, not programming in a lower level language like C++, and it would also allow for much more effective 'good practice' patterns in design. I think that doing this would allow Game Maker to compete with Unity, which I personally see as it's biggest competition at the moment. It would also allow for experienced flash and web developers to adopt GM, which I think they would be quick to do given it's ability to export to HTML5 as well as mobile platforms. /offtopicrant

Ideally, I would like to get Mike's or Russel's opinion on these matters, since ultimately they're the ones who have the best idea of the feasibility of something like this.

[Desttinghim]

I'm not sure I'm following everything you're saying but I'm imagining it as a preference you set under File->Preferences. I also see the the object editor looking like the script editor. The coding of events would look like this:

solid = true;

create() {
    spd=8;
    hp=10;
}
step() {
    move_towards(obj_player.x,obj_player.y,spd);
}
collision(player) {
    obj_player.hp-=1;
}

Something like that.

[Syynth]

I'm not sure I'm following everything you're saying but I'm imagining it as a preference you set under File->Preferences. I also see the the object editor looking like the script editor. The coding of events would look like this:
<snip>
Something like that.

More or less. I think it would probably be fine as a tab, making it an optional view for editing objects alongside the current interface. I suppose it could be a more permanent style option located in the preferences menu, which may or may not be necessary depending on the changes that are made to the IDE in the future. I for one think it's a pretty neat option, and while GM:Next is a long ways off, it is exciting to think about, and depending on the scope of the changes, it might even be worthwhile to be discussing things like this as early as we are.

[Terrified Virus]

I think this would be amazing. It would make GML more like a real programming language, and would be a hell of a lot easier to use (in my opinion).