Jump to content


Photo

Game Maker Suggestions


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

#991 paul23

paul23

    GMC Member

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

Posted 26 January 2012 - 12:04 AM

I've never been a fan of dynamic typing. Weak typing is nice, however when a variable changes it's type of their life I frown upon that heavily. Just a trivial example of a "bug":

var i, s;
i = 10;
s = random(1000) < 1 && "hello world";
s += i;
That's a 1 in 1000 chance the program will crash.

You can crash a program the same way with or without this feature, and this feature can exist with or without dynamic typing. It's a completely separate issue.

Well the problem is how the error may be reported.

With such a feature, the crash occurs at the "s += i" - line 4. Yet the actual bug is in the s = random(1000) < 1 && "hello world"; - line 3. Here the lines are directly below each other, but with these features you'll always have subtle cases where things may crash, making it much more difficult to track the bug down to the correct line.
When to operands of the && operator are forced to be "convertable to boolean", the above example would crash at line 3.


Well sure it's not deal breaking, but I'm not really seeing any advantage of such syntax? Especially if a ternary operator is added I don't see any use to this - well only thing would be if the left side operator is an expression with a side effect...
  • 0

#992 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2463 posts

Posted 26 January 2012 - 12:59 AM

Your "bug" and its "problems" with error reporting are 100% independent of both short-circuit evaluation and value propagation:
var i, s;
if (random(1000) < 1) s = true
else s = "hello world"
s += i
There are plenty of much more realistic situations where the cause of the bug is not on the reported line; just because you can write a sample with that problem that just happens to use a feature doesn't mean the feature is in any way to blame. In fact, you can't even really blame it fully on dynamic typing, as the same thing can happen in statically typed languages.

On the other hand, I have already given several examples where value propagation is more concise:
foo = argument0 || default_value // default values when an argument is null
bar = do_something() || handle_error() // also when some operation fails
if (baz != 0 && some_condition(qux / baz)) // checking before performing an operation that can error
There are more that may or may not apply depending on other changes, such as checking if an array index exists before using it, etc.

Edited by Rusky, 26 January 2012 - 01:01 AM.

  • 0

#993 Gamer3D

Gamer3D

    Human* me = this;

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

Posted 26 January 2012 - 06:48 AM

It would also be nice if ds_lists were implemented as doubly linked lists internally instead of normal arrays (i.e. vectors). Index-based functionality would still be supported, for the new programmers, but it could also support iterators which are much more efficient.

I created my own version of doubly-linked lists not too long ago, using constant-sized ds_lists to represent list nodes. They were much more efficient than ds_lists in everything except adding to the end, which I eventually realized is because if GM's arrays are vectors, they double in size whenever they reach the end, whereas my methods require new allocation for each new node. Still, everything else was orders better, so...I think it should be implemented "correctly" (i.e. in a more standard, generally more efficient way).


Many people use lists as pointers to arrays (random access). Perhaps it would be better to change the implementation, but to add a set of ds_vector functions (or a class, if classes are added).

Some of the current data structures should have their current implementation overhauled. For example, I have written GML that replicates the ENTIRE set of ds_priority functions, and runs 10x faster on average than the built-in functions (~31000 elements). The DLL averages 120x faster on the same data set (includes the time required to determine whether input/output is string or real) (Mine: log n) (Built-in: n). If used properly, the DLL is faster than built-in for 32 or more elements.

GM seems to use the most naive method for managing priority queues (An unordered list, with finding/deleting max/min handled using a picking algorithm)
A better solution would be to use a min heap (or max heap, if people check the max more often than the min). The finding of the other one (min or max) can still be done using picking algorithms, but problems arise when changing or deleting random elements.
Best solution: Min-max heap. This is what I did. O(1) for finding min/max, O(log n) for adding/deleting. Care must be taken when editing/deleting a random element, but if its position is known, it can be done in O(log n)
  • 0

#994 Boreal

Boreal

    C++ Wackjob

  • GMC Member
  • 417 posts
  • Version:None

Posted 29 January 2012 - 06:39 AM

