133 replies to this topic

[Schyler]

I honestly greatly disagree with this: in any professional game you see the interface is always made specifically to match the game. - Independent of the OS! Using the OS interface style would make a game look like an office application.

If you want your own Dialogs, you write your own dialog engine to draw the frame, then add the text. Professional games dont use ones that pop outside the game anyway - they are usually integrated into the foreground.

Native dialogs would instantly make GM much more professional, and it would also free up some (more) runner space because YoYo could remove the existing dialog style commands that people rarely use.

Edit: IPB Really dosn't like this post. Constantly deletes half the stuff I write. Maybe there's a bull**** filter.

Well have you ever tried creating your own dialog (input fields for example) system?

It's a hell. & slow

Not at all - It's easy to do.

And by using native dialog windows, we won't be scrapping input boxes. Both Mac and Windows support input box dialogs without too much fuss. They'll just look more system-specific - something the player is used to seeing.

[makerofthegames]

Timelines - I personally never use them. It also frees up some computation per object, because of all the timeline related variables that are automatically created and checked each step.
...
Triggers - I can see this being a performance hit somewhere in the runner. I don't want to see them added again; alot of people find them useless.

Selfishness wins out, eh? "I don't use them, so we shouldn't have them."

[Hach-Que]

Treat uninitialised variables as 0.

