Jump to content


What should go........?


  • This topic is locked This topic is locked
133 replies to this topic

#31 GPro

GPro

    Gun Powder Games

  • GMC Member
  • 293 posts
  • Version:GM8

Posted 27 January 2011 - 04:58 PM

You should be choosing what to have in your GM, (from ur personal computer) so everyone can be thanked :)
  • 0

#32 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 January 2011 - 05:14 PM

Variables like health, score.
Making objects solid.
Mplay should also be removed (though an alternative that works better would be good).

Edited by Dark Matter, 27 January 2011 - 05:14 PM.

  • 0

#33 gnysek

gnysek

    GMC Member

  • GMC Member
  • 492 posts
  • Version:GM:Studio

Posted 27 January 2011 - 05:15 PM

MCI_command and cd_xxx functions. Even Sony closed their biggest CD factory in USA.

Health and Score should left for begginners - remember, some people using Game Maker at school, so it can be first time that they programming - score and health works also without GML, by drag&drop actions.

Edited by gnysek, 27 January 2011 - 05:18 PM.

  • 0

#34 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

  • GMC Member
  • 7938 posts
  • Version:GM:Studio

Posted 27 January 2011 - 05:36 PM

Remove deprecated features
When a feature is deprecated, formalize its deprecating in the documentation, keep it in the next version for backwards compatibility, then actually remove in future versions.

ie. image_single

image_single was deprecated and replaced with image_speed/image_index years ago. V4 maybe V5. But it's still hanging around.

Action_* functions
I'm not saying to remove actions, but at least remove action_functions from being used directly and from within the function list and editors intellisense.

execute_string and execute_file
Horribly inefficient, can usually be avoided. The existence of these functions prevents or limits potential future GM features such as compiling or obfuscation.

cd_* functions
Do really need games to be playing CDs

max3, min3
deprecated years ago.

set_program_priority and priority related system
If a program performs poorly, the solution is to redesign and improve algorithms. Not to steal resources from my OS and other processes.

Edited by NakedPaulToast, 27 January 2011 - 05:39 PM.

  • 4

#35 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 January 2011 - 05:40 PM

Remove deprecated features
When a feature is deprecated, formalize its deprecating in the documentation, keep it in the next version for backwards compatibility, then actually remove in future versions.

ie. image_single

image_single was deprecated and replaced with image_speed/image_index years ago. V4 maybe V5. But it's still hanging around.

Action_* functions
I'm not saying to remove actions, but at least remove action_functions from being used directly and from within the function list and editors intellisense.

execute_string and execute_file
Horribly inefficient, can usually be avoided. The existence of these functions prevents or limits potential future GM features such as compiling or obfuscation.

cd_* functions
Do really need games to be playing CDs

max3, min3
deprecated years ago.

set_program_priority and priority related system
If a program performs poorly, the solution is to redesign and improve algorithms. Not to steal resources from my OS and other processes.


Yeah, I agree with most of these, though there are circumstances where execute_string is useful...
  • 0

#36 ragarnak

ragarnak

    GMC Member

  • Retired Staff
  • 19468 posts
  • Version:GM8

Posted 27 January 2011 - 05:56 PM

I think these should be removed:
..
- Pascal syntax
..

