133 replies to this topic

[deformed thought]

How about we...

1) Allow users to make instances that disclude variables,

2) Allow users to delete other variables, such as arrays;

3)Compile a game for running only with the functions it USES and what is neccessary to emulate it! That would massively improve performance issues.

EDIT:
Treating Uninitalized variables is useful when you have random "this variable doesn't exist" statements, which I've had, and when you need to know the errors besides the fact that the variable isn't defined.

Edited by deformed thought, 27 January 2011 - 09:07 PM.

[Jess Horton]

I'm with Fred on the custom ui boxes, get them out. I agree with a lot of people on removing MPlay. I am super excited about you guys rewriting a new networking system. Chronic is on top of things with his list, I like the idea of having CD and Printer functionality by choice ... moving them to extensions.

I've seen many talking about removing syntax, you are not forced to use it. I've never used then, begin, end, ever. I think stuff like that should stay. It's easy for all of us to be selfish and think about what things we want because we are experienced, but if we get too crazy, then the whole beginner aspect of GM becomes too daunting. Sure it makes sense to me to remove health, score, and what have you, because I can make my own, but newer people do rely on these things.

Edited by Jess Horton, 27 January 2011 - 09:18 PM.

[lacie]

MPlay. There is 39dll and with this extension you can make much better working multiplayer. Since multiplayer is for experts in GM, it's not a problem to use DLL or GEX extension - so mplay can be removed to save some bytes in exe file.

Timelines - I don't have use for them, you can do the same using one variable and step event in many ways and with better control... but requires some knowledge of course, so maybe not for all it's the best idea.

Game information - you can make room with text, images or sth which looks much better. It can be left in IDE file as form of internal notepad, maybe some people makes notes there about their project during development, but it shouldn't be saved and available into executable.

Triggers - it's just step event with condition, it's equivalent for "execute piece of code" action with: "if some_variable = true { <trigger actions here> }". It's like splitted step event only, because you have action blocks in two events.... but it's still step event.

Timelines
Rarely use them...
You can also use an object with step event, that checks for the current second (or step) then do the action?

Triggers
Because I've never used them before, and it works fine without them.

Game Information
Rarely use it, and a room with info looks much better.

For a newbie is same as me, i really need them. Don't remove... especially for Timelines.

Edited by lacie, 27 January 2011 - 09:28 PM.

[gnysek]

About "Treat Unitialized variables as 0":

if my_very_long_variable = true {}
if my_very_long_variable = true {}
if my_very_long_variab1e = true {}
if my_very_long_variable = true {}
if my_very_long_variable = true {}

Do you see line which should give us error, but are not giving, and is treated as false even if I set my_very_long_variable to true?
Begginner user will make 1000 topics about this, gonna insane and then he create game one again from scratch, because his "if" is not working even if he setting this variable one line before.



In third line there is no 'L' letter in variable, there is '1' (one). Copy and pase it some where you don't have monospace font and check if you don't belive. The same can go in for loop or when you are using arrays.

Edited by gnysek, 27 January 2011 - 09:35 PM.

[commander of games]

to commander of games:
You're wrong, when I first start using Game Maker, I had no programming experience at all, and I did used the health and score, I used D&D of course, but still when moving to GML, I used the health and score, so removing it will create beginners many problems.
And I do agree with the other posts here. (About game help, treating unknown variables as 0, etc).

I used health and score too, but that was not my point. Why would it create problems? 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.

[Jess Horton]

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.

Edited by Jess Horton, 27 January 2011 - 09:55 PM.

[Desert Dog]

There are a few things here, which I'd like to talk about.

Timelines Are very useful. Should NOT go.

Built-in help I use it as a to-do list, for when I'm devving my game. It's useful in that respect, and also useful for providing a sort of help for small projects. I'd like to see it stay, but would looove to see it with a few more features. [for instance, adding images]

built in global variables like health very useful when I was a beginner, only a touch confusing when I was trying to learn GML.. these are fine, why remove them?

[ragarnak]

