Exactly piers.
Piers uses GM, with his rational justification, (in the way that the first post by Fish noted).
He isnt claiming things which arent true based on limited knowledge.
Dont take (most of
) this post as a bash against GM. Im stating
Quoting Scooternew. Sorry man. Nothing personal of course. However
:
{
Yes, maybe higher level languages give you bragigng rights and require more skill
Lower level.
GM = Uber High level 'language'.
but I don't see the point in writing thousands of lines of coding, which takes months and months, rather than having nearly as much capability, maybe minus some speed here and there, the second you want to
A programmer can mix up a good enough engine for a 2d fan game in 2 days, although it'd lackcertain things.
Still, a month for one thats many times faster than gm, allowing many more effects and is far easier to use, is fine. Esp as it can be used again and again. Alternatively, download someone elses and get started...
Consider:
Sprite spr("meh.bmp",16,16);
spr.Draw(0,0,5);
Wouldnt take months as long as class Sprite already exists, and unlike GM....memory leaks wouldnt be a (noticable) bonus feature.
Again, think about creating a base engine for walking. It could take weeks or months in C++, but it could take 20 miuntes in GML. Neither with any speed loss.
As before for the time. Speed loss? try 500 frames per second loss (not that i let games run at that speed, just that with nothing but a walking player they can).
time. Not everyone has infinite time at his/her fingertips.
Programming languages are the solution to this problem.
With standard abstract container libraries & algorithms (functions and functors acceptable as parameters to a function: equivelant to having a variable of code), and object orientated concepts, not only can the final layer of a program appear simple and more in tune with human nature, but it can be created in less time, and be much safer and more reliable, not to mention re-usable.
These kinds of shared code benifits can be done with scripts, but well, then its harder, and not as easy to read (othr than for those who dont know what a,b,c do).
I applaud those who have the time and patience to write an engine from scratch, but I think it is against humanity to have to work that hard on something for 7 months that you can also do in 5 minutes.
I point you to me and the two weeks i spent on a game in the 2005 game comp, using opengl and win32 api. Two weeks. Not 7 months.
Takes 7 months to learn how to do it, not to actually do it. And once youve done it one or two times, maybe what youve made is as you desire, and you wotn have to do it again for a great deal of time, at which point you can program games faster than a GM user, whith a great deal of abstraction towards reality on your side to make things extra easy.
Again, Game Maker only puts out crappy quality based on the quality of the creator's programming skill.
C++ is my favourite language. It has this problem itself, and its very easy to make a bad program with, and write very horrible code with (format is. Thats what makes it so pleasurable to write efficient and readable code. But you have a notable point there. The product should be judged, not just the time, memory abuse, and long term affects on the users mental state
. Although a well made GM game would still suffer waste of memory and limited framerates, the target user wouldnt be that bothered. Like Java games on phones (although the speed and compatibility benifits there saves lots of money )
tend to think that Game Maker programmers are too stupid to program quality, efficiently-run games. Unfortunately, this isn't true, and I don't always love the patronizing
'efficiently-run' cannot be done in GM any easier than it can in C. DLLs...otherwise efficiency is a sacrafice of using GM.
People who know c++ decently but GML much better might prefer GML, and make better games because of it
Then their meaning of 'decent' is skewed, IMO; Or they think they know more than they do, which can common with people who expect to jump straight into media handling and try allegro or sdl right away after something like gm. Theres alot of practice nessecary to reach a stage of understanding in how to maximise the state of both a program/library and its code for developing significantly sized programs.
You want to choose between a gas station automatic car wash or a hand car wash
Changing your analogy to suit my comments: You want to choose between an auto car wash with one setting, or making your own with several settings and using it as it, right in your garden where that rose bush used to be.
}
only a bloody fool would say you arent limited in GM.
I say, one with child-like ignorance ( Only children grow up ).
Are you saying that if you have a variable named 'pants' somewhere in your code, and then you dimension a second variable named 'pants' in another subroutine, and you change the value of the second 'pants', you will change the first one as well?! That would be a terrible nuisance!
Seriously? oooooooommmmmmmmfffffffffffggggggggg.
-Part of me just died.
Usefull, but implemented in such a horribly careless and unconsiderable manner.
If you dont want to make things yourself, you could avoid the limitations of gm and use a blitzbasic language.
Some Limitations in its oop (Why no privates? Who many seconds could it take to implement that in the comiler? >~< ), but not too long to learn if your eager, and you get the efficiency you want.
I aknowledge the usefullness of GM.
The limitations are there. It is =>usefull to some and not to others. I dont find it from my view usefull for some programs and not others, as with enough pre-written code i could always get games of even tiny size done quicker. Still, Its a practical tool for, say, PC tetris or pac man even where someone can work in a lower level language.