If that is possible than I vote for removing any C(++/#/anything) syntax too. We're talking about GML here, not some derivative of some other language. :whistle:

Triggers

I do not know if they have any real speed advantage, but for the rest they are doing something you can already do yourself. So: agreed.

And while we are at it, the 3D sound functions are crap too and i donīt think anyone actually uses them (although Iīm probably wrong!)

Although they are not used often, 3D/directional sound can add quite a bid of atmosfere to 3D games (being able to determine from which direction your enemy tries to sneak up on you. No current 3D game could nowerdays do without it). So: Disagreed.

Solid in the objects properties. I know this may not be liked by some people, but is it really that hard to program "x=xprevious" into a collision event? And it seems to cause more problems than it solves from my experience on the novice forums...

Only if commands like "move_outside(...)" get enhanced to check for specific objects (like Mark13673 already mentioned). Alas, enhancing other functions was not part of the question. So: Disagreed.
  • 0

#37 gnysek

gnysek

    GMC Member

  • GMC Member
  • 492 posts
  • Version:GM:Studio

Posted 27 January 2011 - 05:59 PM

Yeah, I agree with most of these, though there are circumstances where execute_string is useful...


True. execute_string should left, it's like REMOVED) in other scripting languages. But execute_file gives you possibility to change everything in game in real time by injecting code - you can even create new objects, and gameplay in someone game! And export some data and resources without decompiling.

Edited by gnysek, 27 January 2011 - 05:59 PM.

  • 0

#38 TheMagicNumber

TheMagicNumber

    GMC Member

  • GMC Member
  • 5247 posts
  • Version:Unknown

Posted 27 January 2011 - 06:00 PM


I think these should be removed:
..
- Pascal syntax
..

If that is possible than I vote for removing any C(++/#/anything) syntax too. We're talking about GML here, not some derivative of some other language. :whistle:

Having two syntaxes that you can switch between at any time is silly. Just one is enough. :)

Of course, things like semicolons and (maybe) parenthesis-less statements would still be optional. Just make it impossible to mix begin/end and braces.

I'd also like to see the examples in the manual where all the code is in a block removed. You don't need all your code in a block.
  • 2

#39 LSnK

LSnK

    NaN

  • GMC Member
  • 1188 posts

Posted 27 January 2011 - 06:12 PM

Having two syntaxes that you can switch between at any time is silly. Just one is enough.

Unless you use it. I don't feel like 'fixing' a hundred thousand lines of code to satisfy someone else's obsessive-compulsive urges for linguistic purity.

It's not the type of suggestion they're looking for anyway. There would be no performance or filesize gain, and it's a negligable amount of work to implement.
  • 1

#40 ragarnak

ragarnak

    GMC Member

  • Retired Staff
  • 19468 posts
  • Version:GM8

Posted 27 January 2011 - 06:14 PM

Having two syntaxes that you can switch between at any time is silly. Just one is enough. :)

Having a language which accepts a number of different ways to describe what you want just caters to people (teachers?) coming from other language than that C(whatever) language. You could even claim that it enables the teenagers using GML to choose which kind of notation they are most comfortable with. [/sarcasm].

Something just popped in my mind : those "||", "&&", "^^" should go too. We already have the way more intuitive "or", "and" and for anyone having done anything with booleans, "xor" for that.

But that again, some pople here swear by those "&&", "||" aand "^^" thingies. Who am I that I should decide they should be using my way of expressing such things ? :whistle:

Of course, things like semicolons and (maybe) parenthesis-less statements would still be optional. Just make it impossible to mix begin/end and braces.

In other words: make it a strict syntax (maybe even switchable between certain preferences).

I would call that a big change to GM, and most likely not at all what Mark had in mind when he created it ...
  • 0

#41 ragarnak

ragarnak

    GMC Member

  • Retired Staff
  • 19468 posts
  • Version:GM8

Posted 27 January 2011 - 06:21 PM

But execute_file gives you possibility to change everything in game in real time by injecting code - you can even create new objects, and gameplay in someone game!

Same for "execute_string(...)". Removing the other only means that some dumb*ss now using a single command to create his most excelent saving-and-loading system now first needs to read the contents of that whole file into a string, to only than have it executed. End-result: nothing changes. :mellow:
  • 0

#42 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2463 posts

Posted 27 January 2011 - 06:58 PM

Agree on dual syntax/semicolons, mplay, game information, built-in globals like health and score, deprecated features, simple mode, uninitialized as 0, MCI/cd_*, action_* and execute_* in their present form.

Disagree on triggers- they're not just checks in the step event- they can be named, individually executed and most of all inherited. It's much more painful to do that without them. In fact, some of the built-in events could/should be converted to trigger events as this would simplify GM's internals as well as potentially allow them to be moved into extensions.

However, most of these would need to be done with care so as not to make things worse. The syntax of old projects could be trivially upgraded to whatever the new version uses, but in some cases there's no clear consensus on which syntax is better or more widely used. Health and score actions would need to be converted to work with regular globals or even locals (which would be extremely useful for health).

The execute_* functions are useful, but also broken. Workarounds are generally painful or not generally applicable. The best way to replace them would be to find primary use cases and introduce new ways to do those things- looking up resources by name, external scripting, callbacks and closures (yes, sorry Mike :P) are a few.
  • 0

#43

  • Guests

Posted 27 January 2011 - 07:11 PM

Some interesting ones....

mplay is on it's way out. Regardless of who actually uses it, it's WELL past it sell by date. We will rewrite the whole networking system from scratch.

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

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!)

Gravity, score, health etc. all stay. Beginners use them.

In game Help - is a pile of pooh, and will be shot at dawn, or as soon as I can get my pawns on some rusty knives to kill it with. :) An HTML web page would be far better, although most games should just do in game help themselves, it's a far better experience.