The hide errors function has actually a purpose - on a finished product one might want to hide error message and instead replace them with their own error handling system

When I was thinking how to write what I wrote that I already thought someone would come up with that. And that is exactly why I included that "local error handling" paragraph.

The problem is that that "don't show errors" mode is often engaged quite early in the development-phase (instead of allmost at the end), resulting in the earlier-mentioned messs.

I was even considering to suggest a "reset to default at loading" feature (forcing the person creating the game to re-evaluate any errors that might pop-up), but this was about removing features, not a request for more stuff to implement.

I don't think it's a good idea to recommend a deprecated (and undocumented) function

I do not either. But I can't help but wonder : why should that command go ? It has no negative side-effects or is just plain ugly. And yes, that made me mischievous and play a bit of the advocate of the devil. To be honest, I have not used it for ... wel, directly after I switched to v6.x I guess.

Although its funny to see that this "should go" command has been depricated but survived 3 versions and about 6 years now.

In this regard (using undocumented commands ) I must say I was a bit baffeled to see the "action_...()" commands prominently displayed in GM v8.0s "show build-in functions". Maybe they should be removed there (mike, looking at you).

Registry - WILL go. It's a massive security hole that needs nuked as quickly as possible.

<snip star-treks facepalm picture>

I agree with you here. But when its put that way ("WILL go") I know when to shut up.

And luckily we have some capable programmers here which will probably replace that killed functionality with a simple DLL, eventually embedded in an extension-package. In short: you probably won't even notice it was gone. (And yes mike, this is a (somewhat) silent protest, as well as showing you the futility of your decision).

[FredFredrickson]

Registry - WILL go. It's a massive security hole that needs nuked as quickly as possible.

I'm a tiny bit sad to see the registry commands go away. I know they are an awful security risk - probably the worst one in Game Maker - but I also liked having a global place to store cross-game information easily that existed on all Windows platforms. But eh... so be it.

set_program_priority (and similar functions). Yes, I think they should go too...

Does anyone use the printer stuff?

Never. I had actually forgotten that these functions existed... and now I kind of want to, haha. Anyone remember that old game that EA (?) tried about ten years ago that involved the player receiving telephone, email, and fax messages in the real world?

[Mnementh]

So actually... I would now drop that feature, and replace it with a much BETTER one, of reporting variables as uninitialised. This would be far, FAR better, reasonably simple - but would take a speed hit. Perhaps a debug/release more thing would start to help in this regard. We already have it (DEBUG/Build EXE), so we could expand that...

I'm not sure I understand. We already have an error message for uninitialized variables, don't we? How does your suggestion differ from the extant "Unknown Variable" error message? Wording? If so, I think that's a great idea. Game Maker's error messages are descriptive, but often require experience and knowledge to comprehend, and making them easier to understand would be extremely helpful for beginners and advanced users alike.

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.

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.

But I can't help but wonder : why should that command go ? It has no negative side-effects or is just plain ugly.

It has a negative side-effect of ugly forum posts. That's reason enough, in my opinion.

[ragarnak]

What I think it actually needs.... is proper error messages telling you it hasn't been initialised yet...

Doesn't GM already have that ? In the way of reporting an "unknown variable" when you try to read from it ?

Or have I misunderstood you and are you really thinking about declaring a variable before initializing it ? And than regarding/renaming that switch as an "option explicit" equivalent ?

Actually, I think I would like to see the possibility to have a "declare before usage" switch. It not only makes short process with mis-spelling variables you want to read from, but than also for the ones you want to write to.

However... give an error when someone tries to READ a variable that hasn't been set yet, and it's then VERY obvious that you have to set it to something first, and this aids the learning process.

Yep. Apart from a novice getting the heck confused outof him why certain variables stay Zero when they are sure they did put something into them they will actually learn something.

Oh, by the way: Another thing I would like to see gone : GM silently ingnoring strings where it expects numbers and use the value Zero instead. I would rather see an error there. It does when you do the reverse (a value where a string is expected), so why not the other way around too ?

[Schyler]