I don't know if this has been said yet or not, but we need the option to disable collisions/speed updates/automatic stuff for certain objects. Does a controller really need to be included in collision checks?
  • 0

#995 Big J

Big J

    GMC Member

  • GMC Member
  • 2841 posts
  • Version:GM8.1

Posted 29 January 2012 - 07:02 AM

The overhead for updating all the variables of 1 object is probably negligible compared to everything else that the engine has to do. Aren't controller objects usually made without a sprite? In that case, they would probably be excluded from collision checks. However, since I actually don't know, this post cannot be taken at face value because it is merely speculation. :P

Edited by Big J, 29 January 2012 - 07:03 AM.

  • 0

#996 falconfetus8

falconfetus8

    GMC Member

  • GMC Member
  • 38 posts
  • Version:Unknown

Posted 05 February 2012 - 04:09 PM

For the debugger, we already have the ability to exceute code one step at a time. However, this is useless when trying to solve many bugs. What we need is the ability to execute code one LINE at a time. This will make solving bugs dramatically easier, and cut down much of the trial and error involved.
  • 0

#997 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2463 posts

Posted 05 February 2012 - 04:37 PM

That's already planned, and available in GM:HTML5.

Edited by Rusky, 05 February 2012 - 04:37 PM.

  • 0

#998 falconfetus8

falconfetus8

    GMC Member

  • GMC Member
  • 38 posts
  • Version:Unknown

Posted 08 February 2012 - 10:58 PM

That's already planned, and available in GM:HTML5.

Sorry, but who exactly were you replying to?
  • 0

#999 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 12 February 2012 - 08:13 AM

I have a couple suggestions to improve the language: if_with & return_with. As the names suggest, these will allow you to do an if then statement or return a value from a function while setting the scope, temporarily, at the same time.

For example, say I have an Object1 instance that has a script which will return true/false depending upon some condition which must be checked real-time. Right now, in order to do a conditional based upon that value from outside the scope of Object1, I have to take a rather verbose approach:

var temp;
with(Object1) temp = script_name();

if(temp){....}

The need for useless intermediate values and verbose code can be done away with by combining the if & with statements into one:

if_with(Object1,script_name()) {...}

of course, if_with is not exhaustive and could be improved with a return_with statement. For instance, say I needed to do a conditional using values from scripts using variables from different instances? I could make a bunch of temporary variables to store the values or I could have the much nicer return_with approach:

if(local_script() && return_with(instance1,another_script())) {...}


Still better yet, I would love to see a "->" operator, like in c++, which would essentially serve as a quick with statement. It would set the scope to the variable indicated on the left for the variable/script indicated on the right. Like so:

somevariable = someinstance->evaluate_script();

someinstance->do_function();

This would be an incredible improvement to the language for those of us who know how to program outside of GML.
  • 0

#1000 Dark Matter

Dark Matter

    RPG Expert

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

Posted 12 February 2012 - 06:08 PM

This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...
  • 0

#1001 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 12 February 2012 - 06:13 PM


This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...


I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.
  • 0

#1002 kikjezrous

kikjezrous

    Seer of Spaaace

  • GMC Member
  • 636 posts
  • Version:GM8.1

Posted 12 February 2012 - 06:35 PM

Give us screen_gamma() back!!!
  • 0

#1003 GStick

GStick

    All Secrets Exposed

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

Posted 12 February 2012 - 06:58 PM



This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...


I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.


I would just rather scripts be treated like methods.
  • 0

#1004 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 12 February 2012 - 08:10 PM




This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...


I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.


I would just rather scripts be treated like methods.


Indeed! My "->" operator idea would essentially do this.
  • 0

#1005 GStick

GStick

    All Secrets Exposed

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

Posted 12 February 2012 - 09:44 PM



I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.


I would just rather scripts be treated like methods.


Indeed! My "->" operator idea would essentially do this.

Sort of. From what I gather from your idea, it would essentially just allow you to know the exact scope of your script, being local to the object... but that script is actually still a global entity because you can apply it to any object...