We have started using OpenAL internally. This might go into GM at somepoint, but I'm not sure how this would affect things other than give better access to stuff like MP3s, and OGG etc.

Choice of renderer is academic, and easy to have multiples types - don't worry about it. And if someone tells me what DX10 and DX11 actually has that would make such a huge difference to what Game Maker does, I'll be impressed.

Timelines - aren't terrible well implemented, but they are brilliant. We may well increase support for them and make them easier to use and visualise.

Hiscore - we've been moving to a more "contained" system, where everything comes up inside the gaming window. This is a better experience, and far more portable. Again... not sure when this will appear, probably when the C++ runner does.

execute_string(...), execute_file(...). While I really don't like these, they are used all over the place, so I'm more in favour of changing them, so you can "compile" a script yourself. This would mean you can load, compile, execute. which would then allow you to keep speed up, but still keep the flexibility.

Beginner/Advanced mode. DEF stay, in fact we may even add a PRO mode. Mark was right on the money with these ones.

CD functions... interesting. possibly, but not yet I think. you can still buy cd's, so you might want to do something with them....

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

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

Does anyone use the printer stuff?

#44 ragarnak

ragarnak

    GMC Member

  • Retired Staff
  • 19468 posts
  • Version:GM8

Posted 27 January 2011 - 07:13 PM

I just thought of a few I would really want to have gone :

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

#2 : the "sleep" command (D&D & GML). Freezing an event-driven program is not the idea.

#3 : the "splash_show_web(...)" command (D&D & GML). Its little more than a dumbed-down version of "execute_program(...)" and "execute_shell(...)" commands, simply displaying a full webpage (whatever it might be, even some porn-site) in IE (even when you have FF as default browser) with its default security-settings. Not really to my liking. Remove please.
  • 0

#45 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 19883 posts
  • Version:GM:Studio

Posted 27 January 2011 - 07:26 PM

Sorry Mike, but that uninitialized variables thing is NOT a good thing for beginners... Honestly I have thousands of posts in the Novice section here and I see a LOT of users who can´t solve their problems due to this. It just masks small errors until they get so big that it´s almost impossible to say where to begin to fix the problem. I think it´s better to teach people right from the start to code in a logical, clean and ordered way as well as teaching them how to debug their own code. Something that function makes very difficult...

EDIT: Oh, and I don´t use the printer options ever...

Edited by Mark13673, 27 January 2011 - 07:28 PM.

  • 3

#46 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2370 posts
  • Version:GM:Studio

Posted 27 January 2011 - 07:27 PM

Timelines should stay becuase they are a clear way of scheduling things like cutscenes, animations, or anything time-based that is predefined by the programmer (like when enemies appear). Doing this another way requires GML, which makes it less accessible to novices.

Triggers should definitely stay. I use these quite a lot in my GM8 games because they clear up the code a lot. I find this very important: clean code. Trigger events help with this.

Health and score should stay. Beginners use these a lot. Especially score, since the highscore list is based around it.

I even think execute_string should stay, because it does things no other GML function does. At least I have used execute_string in a game that would've been a lot harder to code (if even possible) without (the game was about placing items on sensor platforms to change their value in such a way that a given math equation would turn true. I used execute_string to evaluate the equations. If I didn't have execute_string, I would have to either write my own equation parser, or hard-code all equations and their solutions which means I can easily forget solutions.)

Anyhow. Things mentioned by others earlier that I support for removal:
simple mode
The first thing that newbies are getting as advice when can't find something, is usually Go to advanced mode. Doing this, the GM IDE will look the same for everybody, which makes helping each other find things a lot easier.

treat uninitialized variables as 0
All this does is hiding the most useful error message you can get. If you use an unitialized variable, your code is wrong. It's that simple. An no, beginners don't need it. They need the unknown variable error to fix their coding.

Program priority setting
Explained already by NakedPaultoast in post #34. I have never seen it do anything good and it can make other processes unresponsive. Also as far as I know almost any game that lags takes 99% CPU anyway, so this won't do much.

deprecated functions like image_single, part_type_color, file_eof, font_name, ...
I mean...

image_single was deprecated and replaced with image_speed/image_index years ago. V4 maybe V5. But it's still hanging around.

It's even worse: I still sometimes see people recommend others to use image_single.
  • 0

#47 ragarnak

ragarnak

    GMC Member

  • Retired Staff
  • 19468 posts
  • Version:GM8