Everything I'm about to say is directly related to runner speed and size. I have no concern for the people who used these functions - most useless, anyway.

mplay - Better done with extensions, please remove it (and don't try and make an equivalent - I think using extensions is fine, since its not included in the runner to take up space). If you want to include it with GameMaker, why not include it as an extension so we can choose to add it?

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.

Global score/lives/health - Annoying to code around, since they have very generic names. I'd prefer if they were just removed, but I can understand why you might not want to.

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.

cd_*, execute_*, max3, min3, image_single... - Please deprecate the functions that need to be deprecated. If you're rewriting the runner, dont rewrite it to be backwards compatible. Things that are deprecated eventually need to be removed - rewrite it for speed and a small filesize. That's what we've been begging you to do for ages.

d3d_ - Remove the existing 3D lights system and rewrite it to be handle based (saving memory, and making it easier to use).

EDIT:

Dialogues. - I would prefer to replace them (show_message() ) with native ones ( Windows or Mac standard ones ). I think this gives a better user experience (Mac users love to see proper Mac dialogues etc.)

PLEASE DO THIS. <3

Edited by Schyler, 27 January 2011 - 10:53 PM.

[~Dannyboy~]

To add to the list of functions which do things to my computer that I would rather games didn't:

display_set_all
display_set_colordepth
display_set_frequency
display_set_size

Games shouldn't need to change the resolution, it's really not that hard for people to just scale the game with views. Why on earth a game would want to change your frequency or colordepth I don't know.

[paul23]

@the topic of solid removal:
-Well this still wouldn't solve it.. What if I want to move out of A & B, but not C.. And later I would like to move out of A & C but not B? - using "Solid" allows you to easily (& quickly compared to deactivating) "group" objects.

So actually... I would now drop that feature, and replace it with a much BETTER one, of reporting variables as uninitialised. This would be far, FAR better, reasonably simple - but would take a speed hit. Perhaps a debug/release more thing would start to help in this regard. We already have it (DEBUG/Build EXE), so we could expand that...

It's always the hidden things which are the best news! - Different builds would allow gamemaker to have soo many "upgrades"! Finally you have the possibility to don't add comments in the release build.
Also this would allow you to do a quick scan for any use of the "score" (and other build in) variables, and possibly not include them in the release build?

Dialogues. - I would prefer to replace them (show_message() ) with native ones ( Windows or Mac standard ones ). I think this gives a better user experience (Mac users love to see proper Mac dialogues etc.)

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.

@dannyboy, I take it you don't play any "big" game then? 100+% of those games allow you to set those things (well apart from the frequency). Removing those would severly limit gamemaker to only make minigames!

Edited by paul23, 27 January 2011 - 10:54 PM.

[frankpiet]

Remove all CD functions, everyone rips music now.


Choose whether you want to remove the mask interface in the sprite editor (for a inbuilt one) or the mask option in the object editor. I see no point for two.

[ugriffin]

Mplay. There are far better open source alternatives that you can pillage and add into the GM runner (39dll, 39dylib?).

In fact, this has already been done in GM4Mac (dead mplay), and it's not missed one bit.


I'm against removing the registry functions, some of us find it useful when we *want* to hack something using Game Maker (then again, this doesn't concern me anymore).


In game help ought to be rewritten, not nuked. Something to fit .CHM in Windows and .help in Mac OS...


CD functions should stay and expand.


Something people tend to forget are INI functions. They're dead useful, but you can only keep one open and it can only be in the game's root directory, so it NEEDS love.

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

Edited by Schyler, 27 January 2011 - 11:05 PM.

[~Dannyboy~]

@dannyboy, I take it you don't play any "big" game then? 100+% of those games allow you to set those things (well apart from the frequency). Removing those would severly limit gamemaker to only make minigames!

Well. You've got me there. I guess what I don't like is games which choose the resolution for me and change it without permission. You're correct that having options in the game which allow you to change the resolution can be useful. Perhaps rather than removing the functions, a warning could be added to the manual stating that using these functions without allowing the user to decide is not good, but no one would read that...

[paul23]

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