obj_player->do_kung_fu();
obj_wall->do_kung_fu();

// both of these would applicable?

Similar idea, but also... what if that script wasn't meant to be used locally, and you weren't thinking straight?

obj_wall->not_local_script();

I would just prefer to have scripts that are only local to the object and can be inherited, or not. Public/private would be nice but that's a bit different.

// do_kung_fu() can only be used by obj_player
obj_player.do_kung_fu();

// this will result in a compilation error / "code-time" error in the editor...
obj_wall.do_kung_fu();

  • 0

#1006 Big J

Big J

    GMC Member

  • GMC Member
  • 2841 posts
  • Version:GM8.1

Posted 12 February 2012 - 09:47 PM

This is how you do it in Game Maker:
with (instance)
{
    script();
}
That's because GM's language loves doing things differently than other languages, even if it completely sucks. :D

I'd like this:
instance.script();

I also want ++ and -- for incrementing and decrementing, and % for modulo division like in "real" languages.

Edited by Big J, 12 February 2012 - 09:48 PM.

  • 3

#1007 kikjezrous

kikjezrous

    Seer of Spaaace

  • GMC Member
  • 636 posts
  • Version:GM8.1

Posted 12 February 2012 - 10:02 PM

+1
  • 0

#1008 Gamer3D

Gamer3D

    Human* me = this;

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

Posted 12 February 2012 - 11:17 PM

I'd like this:

instance.script();

I prefer this to -> for localizing scripts. C++ reserves -> for combined dereference and element access. "a->" is more or less equivalent to "(*a)."; I'd suggest reserving it too, so the language doesn't need to change if pointers/references are added at some point.
Anyway, I think the whole a.script() is a good idea. It'll get people working with this, so when GM adds scripts as elements of objects, it'll be an even smoother transition.


I also want ++ and -- for incrementing and decrementing, and % for modulo division like in "real" languages.

Seconded. It's occasionally annoying to type % and remember that I need to use mod, but ALWAYS annoying to have no increment or decrement operator.
  • 0

#1009 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 12 February 2012 - 11:54 PM


I'd like this:

instance.script();

I prefer this to -> for localizing scripts. C++ reserves -> for combined dereference and element access. "a->" is more or less equivalent to "(*a)."; I'd suggest reserving it too, so the language doesn't need to change if pointers/references are added at some point.
Anyway, I think the whole a.script() is a good idea. It'll get people working with this, so when GM adds scripts as elements of objects, it'll be an even smoother transition.


The reason i suggested "->" versus just "." is because everything in GM IS essentially a pointer. You don't work with instances, but instance "ids" - which tell GM where that instance is in memory. And any variable holding an instance id can be set to another instance id, just like a pointer!


I also want ++ and -- for incrementing and decrementing, and % for modulo division like in "real" languages.

Seconded. It's occasionally annoying to type % and remember that I need to use mod, but ALWAYS annoying to have no increment or decrement operator.