Posted 27 January 2011 - 07:33 PM

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

Sorry my saying so, but beginners need that like a hole in their heads.

It just makes it easier for them to make all kinds of spelling-mistakes and think there is no problem. The end-result often is that they than post on this forum with the mess their program has become to ask us to figure out what went wrong ... :(

Ofcourse, this mess is only possible because GM (still) uses a resource-system in which Zero is a valid ID. :mellow: (and yes, thats a hint. :) )

One even more evil setting is the possibility to disable the showing of errors. Misteriously failing programs galore. End yes, I had the displeasure to have tried to figure out how to help members to recuperate something of their (often) hard work.

I'm in favour of a more localized approach, where a few lines can be excluded from throwing errors (and than checked with the normal error-variables afterwards).

[edit]

I still sometimes see people recommend others to use image_single.

Its a one-stop setting of a certain sub-image and telling the instance not to animate: one command instead of two. Sounds like a good decision to me. :whistle:

Edited by ragarnak, 27 January 2011 - 07:59 PM.

  • 0

#48 Joebra

Joebra

    GMC Member

  • New Member
  • 4 posts

Posted 27 January 2011 - 07:45 PM

There are some things I would like to say, but I will just bring this up right now since I'm short of time right now.

Treat uninitialized variables as 0
In my opinion this is bad, even for beginners. Why? Well, simply because it makes it harder to debug your program. If you've missed to initialize a variable somewhere in your code (even if your code is fairly clean) it can get extremely irritating and time consuming to find that tiny mistake. It may now cause horrible bugs, but it's possible that it causes hard found bugs and that's one thing that you want to avoid. If you want your variables to initialize to 0, then write it on your code yourself. Write "variable_name = 0;" instead of just "variable_name;". The latter is just bad practice and shouldn't be allowed. It's better if beginners learn from the start of to initialize their variables and it will also prevent lots of unnecessary bugs caused by a variable that you missed to initialize.

This is just my opinion and I agree with the others that have said that this should "go". As I mentioned before, you shouldn't learn beginners something that is just bad practice. It may (I don't say it will) make it harder for them to continue on with some other language like C, C++, C#, Java, etc. Well, I'm not going to say more about this, I've already said enough. I'll probably give my thoughts about some other things at a later point, but not now.
  • 0

#49 Chronic

Chronic

    Administrator

  • Global Moderators
  • 2729 posts
  • Version:GM:Studio

Posted 27 January 2011 - 07:46 PM

I would agree to remove registry functions, and to remove program priority all together (from editor and functions).

CD and Printer functions could be moved to there own extensions.
  • 0

#50 Nehacoo

Nehacoo

    GMC Member

  • New Member
  • 180 posts
  • Version:GM8.1

Posted 27 January 2011 - 07:54 PM

#2 : the "sleep" command (D&D & GML). Freezing an event-driven program is not the idea.

I find it very useful for debugging loops though.

As for "Treat uninitialized variables as 0", I remember it only confusing me further when I was new to Game Maker.. I can't speak for everyone else but I don't think it's much help.

Edited by Nehacoo, 27 January 2011 - 07:55 PM.

  • 0

#51 ragarnak

ragarnak

    GMC Member

  • Retired Staff
  • 19468 posts
  • Version:GM8

Posted 27 January 2011 - 08:03 PM

I find it very useful for debugging loops though.

:) Thats the only thing I can remember I've ever used it for. For loops that visually did something.

Ofcourse, I only used it as a replacement for the "show_message(...)" box I had there earlier, as that gave me the possibility to single-step (and keeping a button down also is a kind of slow sleep :) ).
  • 0

#52 Chronic

Chronic

    Administrator

  • Global Moderators
  • 2729 posts
  • Version:GM:Studio

Posted 27 January 2011 - 08:09 PM

Sleep is also useful when adding a pause button to your game, however using the de/activate instance functions can give you the same effect.

io_clear();
while !keyboard_check_pressed(vk_anykey) sleep(100);
instance_deactivate_all(true);

  • 0

#53 IceMetalPunk

IceMetalPunk

    InfiniteIMPerfection

  • Retired Staff
  • 9322 posts
  • Version:Unknown

Posted 27 January 2011 - 08:36 PM

io_clear();
while !keyboard_check_pressed(vk_anykey) sleep(100);

Is that not identical to:

io_clear();
keyboard_wait();

?

-IMP ;) :)
  • 0

#54 FredFredrickson

