One thing that I find a lot working at YoYo games is the disrespect GameMaker's built in scripting language (GML) gets. You see it all over the various forums, and in responses to glog entries, that if you really want to make games, you should learn a proper language. This does annoy me, and I'll explain why in a moment... First, I want to explain where I've come from in terms of games, programming and how I got to where I am today.
So, when I was around 13 a friend of mine got a ZX81 and we'd sit and play games, type in programs from magazines and on occasion try to make the computer do what we wanted it to do. Later, I bought the ZX81 from him and would make little games at home in BASIC, and then started to learn Z80 assembler. I then progressed to the ZX Spectrum and wrote a database for a solicitors office using Sinclair BASIC, and the progressed to the Commodore Plus4 where I wrote a few games in a mix of assembler and BASIC. Eventually I progressed to full assembly programs and moved onto the Commodore 64 and my first job at DMA Design. While writing Ballistix and Blood Money I learnt Pascal and wrote several tools on the PC for development, and when I progressed to the PC Engine and its 65c02 assembler, I again wrote many tools in Pascal, including a full (and very powerful) remote debugger. The same goes for the SNES and 65816 assembler, while all it's tools were in Pascal on the PC. While coding on the SNES I started to learn x86 assembler on the PC and did lots of game stuff in Pascal and x86, including the prototype that lead to GTA.
I then moved onto C and used x86 for all rendering stuff, and eventually SIMD and C++. I did lots of JAVA here including mobile phone J2ME and Java Applet code, including some Java Virtual machine assembler (if you can believe that!). I then did PS1 and PS2 C, and learnt some MIPS assembler while also playing with the Gameboy advance and it's ARM assembler. At home I was also doing some Dreamcast stuff and some SH4. These days I hardly ever touch x86 assembler and it's mostly C/C+ or C#.NET, although I'll probably do some Delphi pascal again soon. There you go... a pocket history. I've missed loads out (particularly home projects), but it's pretty close.
So... Why do I bring all this up? Well, you can see that I've progressed through many languages and use whatever is appropriate. On the PC where the machines are fast (these days), I don't need to dip into assembler any more, while on the PSP I'll happily drop down to MIPS assembler again.
So what makes a language? Well, you have variables, loops, branches and function calls. In more object orientated languages, you also have objects you can access, but these certainly aren't a requirement. Old machines like the C64 or spectrum didn't have them, and they managed quite well without all that. You just arrange your data differently, but it's all pretty much the same thing.
GML has all of this. The loops and branches are there, as are variables and function calls. In every important respect, it's a full language. Some might even say it's much nicer to use as you don't have to worry about lots of things and it makes it much simpler to throw things together. There are lots of ways to write games, I used to write in BASIC as did many others, some still do. There's plenty of jobs around for Visual Basic programmers, so this is definitely a proper language, but I would never write a game in Visual Basic. I would use a language better suited to making a game. GameMaker gives you LOTS of tools and support to quickly make games, just like many other game making tools do, but very few pull everything together for you into such an easy to use package.
So to put this in context. There IS no professional language. You use whatever you must in order to make the application or game you want to make. If you make a game or application, and you sell it, then it's a professional language, it's that simple. There have been many games created and sold that were done inside GameMaker, and there will be many more. If you make a Tetris game, can the end user tell that it's written in Game Maker? Would they care? No of course not... If your talking about a game, then the end user just wants to have fun and only cares about if your application delivers that.
Now... if you want to make a game for console, then Game Maker might not be the right tool - yet!! But that may well come, then you'll have a much wider choice as to what the right tool is.
In the old days we used to mock C programmers for using slower languages than assembler. We could do at least twice the amount, but they would develop twice as quickly, and now we hardly use assembler at all! We're getting the same thing with GML. Unless your talking about making Halo or GTA 6, then GameMaker and GML may be just fine. I suspect all 2D games (pretty much) can be done with GameMaker, and a LOT quicker than if you tried with C++ and DirectX too.
So... ignore the requests to learn a proper language. Use what's right for you, and what makes your life easiest.
Tuesday, July 27, 2010
Subscribe to:
Post Comments (Atom)
12 Smart arse replys:
I saw the title of this blog post and thought to myself, "Oh boy, he's having a rant about what I said on the glog." Reading through it though I'm not so sure that it was targeted at me though... You seem to be arguing for the point of view which I've taken. That is the motto of Game Maker, "Easy game development"
GML is definitely a "proper" language, as you say it's got everything a language needs and the games which have been made with it show that it works. The real issue in my opinion though is: is it the "best" language it could be. I'd have to argue no.
I've made 832 posts in the "Novice and Immediate Users" section of the GMC forums (and I haven't asked many questions), so I have a reasonable idea of the issues new programmers have (the users Game Maker is targeted towards).
There are things about GML which are annoying and confuse beginners no end. The biggest of these (IMHO) is the many alternative syntaxes which are supported.
For example:
- you can use = or == for comparison.
- you can use <> or != for comparison.
- you can use := or = for assignment
- you can use {} or begin/end for blocks.
- you can use "global." or "globalvar" for global variables
- you can use "then" in if statements.
- you can use and/or/xor/not or &&/||/^^/! for logic.
This leads to so many arguments about the best way to do things and makes it difficult to help people because they use a different syntax to you. I realise that many of these are left in for backward compatibility and are no longer documented but people keep using them and it doesn't help at all. They just confuse beginners and lead to bad programming practices.
There are other things which are a nuisance to more advanced programmers. One of the biggest of these issues is the support for data structures. Sure they work fine but their overly verbose function names make them painful to use. They would be much nicer as a language feature.
One more thing which makes GML hard to debug is the use of numerical values for indexes. There's no distinction between sprites or objects or fonts or textures or surfaces or lists or anything. This leads to bugs that are often quite hard to find. For example, where you've use a background instead of a texture. It would just take an extra flag attached to these values to have the engine throw you a nice error like "Background index used where texture index was expected." rather than just using whatever texture happened to have the same index as the background.
Don't read this the wrong way. I love Game Maker and I learnt to program through GML, but, there is certainly a lot of room for improvement and some compatibility breaking changes are needed to make GML the "best" language it could be.
One final comment, I'm extremely impressed by the amount of communication we've been getting since you guys joined the team. It's great, thank you for listening!
It's exactly what Dannyboy said. That's why more experienced programmers still see GML as a mess. Even though I respect what Mark made of it over the years, in my opinion it should be dropped at some point and be replaced with a more consistent language (new or an existing one, like Lua). In the end it'll be easier for people to understand each other.
Hi! I'm not a stalker I swear, but would you mind if I could interview you for our gaming site? It is a Kirby fan site, and after looking through your flicker and blog... I just have so many questions. I grew up on the C64, and a Spectrum when I lived in England, eventually I'd be a Nintendo player and run a Kirby site. I just think a lot of people would be super interested in what someone with your experience and background would have to say! If it's okay, I'd love to compile some questions at your leisure or any other way possible =) My e-mail is kindarspirit@gmail.com -- however if you are not interested/busy/think I am actually a stalker haha, I completely understand and would love to thank you for your time.
Thanks for reading my blurb, and take care!!!
I like how you say "A real programmer uses the language best suited for the situation.", which is correct and a completely valid point.
But then, you go and say "GML is the C of the assembly era", the problem with this statement is that it's not.
For one you've contradicted yourself, you've said yourself you still use assembly to this day, as do I for low level programs/functions.
Secondly, the speed margin between C and assembly may be great, but is by no means noticeable to the average eye.
However I dare you to write a 3MB large files, or hell, read a 3MB file in GML. Let me know how long that takes, for me it crashes on a 64bit, quad core (not that, that even matters cause GM maxes out on one core), 2.6GHz, 8GB RAM machine with a decent HDD r/w time.
Even if it does manage to write it it's been well over a minute. Whereas any other language including "novelty languages" such as LOLcode can read/write files larger than 3MB in less than a second or so (file operations have been removed from LOLCode since v1.x).
It's just a little sad that GM is weaker than a novelty language.
To be honest, I don't understand what's there to like about GML, it's a very underpowered, buggy and static language.
If you want to say GML is a respectable language you have to fix a lot of it, can you seriously look me in the eyes and say "It's ok to use # for new lines" or "Crashing while writing a 3MB large file is ok", or "0 and 1 are the same character only in some string manipulation functions, and that makes perfect sense and is in no way annoying."
Oh, by the way, I was looking through the GM runner and turns out you guys have bitmap resources laying around from the GM3 - 5 days, you can cut off about half a megabyte if you remove them, also, if you upgrade to DX9 you should be able to remove the DX8 DLL from the runner, cutting the size down even more (I'm assuming it's stored in there, zipped or otherwise compressed, I couldn't find the DLL in the runner so I could be wrong.)
Anyway, that's just my 2 cents, you can say GML is a programming language, it is, but you can't say it's a good one and you by no means can compare it to a "real" language.
Your completely missing the point. GML on it's own is no where near good enough, and I would never use it like that. But using it with Game Maker and all it's infrastructure makes it far more powerful, and it certainly punches above it's weight when it comes to games.
And to compare speed with C++ is stupid. "Back in the day", C compilers were so crap I could easily out perform them with assembler, in fact I would normally get something 10 times quicker. Langauges take time to mature, and yes... GML is behind and hasn't been given the attention it needs to keep up, but that's something we hope to address. However, that still isn't the point.
It terms of bugs, all languages have bug. Even now I can hit something in a "professional" language then have to work around it. These are reported, and should be fixed. But still, none of this is actually valid.
The whole point of this was to say that if your writing simple games, then chances are Game Maker, and GML would be much quicker than doing it in C++ and Direct X. Game Maker delivers a lot in terms of infrastructure and framework, and that's a nightmare to build up. Hell, back in the early days of gaming folk used to write full games in Commodore Basic, and that's one of the worst languages out there! Peeks and Pokes all over the place! Even early visual basics were terrible. GML at least gives you all you need to write games. Yes its rough around the edges and we hope to address some of these issues as we go forward, but I've seen amazing looking games written from scratch in a few hours. You'd be hard pressed to do that in anything else. So the point is FORGET about it being a "proper language", if you can make a game in it easier than another system/platform, then that's ALL that matters.
As to the runner. We haven't looked into the Delphi runner at all yet (Mac Version aside), but we will get to it. The C++ runner we have been working on has long since been upgraded to DX9, and most of the bitmap resources have also long ago been replaced by DXT textures. One day we hope to replace the Delphi runner with the C++ one as it is significantly faster (we'll be posting some performances metrics soon), so it doesn't make much sense to get dirty with the Delphi one.
On... lastly. Why I "dip" into assembler. As I said, I use what's appropriate when it's appropriate. If some things being called by the C language runtime 10,000 times a second, then it makes sense to make it as FAST as we can, and that means IF we can write an assembler version (and we can't always), then we will. If I thought a well thought out C function would do, I'd write it in C. Our memory management system is called a lot, but I don't write that in assembler because it's fundamentally slow anyway! So why waste the effort and make the code harder to maintain. That's not to say I just write some slow C code, no.. it's very optimal, but I use what's appropriate.
@Dannyboy @Clavus: I'd have to agree that there are some issues with GML syntax, but they are definitely fixable, and we hope to rationalise these in the future. We'd also love to introduce things like function headers and the like because most of the time, this clarifies a function, not complicates it.
However our real challenge is to make these chances and still make GML very accessible to novice coders, while allowing the more experienced guys to really let rip. Mark has some great insight into this kind of thing, and it's going to be fun making it better and better.
However, I stand by what I said. GML+Game Maker may well be the best path for many games you write, simply because Game Maker brings so much more than GML to the table. That said, yes... GML is not ALL it could be, and we'll strive hard (and have great fun in the process!) improving it.
You make some very valid points, I wasn't aware of the state of C compilers back in the late 80s early 90s, seeing as how I've only worked with it since 2005.
Anyway, you mention that GML is a good way to go for rapid development, this is true but at the same time you really have to twist your neck to make a game in GM that's quality and runs smoothly, part of this is the runners fault, another part is the prematurity of GML.
With the creation of GMAPI, if you don't know what that is it's a wonderful extension to DLLs for GM, life is so much easier but it still doesn't change the fact that certain elements of GM can't be changed through a few DLLs.
For instance the sound engine, the game will freeze on loading even if there are no sounds to prepare, though the Mac version loads up no problem.
On top of it taking forever to prepare sounds, entire systems will not run games because they will get the "An unexpected error has occurred" error because they're missing the packages required by the new (post GM6) sound engine. At least, that's what it looks like.
I understand the need to become cross platform but I strongly believe that before you guys can truely continue forward you must take a step back and fix GM4Win.
Personnally, I'm much in favour of scripting languages for games. That favours thinking about the game logic, ease the creation of edition tools / game makers while providing more investigation power (is the tool or the engine buggy when I observe that my game is going wrong).
What would make those languages professional tools is the fact that they're sufficiently well-defined (no magic) and reflecting the "natural thinking" of game development so that professionnals (guys with deadlines and paychecks) find them a booster in the process of making games.
Now, that doesn't make a programmer more of a professional programmer because he masters GML, and that's probably while programmers frown such language while game developers embrace them. If I master GML, that won't help me doing any programming task that is not related to the GM runner, is it ? E.g. it won't ease the building of automated tools for preprocessing game data, nor would it help me bringing up a game server if I decide to move to online game.
It also ties me to the platforms supported by your runner. Will I be able to make games for iPhone or Facebook just by having learnt GML ? The reputation of C/C++/JAVA imho comes from their "Learn Once, Use Everywhere" nature.
As a final checkpoint, to what extent does GML allow me to manipulate complex data structures ? If I need something else than the packaged path-finding algorithm, for instance, or if I need to implement physics on a collection of solids, will I be able to represent what solid interact with who else, or to store the agent's "mental map" of its environment so that it can decide where to go next ?
While some of what you say is absolutely correct, some of it simply isn't. Knowing Java for example won't help me write games on a Nintendo DS, or even an XBox 360, just as knowing ARM assembler won't help me very much on a PC - in fact, knowing Java won't help you do much of anything except chew your eyes out in frustration! :)
You learn a language to help you make a task on a particular platform easy. C and C++ are probably the only global cross-platform languages these days; but they suck (in that they're ugly, and yucky to code in by modern standards).
That said, I totally agree that GML is missing proper data structures. It's very tricky to write clean code without them as your stuck using matching arrays or objects with variable names in them - possible, but horrible.
Oh... but I did have to laugh when you said Java was a "learn once write anywhere" language. I used to write games for mobile phones in Java, and I can honestly say, that was never the case!! JAVA sucks... no, I mean, JAVA suck BIG time! It's slow, clunky, bloated, every version differes and well, it's just plain nasty. I've written Java and Java assembler (direct virtual machine mnemonics), and it's HORRIBLE. Just my $0.02 :)
"""in fact, knowing Java won't help you do much of anything except chew your eyes out in frustration!"""
Yeah, I've had a decent dosage of Java programming too. Knowing Java helps me to appreciate other languages more ;)
I just hope that you and the team can make GML less like Java, or at least not more like Java... A quote from 'The Zen of Python':
"""There should be one-- and preferably only one --obvious way to do it."""
"Yeah, I've had a decent dosage of Java programming too. Knowing Java helps me to appreciate other languages more ;)"
LOL - yeah. I can appreciate that too! :)
"There should be one-- and preferably only one --obvious way to do it."
Yes, agree. Something we will work on over time.
"I did have to laugh when you said Java was a "learn once write anywhere" language"
Good to know I made you laugh ;) Don't take it wrong: I find myself Java too sluggish to express things properly, too heavy to write small tools and I acknowledge issues with versions. Yet, you can't dismiss that whether you want to write a GUI for an image cruncher tool, a dynamic server page for your online leaderboard or some ecclipse plug-in for whatever purpose, it is present there. That doesn't make me love it more, nor does it make it a good language for game programming, but it's definitely more "use everywhere" than my dear PERL. The "learn once" part may not be very true indeed.
I acknowledge as well the fact that both C and C++ are inconvenient to use and fail to "bring you straight to the point". The more I discover C++, the more I can rant about it. I wouldn't recommend them for anything else than core routines (collision checking, etc.), but that doesn't change the fact that they can also be used for converter tools if I'm silly enough to write them at that level of inconvenience.
Most likely, "you need to learn a serious language if you want to program games" is a wrong sentence. You prove it in your initial post. Yet, there are a collection of core properties/usage that distinguish general-purpose languages from others. Admittedly, using the right language at the right place is a smarter move than e.g. insisting on doing games or regular expression parsing in Java.
Anyone attacking GML saying "it is not a serious language" is likely to be thinking wrong (as in "oh, yeah. Maybe you think we should program our games in COBOL or LISP -- these are definitely serious"), and making GML more "serious" would not necessarily make it a better tool for its job.
Imho, it needs to be clean, don't do any black-magic behind your back and have the closest fit to the game logic (state machines, data structures, collision engines, etc.)
HTH.
Post a Comment