Language features...

So at what point do language features become a hindrance? Well having learnt using BASIC, I know what the features of other languages has allowed me to do. SO lets have a little lookie and see what these features have added.

First up: TYPES.

I remember coding on a ZX Spectrum and being incredibly jealous of the BBC as they had INTEGER variable types. This option allowed your code to run MUCH faster than using the standard floating point number variable. Now, back then ALL floating point code was done through emulation and so was much, much slower. Nowadays, doubles (which is what Game Maker uses) is all done in hardware, so why do we care? Well first, it's not always done in hardware, so we're back to the CPU doing emulation and that's really bad. In fact, even is we're doing this on a machine with hardware for doubles, integer computation is simply faster, what with the multiple execution pipes and single cycle execution on most hardware, if you can do it in integers, you should at least have the option. After all, how many FOR loops really need floating point? Lastly... How much would this really affect folk who don't care? I'd argue not much. For example...

   i = 1.12;
   b = 12;

compare that to something like...

   INT  b;

   i = 1.12;
   b = 12;

I'd say if you don't want to use them, it's not exactly going to bother you, but if you want to declare the variable (with INT, DIM, VAR or whatever we end up using), then you will not only get a speed boost, but it'll help you debug your code because you KNOW it can't be a fraction! That can be a valuable bit of info.
Second: STRUCTS

I'm wondering how I can even begin to say how important this is. Lets give a couple of examples. (this isn't proper code, so don't jump on errors please!)

    BaddieID[i] = id
    BaddieGridX[i] = round( id.x/16);
    BaddieGridY[i] = round( id.y/16);
    BaddieType[i] = enemytype;
    BaddieParent[i] = id.parent;

Now, in this little sample, we need multiple arrays to deal with storing all the bits of information I need for processing later. This is pretty common when coding and having multiple, dynamically resizing arrays is a nasty thing. So what can we do to improve this? Welcome to the world of structures.

   struct SBaddie{
      id,
      gridx,
      gridy,
      type
      parent
   };
   
   baddie.id = id
   baddie.x =  round( id.x/16);
   baddie.y = round( id.y/16);
   baddie.type = enemytype
   baddie.parent = parent;
   
   Baddies[i] = baddie;