FredFredrickson

    Artist

  • Global Moderators
  • 9208 posts
  • Version:GM:Studio

Posted 27 January 2011 - 08:38 PM

How about removing the Game Maker "game UI" (the UI of the boxes like show_message() produces) and make the default message boxes whatever is native to the OS you create your game for? That would make GM games seem much more "legit", I think (plus I can't stand those ugly black boxes).
  • 0

#55 IceMetalPunk

IceMetalPunk

    InfiniteIMPerfection

  • Retired Staff
  • 9322 posts
  • Version:Unknown

Posted 27 January 2011 - 08:41 PM

How about removing the Game Maker "game UI" (the UI of the boxes like show_message() produces) and make the default message boxes whatever is native to the OS you create your game for? That would make GM games seem much more "legit", I think (plus I can't stand those ugly black boxes).

Seconded. There's no need to have a separate, verbose extension to replicate exactly the same things as the default functions, but with a recognizable interface.

-IMP ;) :)
  • 0

#56 commander of games

commander of games

    Kaos Kreator

  • GMC Member
  • 2879 posts
  • Version:GM:Studio

Posted 27 January 2011 - 08:52 PM

score, health etc. all stay. Beginners use them.


Beginners should be able to get along without score and health. All they need to do is create a global variable called health or score... Maybe(I know this isn't the place to suggest features)have a setting the Global Game Settings that will allow you to choose if these are 'pre-defined' or not?
  • 0

#57 FredFredrickson

FredFredrickson

    Artist

  • Global Moderators
  • 9208 posts
  • Version:GM:Studio

Posted 27 January 2011 - 08:56 PM


score, health etc. all stay. Beginners use them.


Beginners should be able to get along without score and health. All they need to do is create a global variable called health or score... Maybe(I know this isn't the place to suggest features)have a setting the Global Game Settings that will allow you to choose if these are 'pre-defined' or not?


Thing is, these things make it easier for beginners, and don't affect advanced users at all. There's no point in getting rid of them just for the sake of getting rid of them.

Maybe it'd be more useful if in Advanced or Pro mode you could disable some of the default globals like these. I'm not really sure how that would help, other than to make sure that your game throws errors if you accidentally use one of those var names or something, but hey, just a suggestion.
  • 1

#58 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2370 posts
  • Version:GM:Studio

Posted 27 January 2011 - 08:56 PM

One even more evil setting is the possibility to disable the showing of errors. Misteriously failing programs galore. End yes, I had the displeasure to have tried to figure out how to help members to recuperate something of their (often) hard work.

I disagree. 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 (using a Trigger event with error_occurred in it ;) ). In fact I have done this on a GM program. This way you can style your error message the way you want and e.g. write on the error message "please report this to [...]". This can look much more professional than the default GM error message. When writing large programs, never automatically assume it is error-free. Especially not if it has to handle a lot of user-generated content. So if you want a polished product, the ability to create a polished error handling system for it, for just in case, is, to me, a very big plus.

So, Hide error messages should stay.

And also I think I have encountered a bug in the error system twice, that I could find only by looking at the error in game_errors.log, because both bugs gave a normal error message followed by a series of access violations (yes, GM is not bug free as we all know). Although of course the solution to this is to fix the error system (assuming it is the cause of the two bugs). Those bugs have been reported to YYG's bug system a while ago already by the way.

ts a one-stop setting of a certain sub-image and telling the instance not to animate: one command instead of two. Sounds like a good decision to me

I don't think it's a good idea to recommend a deprecated (and undocumented) function, because sooner or later this will be removed from the program. I think it's much better to learn the right way, even if it's one line longer. (Woo. One whole line. Disaster. ;) )

But I don't really care either way.
  • 1

#59 Revel

Revel

    ɹǝqɯǝɯ ɔɯƃ

  • GMC Member
  • 4922 posts
  • Version:GM8

Posted 27 January 2011 - 08:57 PM

Built in variables: You already said beginners use them, so maybe have an option to disable them.
Treat uninitialized variables as 0: This is TERRIBLE programming practice and should be removed. Beginners need to learn that programming involves careful variable declaration and usage. Otherwise, if this feature wasn't removed, whenever a variable was initialized via this system, it could have a "flag" on it saying it was declared via the system and could produce a warning to the programmer saying that it hasn't been declared manually.


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

Posted Image
  • 2

#60 FunnyGames

FunnyGames

    GMC Member

  • GMC Member
  • 362 posts

Posted 27 January 2011 - 08:58 PM

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).
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users