Thirded! I especially miss the ++ and -- operators :(
  • 0

#1010 zekew11

zekew11

    GMC Member

  • GMC Member
  • 15 posts
  • Version:GM8

Posted 13 February 2012 - 02:04 AM

Two Suggestions:

1: If a mathematical function is not possible (ex: division by zero), then, instead of an error, GM returns "null"
2: Object tagging; in an object's menu, a user can add tags to that object. These tags can be used to reference any object with that tag. for example, If I had 3 monster objects, and a bullet that should fly at the nearest one, I could tag all my monsters as "foe_tag". I could then write, in the create event of my bullet: {direction=point_direction(x,y,foe_tag.x,foe_tag.y)}
  • 0

#1011 Silver Scratch

Silver Scratch

    GMC Member

  • GMC Member
  • 166 posts
  • Version:GM8

Posted 13 February 2012 - 04:40 AM

These four ideas might be stupid, but here we go.
1.)Add encypting and decrypting functions. I know xot made them in GMLScripts but it would be nice having it in Game Maker itself to protect our data some how.
2.) I was thinking that in "Debug", There should be options that shows arrayed variables. Like "Global Arrays" and "Local Arrays" so we can see what is going on cause we can't see if our arrays are getting the right information.
3.) Make the dialog box appear in the directory you want. get_openfilename(startdir,i 4got what it said here,and here) and if you want to start at "my documents" let there be a way to do so! :) This will help alot since the creators of some games put the game in "Program Files" and it would be nice to appear in another directory.
4.) Make more drawing shapes. This would be nice for effects like shooting starts. draw_star(x1,y1,x2,y2,outline), this would reduce some sprite usage. Star, diamond, trapezoid. Maybe some that others might request. Oh! and make it there be a "width" for the drawn shapes. Like draw_line_width but in the shapes. draw_rectangle_width(x1,y1,x2,y2,outline,line width) this would be more usefull when drawing stuff like a menu that clearly shows its boundary.
Just some suggestions since i have no good reasons :(
Edit:
I agree on making a better way to put tiles! Like a shape for the section you want. Maybe we might be "copying" from another maker but it is really useful.
  • 0

#1012 GStick

GStick

    All Secrets Exposed

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

Posted 13 February 2012 - 04:48 AM

2: Object tagging; in an object's menu, a user can add tags to that object. These tags can be used to reference any object with that tag. for example, If I had 3 monster objects, and a bullet that should fly at the nearest one, I could tag all my monsters as "foe_tag". I could then write, in the create event of my bullet: {direction=point_direction(x,y,foe_tag.x,foe_tag.y)}


Creating a parent object solves this issue already. Create an object foe and make that the topmost parent for enemies.
  • 0

#1013 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 13 February 2012 - 05:43 AM

OH!!! There needs to be an object_set_name() function so that GML defined objects can have names associated with them. Its not nice seeing all your instance variables in the debugger having the name "_newobject7" or something like that.
  • 0

#1014 paul23

paul23

    GMC Member

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

Posted 13 February 2012 - 07:15 AM



I'd like this:

instance.script();

I prefer this to -> for localizing scripts. C++ reserves -> for combined dereference and element access. "a->" is more or less equivalent to "(*a)."; I'd suggest reserving it too, so the language doesn't need to change if pointers/references are added at some point.
Anyway, I think the whole a.script() is a good idea. It'll get people working with this, so when GM adds scripts as elements of objects, it'll be an even smoother transition.


The reason i suggested "->" versus just "." is because everything in GM IS essentially a pointer. You don't work with instances, but instance "ids" - which tell GM where that instance is in memory. And any variable holding an instance id can be set to another instance id, just like a pointer!


That's actually bad reasoning: first of all in gm everything is a HANDLE, not a raw pointer. And actually it is more similar to a reference than to a pointer. Secondly - why should a "->" be used? You know that language like JAVA also always use references for their objects? And they use a "." sign.
  • 0

#1015 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 13 February 2012 - 07:39 AM

That's actually bad reasoning: first of all in gm everything is a HANDLE, not a raw pointer.


All a pointer is is a number that corresponds to a place in memory. Hence why in C and C++ you can use the arithmetical operators on them (like ++). True, a "Handle" is probably a more correct term when referring to things like the the ids that are passed back when you create a GML data structure, but this is not so for a numerical variable pointing to an instance of a custom object - you don't have to pass the pointer to gml functions in order to manipulate the instances.

And actually it is more similar to a reference than to a pointer.


You have somewhat of a case for a handle, but not for a reference. References are like 'permanent pointers' - you CANNOT have a reference variable that points to one spot in memory and then switch what it points to. You CAN however do that with a pointer or with a numerical variable in GML.

Secondly - why should a "->" be used? You know that language like JAVA also always use references for their objects? And they use a "." sign.


That's just it - they use references, not pointers.

Edited by iam1me, 13 February 2012 - 07:44 AM.

  • 0

#1016 Big J

Big J

    GMC Member

  • GMC Member
  • 2841 posts
  • Version:GM8.1

Posted 13 February 2012 - 08:25 AM

It's easier to type a dot. Besides, that's how Java does it.
  • 0

#1017 kburkhart84

kburkhart84

    Firehammer Games

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

Posted 26 February 2012 - 07:56 PM

I've mentioned particles in this topic before, but I have another suggestion that would be really nice.

I know some people are downing the particle editor itself as part of the GUI. I myself would like to see that, but not only that.

I would like to see particles(either code or editor based) be much more capable. Instead of either 1/2/3 color and alpha settings, would it not be better to have an actual gradient, with many more "stops" defining colors/alphas. Even with defining 3 colors, since we can only define the color, not the "gradient position" we can't say that the first 10% is the first color, then the other two colors, rather it is only beginning/middle/end.

How about using a "sprite" emitter. If 3d engines can emit from 3d models, why couldn't we emit particles from sprites, specifically the non-transparent sections. This would be great to create random shapes of flames, etc... among many other uses.

With Box2D coming into GMStudio, than the GM9 version of GMStudio could provide the full physics simulation for particles as well, which could then turn into the fluid simulator of sorts, though maybe not on that last step. This would also make the deflectors more useful, because particles could actually "bounce" around instead of just changing direction.

Of course, this type of thing is probably easier to create/modify with an in GUI editor instead of code. The reason code has worked fine so far for particles is the limits they have.

***

And about the '->' versus '.' bit, I think the dot is plenty. The '->' in C++ can be confusing to beginners as too why that instead of the dot(for pointer to objects/class instances for example) but for GM, that will be confusing. The simple '.' is all we need to simply execute a script "from the object", but that is what the "with" construct is for. The dot would be a welcome addition, but is not really adding functionality in this case.
  • 1

#1018 Rexhunter99

Rexhunter99

    GMC Member

  • GMC Member
  • 922 posts

Posted 26 February 2012 - 10:40 PM

It's easier to type a dot. Besides, that's how Java does it.

So by your reasoning, because Java does it so should all other languages? Because Java forces users to put super(); in their constructors of objects, Game Maker should force users to put super(); in their create events? I don't think so, C/C++ set a programming language standard that C# and Java follow, the topic regarding '->' is about making things more fluid for experienced users who are constantly getting mixed up after going back and forth between languages, which I am sure that YYG are quite familiar with, having worked on a C++ runner and the Delphi Runner and obviously testing these things out in GML after updating the engine.

I am incredibly familiar with the issue being discussed and while it does not break anything in regards to development of a game withing Game Maker, it is incredibly frustrating, especially for DLL developers using C++ like myself. Working on an OpenGL wrapper for Game Maker (for educational purposes mainly) I am constantly making the mistake of using % instead of mod, ++ instead of += and -- instead of -= among other things, I have even caught myself using pointers, haha, it's the same for functions but it is typically easier to catch out several sinf()'s than dozens of the aforementioned things.

Edited by James_ogden, 26 February 2012 - 10:46 PM.

  • 0

#1019 Big J

Big J

    GMC Member

  • GMC Member
  • 2841 posts
  • Version:GM8.1

Posted 26 February 2012 - 10:49 PM

My bad, I should have said that Java and C++ both use the dot, because they do. The point is, typing a dot is easier and makes more sense.
  • 0

#1020 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 27 February 2012 - 01:15 AM

My bad, I should have said that Java and C++ both use the dot, because they do. The point is, typing a dot is easier and makes more sense.


There is a fundamental functional difference between a dot and "->" - the dot is used for normal variables/references, and the "->" is the combination of dereferencing and the dot (ex: (*myptr).function();). The reason Java doesn't use "->" is because pointers aren't part of the Java language.

Furthermore, "->" is more appropriate for GM since everything in GM, apart from the variables used to hold numerical data in of itself and those variables which serve as handles to data structures, is essentially a pointer. Any variable that holds an instance id IS functionally a pointer - not a reference variable. "->" is plenty easy to understand for programmers and makes more sense to them.

Finally, as has been pointed out, the use of "->" would be an addition for advanced users - beginners can stick with their D&D.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users