(I'm deliberately avoiding adding any types here... but you can do)
Now... how I'd hook all this up is unclear, but having a single object (much like a standard, but very lightweight Game Maker object) with variables you can access can mean you can contain data in a single packet. This means you no longer have lots of dynamically resizing arrays (which is always a good thing), but if we are to expand what can be passed into functions, it also allows you to pass a lot of data in a single blob, removing lots of parameter stacking. This is all good, not only from a performance standpoint, but simplifies your think about about variables you're dealing with. No longer are you thinking about lots of individual variables, remembering which ones do what, you now have a single variable with all the information you need and this again simplifies your work.

Structures are good. Structures are VERY good.


Third: FUNCTIONS.

Being able to breakup large functions into smaller common parts is nice, not just from a readability standpoint, but for allowing you to reuse code better. It's a very good skill to learn; making code general so you can use the same function over and over again. This not only teaches coding flexibility, but allows you to start to make an API for certain features. Good APIs are a real skill, and one thats vital to learn if you ever want to progress as a coder. All that said, if you don't really care about coding and it's simply a means to an end, then being able to break your functions up does make code just simpler. Having a function that is pages and pages long is horrible to maintain, and will introduce bugs, so this would also help you reduce bugs as each function is smaller, and easer to think about. So again, its another good one.

Fourth: CONSTANTS

Simple one. PROPER constants. This is mainly an internal thing... but allowing you to define them in code would be great.


Now... I'd also say there are features that would just confuse most folk so we should just avoid them. Things like anonymous delegates, the C++ << style operator, operator overloading, templates, and even to some extent #defines; these are all simply not required inside GML. While I do like #defines, I think they can be so badly used, I'd simply avoid them.

EDIT: Oh... and the other thing I'd LOVE to add; argument passing to the instance_create(x,y,obj) function. This would be brilliant. This would allow you to do stuff like this...

    w = instance_create( 10, 10, cBullet, "smallbang.wav", false, sSprite );

I could have used this quite a few times already....

To GML or not to GML...

So... I've been idly thinking... If I had bags of cash, oodles of time, and free rein, what would I do? Well, before I say ANYTHING else, this is nothing to do with YoYo. While its obviously been discussed, we haven't decided anything, and much of what I'm about to say goes against the basics of what Game Maker is all about! So don't get too excited/angry. Now that that's out of the way... what would I like to do? Like? No...LOVE to do...

Well, first... I like GML for what it is. A very simple scripting language. It does what it says on the tin (as it were), and that's a great achievement in itself. What I don't like about it, is that the syntax is a little woolly, and you can't declare types or sizes upfront. This has a huge baring on performance and what you can do to optimise the engine itself. So first and foremost I'd allow types. ints, bytes, shorts, floats and doubles along with strings and fixed size arrays (I think lists should grow, arrays shouldn't; personal preference). Not only are these things which would help you develop your skills, but it also helps you track down bugs. For example, I have an array 16 elements long, but I have a bug that touches element 4000! Currently, the array simply expands and it's hard to track down. However, if I knew it was only ever supposed to be 16 entry's long, I could set that as a fixed array then I'd get an out of bounds exception and hay presto! Bug found!

Next on my list would be structures. BLOODY HELL!! I MISS STRUCTURES!!! So many times in the past few months as we've started to push game out, we've needed to fix a bug, or add a little feature, and I've though, "well, just have an array of x/y coordinates, possibly an index to an object and then a type", only to actually realise.. I'd have to have multiple arrays for this. This is crap. So... Arrays next would be awesome, particularly when merged with real types.

Next up... I'd like objects to have custom functions you could call. So rather than having a script where you pass an object in, you call the objects function directly like so...

     Player.SetHealth( 100 );

This is nicer to me, and would help teach some basic skills you could use as you learn and perhaps want to move into other languages. So it's a plus to me. Not that you couldn't keep the current script method where you pass stuff into it, but I prefer this, it reads better to me, and keeps the code bound together with the object that it affects.

Another thing I'd love to add is the ability to have functions inside a single script. For now if you want a new function you have to declare it in the scripts section. Again, I think this is okay, but you lose the context in which you would probably use the function. Although using the new object function feature above would allow something like this, it still means jumping back and forth in source files for a single function. It would be much nicer if I could simply declare the thing; something like...

BaddieObject  FindBaddie()
{
   //Do something
   return the_baddie_object;
}

bool MoreBaddies()
{
   // anymore?
   return answer;
}


main()
{
     //Do stuff...
     while( MoreBaddies() )
     {
         baddie = FindBaddie();
         baddie.die();
     }
}

Now... technically... you don't need main(), we could just detect your not in a SUB function and do all that for you... so it would look like...

BaddieObject  FindBaddie()
{
}
bool MoreBaddies()
{
}


//Do stuff...
while( MoreBaddies() )
{
   baddie = FindBaddie();
   baddie.die();
}

Which would be okay for beginners I think. I suspect the real GOAL of GML should be to make it open to beginners, but allow for experts to excel in it.

Now what else would I add? Well...I'm a MASSIVE C# fan, so I'd love to add the ability to call .NET stuff. Not only would this open a fully functional plugin system (in both directions!), but would mean we could drop support for things like GML stacks, queues, lists etc. as .NET already has really cool ones.

But what about this plugin thing? Well. allowing plugins to see into the main program via .NET interfaces or reflection would be massive. You could suddenly get access to the entire rendering engine, the variable system, rooms, instances etc. ALL done legally via a simple C# style interface. Not only would Plugins become much simpler to do, but their power would be immeasurable! The whole of Game Maker could then be done as a series of plugins.

Yes I know... veered slightly away from GML, but it's all related. Still, all this is my little fantasy world. Not only would we have to make sure Marks vision of a learning tool is protected, and that everyone else agrees with the direction. We'd also have to make sure we had enough cash to be able to do it justice, and not a half arsed attempt that would alienating the whole community.

So... not quite yet then... Oh well. Perhaps I'll do another post soon on what I'd like the graphics engine to actually be like. We lose so much performance because of the simplistic interface, a more comprehensive one would allow proper throughput and would probably even allow real 3D stuff to be done; not that I'm a fan of turning Game Maker into a 3D tool though....