This needs to be replaced with variables defaulting to a null or nil value, which would be illegal to provide as an ID to functions or act as a numeric or string value (i.e. the engine won't implicitly convert null to 0 or ""). This allows people to still know when they've got spelling mistakes, and gives advanced users the flexibility to set variables to a "unset" value (so we don't have to have a separate boolean value just to indicate whether some numeric counter is set or not).

GML

Seriously, replace it with Lua or something of that nature. You know you want to.

Edited by Hach-Que, 27 January 2011 - 11:25 PM.

[commander of games]

I used health and score too. All they need to do is add a 'set variable' action with 'global.health' to whatever value they want. It isn't hard. Besides, they SHOULD be reading the manual before they make something, so they SHOULD know what a variable is.

Haha, I'm sorry but that was just the most obvious contradiction I've seen in a while. The point is that they use them. It's not for you or us to decide when they should learn about variables. The very real point of GM is ... and I quote the Game Maker's Apprentice "Game Development for Beginners". Again, beginners use them. You used them, I used them. We now know better ways, but once we used them.

I fail to see your point. Basically your saying that because you onced used something, it isn't a good idea to remove it. Declaring a simple variable is not hard. A beginner could learn it in about fifteen minutes. All they need to do is READ THE FREAKIN' MANUAL(If you don't read the manual, that is YOUR fault). If you can't declare a variable you will be unable to create anything. It's a skill that MUST be learned sooner or later.

GML

Seriously, replace it with Lua or something of that nature. You know you want to.

No... Just no.

[ev149]

The Runner
Seriously, compile the games. The current interpreter makes it too easy for people to extract the source code.
SoftWrap
There has to be some better form of DRM that you can implement, SoftWrap is buggy and annoying.

[Jess Horton]

I fail to see your point. Basically your saying that because you onced used something, it isn't a good idea to remove it

Really? I thought I made it very clear. Here let me try color coding and bold letters on emphasized words. The point you fail to see is ... once you are done using the basic variables, you are done using the basic variables. That does not mean that future beginners are, unless everyone in the world gains knowledge every time you do. Basically you are saying that ... because you know how to do it, so should beginners.

Declaring a simple variable is not hard.

Never said it was. To those beginners who really have never programmed before, it may be.

All they need to do is READ THE FREAKIN' MANUAL(If you don't read the manual, that is YOUR fault)

Haha. Oh my calm down. Yes I agree with you that they should read the manual. If you read the manual you would know it starts with "Using Game Maker". Then it goes to "Advanced Use". Then the very last item is "The Game Maker Language (GML)". I believe it's structured for a reason. I mean sure you have the headstrong who wish to jump right into the meat (GML), but I think the majority of beginners want to start slow and get more advanced over time.

Edited by Jess Horton, 28 January 2011 - 12:13 AM.

[Schyler]

Timelines - I personally never use them. It also frees up some computation per object, because of all the timeline related variables that are automatically created and checked each step.
...
Triggers - I can see this being a performance hit somewhere in the runner. I don't want to see them added again; alot of people find them useless.

Selfishness wins out, eh? "I don't use them, so we shouldn't have them."

It's not selfishness to repeat what's already been repeated hundreds of times in this topic.

[makerofthegames]

Just because a lot of people are selfish doesn't make it not selfish.

[commander of games]

I fail to see your point. Basically your saying that because you onced used something, it isn't a good idea to remove it

The point you fail to see is ... once you are done using the basic variables, you are done using the basic variables. That does not mean that future beginners are, unless everyone in the world gains knowledge every time you do.

Declaring a simple variable is not hard.

Never said it was. To those beginners who really have never programmed before, they may be.

I never said that future beginners were done learning basic variables. I was saying that if you can't even declare a variable, you should not be making games. Period. Even if GM is supposed to be easy and for people who have no prior knowledge of programming, there are still some basic skills you'll have to learn if you ever wan't to make anything.

[Andy]

I don't know, maybe people do use this, but I don't really get why there is a "simple mode." I guess it just hides some stuff – not much stuff though. Personally I could do without that.

Removing the, change game priority, option in the global options would be ok. I think you should still be able to change it though GML though.

I use the, treat uninitialized variables as 0, option and would not want to see it removed. I guess I could do without it though.

I think keeping the game information option would be nice. Again I could do without it.

-

I do not think removing gravity, or other pre-set global variables like health, would be a good idea. Many people, including myself, use them with no problems. This would really be aggravating to beginners.

I was saying that if you can't even declare a variable, you should not be making games. Period.

I highly disagree with this, game designers are not always programmers, for a long time Mr. Chubigans used only D&D. Game Maker is designed to help those beginners, ones who cant declare a variable, be creative.

Anyway, on another note, the GML syntax should stay basically the same in my opinion. ...My very strong opinion. *Stern look.*

Edited by Andy, 28 January 2011 - 12:23 AM.

[GameGeisha]

uninitialised variables to 0. Stays. Beginners need this. It's just easier for them if it's there.

That option doesn't make a novice's life easier any more than an automatic syntax error fixer would. Errors that should have been reported directly would need to be discovered via observations with the debugger. This would increase the debugging load for novices and those who help them as well.

begin/end/then etc. all stay. GML is simple to get into because it understands many syntaxes. However... I'm starting to think we need an option to selected various syntaxes. Lax, Pascal, C, C#.. etc.. (just examples!)

Won't having to adapt to several syntaxes on top of each other in the same language confuse a novice even more? Look, nowhere in the manual did it say that we can use and, or and xor as boolean operators, begin and end as block delimiters and then as part of if statements. These aren't even in the standard to start with, so they should go away.

Does anyone use the printer stuff?

Not me. But since it is implemented as an extension, there's the option of leaving it out of finished games. That's fine with me.

The same cannot be said for the cd_*() functions, because it's built into the runner. Although I still have a couple of CDs, I don't play them with GM and the code for it just takes up space in the runner. Feel free to put them in extensions, but I don't want it in the main runner.

Triggers - I can see this being a performance hit somewhere in the runner. I don't want to see them added again; alot of people find them useless.

I would vote for trigger to stay. Rusky has already posted the reasons for why they should stay from page 3, see for yourself. Besides, it was originally implemented for a request for custom events that automatically trigger --- what will fill that void?

My most recent game uses a trigger-based pausing mechanism which allows me to selectively pause certain step activities with the change of a single global variable. Inheriting these activities over an object hierarchy is where triggers shine over step-checks.


As for a short list of things that need to go:
- All deprecated functionalities, except for instance deactivation. (It's about time they go for real.)
- All GML constructs not present in the GM manual, including the use of = for equivalence checking. (Keep the standard consistent.)
- mplay_*() (DirectPlay's fallen from grace, and so should this.)
- script_get_text() (I don't see any useful applications of this.)
- secure_mode (Really, who doesn't use external files and DLLs nowadays? It doesn't work when GM isn't running, either.)
- score, lives, health, show_score, show_lives, show_health, caption_score, caption_lives, caption_health (Please, just make the novices learn about variables, it's not that hard.)
- sleep() (Too easily mistaken for freezing.)
- sound_set_search_directory() (I don't think anyone would use this, given the presence of sound-playing DLLs and tracker formats.)
- Simple mode (Many settings and properties that still have effects, such as views and scripts, get hidden this way --- just trash it.)
- Game Information (Looks ugly, limited in functionality, kill it.)
- solid (Causes lots of issues with collisions.)
- "Treat unitialized variables as 0" and "Show all errors" checkboxes (There is only one good setting for these things.)
- execute_string() and execute_file() (Inefficient, opens up potential security threats and prevents GML from being compilable)
- set_program_priority() (NPT has explained why pretty well.)

Things that can stay but should be moved into extensions:
- cd_*(), MCI_command()
- ini_*()
- highscore_*()
- date_*()
- registry_*()

GameGeisha

[Hach-Que]

GML

Seriously, replace it with Lua or something of that nature. You know you want to.

No... Just no.

Maybe not replace, but in addition to. Because Lua is awesome. And is dead easy to bind to C++ code.

[mcmonkey]

*cough* Remove nothing, everything is useful to someone...

[Takagi]

#1 : the "keyboard_check_direct(...)" command (and other methods behaving like it). A game should not be able to see what another other programs input is. Maybe the addition of an "Abort now key" would than be neccessary though ...

I'd like to keep this. My problem was solved by this. I had no other programs running, yet my game still seemed to not detect the keyboard input with keyboard_check. Yeah, personal experience.

I'd also suggest keeping execute_string. I currently use it as a "bug fixer", so I can play around with variables in the EXE without reloading. Changes would be fine, but I'd suggest keeping it.

[Rusky]

BUT! (and here's the revision) What I think it actually needs.... is proper error messages telling you it hasn't been initialised yet... This then PROMPTS them to fix it and doesn't just give a different error (instead of 0+12, you might have 234+12; same problem and just as hard to track down). If the variable wasn't set up, you would get an unreproducible error (as the memory will keep changing), and this is very hard for even pros to track down. It has to be consistent, and reproducible.

This already exists. If the option is disabled it gives you an error, not junk memory. All you need to do is remove the option. However, like Hach-que said it might be nice to have a null value rather than an immediate non-existing variable error. I'm not sure which of these would work better for GM- non-existing name errors or default null values.

Regarding the build in "score", "health", and "lives" variables: I agree that beginners use them and they should remain because they act as a bridge between the beginner's preexisting knowledge of video games and variables, but I would like to see them lose their global-by-default status. I've seen quite a few problems resolved because a beginner didn't realize that those variables were global. Perhaps an "Applies to" dialog could be added to the relevant actions, so that no overall functionality is lost. It seems logical that a bullet, upon impacting on the player, should take away one of the player's lives.

This. There is absolutely no reason for built-in global variables for score, health or lives. That causes more confusion than it's worth- the names are taken and as soon as you try to make instance-local health for monsters you run into a problem: your game fails to work without so much as an error message, and you get to debug it. There's really no reason for them to be built-in, either. Once they're not global anymore, you can use them exactly the same way whether they're built-in or not.

Finally, I'm curious as to the reason you won't consider removing the beginner/advanced mode distinction, and the reason you would consider adding a third mode. The beginner mode has little impact on the actual use of Game Maker, beyond making it impossible to find "advanced" features. If it really is a beginner mode, should it make Game Maker easier to understand? I don't see that it makes anything easier at all.

Also agree here. I know I immediately switched to advanced mode when simple mode was missing half the stuff from tutorials. The only reason to hide things in the UI is to make thing simpler, and making it harder to find things is not simpler. A much better solution than adding yet another mode would be to have a single mode that is more intuitively designed.

[commander of games]

I was saying that if you can't even declare a variable, you should not be making games. Period.

I highly disagree with this, game designers are not always programmers, for a long time Mr. Chubigans used only D&D. Game Maker is designed to help those beginners, ones who cant declare a variable, be creative.

You can declare a variable with D&D using the Set Variable action. And technically even when your using D&D you are programming. I find it hard to imagine that there are any games, other than maybe Catch the Clown or something, that don't use user defined variables. So I repeat, if you can't declare a variable you will not be able to make anything serious.

[Jess Horton]

So I repeat, if you can't declare a variable you will not be able to make anything serious.

You've repeated this many times but I don't recall anyone arguing that. Defining a variable is the easiest thing ever, but some beginners might not think so. It doesn't matter anyhow, Mike said those basic variables will stay because they help beginners which was what I've wasted two posts on trying to explain to you anyway.

[Andy]

@The idea to remove preset variables:
Would any improvement, to Game Maker, be made by removing them? If not I think that they should stay. It would be making simple tasks a lot harder for new users / lazy people. I demand a good reason, for me to have to program my own gravity system, when the inbuilt one works fine.

Edited by Andy, 28 January 2011 - 02:13 AM.

[Yourself]

GML

Seriously, replace it with Lua or something of that nature. You know you want to.

No... Just no.

Maybe not replace, but in addition to. Because Lua is awesome. And is dead easy to bind to C++ code.

If not that then at least a more comprehensive and robust extension API that would allow people to create their own GM bindings in other languages. But that's not what we're talking about right now.

[Mnementh]

In the spirit of making things easier for beginners and advanced users: what if built in variables, like "score", "health", and the corresponding actions were only available when Game Maker was in beginner mode? That is, what if the things that make beginner mode unusable were eliminated, and elements of Game Maker that are undesirable to more advanced users, such as the global-by-default variables* were removed from the advanced mode? If the simple and advanced modes operated in such a way - as opposed to the useless manor in which they currently operate - I think that the majority of users of the simple mode would also use drag-and-drop, and most users of the advanced mode would use GML. It may be possible to avoid the use of variables using D&D, but can we agree that no significant usage of GML can occur without variables? If so, then the presence of the built in variables only in the simple mode is logical because D&D users may not be familiar with the way game concepts translate to variables - so Game Maker can do it for them, in the form of the frequently used "score", "health", and "lives" variables. GML users, on the other hand, have a steady grasp of variables and can function better without intrusive built in features.