gamemake is weak and slowI tried making a bezier curve generator with it, and if you try to make gamemaker do more than a few hundred commands in a frame, it starts to slow down, you can even make the command do nothing, like a null command, and it still slows down.construct lets you do a few thousand things per tick before it's interpreter causes a bottleneck, [quote="LavaWave":1m4w35qn]Last time I heard, Python in Construct is very weak/limited and need's alot of improvement's.[/quote:1m4w35qn]as far as python goes, python with construct makes gml look like a toy,python is a full language, every bit as powerful and complex as a real compiled language like C++, aside from speed that is, though it is still at least an order of magnitude faster than gml, but even faster is...[quote="StAtrill":1m4w35qn]Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)[/quote:1m4w35qn]aside from python, which is insanely c-likeyou can make plugins for construct fairly easily using c++ , everything you do in construct is done with a plugin, from loading an image into a sprite, to applying a platform behavior, to playing a sound, to opening a file dialogue. they are as powerful and fast as the c++ that spawns them. the possibilities are endless.

I used gamemaker for a while, I even bought it. it's a neat little tool for what it's worth, but it's very limited. With construct, a dedicated user could create World of Goo, or Braid, Plants vs Zombies, or Aquaria.with the speed, and the pixel shaders, it's definitely possible to create the next big thing in 2D.

one last thought, people keep saying rapid prototyping without really explaining what they mean exactly. I'll give you a quick example or two. somebody asked if it was possible to create a 2d version of katamari damacy, and upon reading it I was able to create a playable, albeit simple graphiced, example of a 2d katamari damacy prototype in 5 or 10 minutes. I haven't frequented the help forums in some time, but it was quite common for someone to ask a question starting with "is it possible to..." followed by something that has no built in object or behavior in construct, and the response within a few minutes be an actual working example of what they were asking for. it sounds too good to be true, but I mean it. The fact that there is even a such thing as a 1 hour game competition thread speaks volumes

I've seen some pretty interesting and impressive things created with GameMaker, but I'm pretty sure it's comparable to Clickteam's products in terms of capability: meaning, there's a big limit to what you can do. Having switched from MMF2 (which I realize is different from GM) to Construct, now pretty much the sky's the limit.

[quote="lucid":19pjwdzh][quote="StAtrill":19pjwdzh]Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)[/quote:19pjwdzh]aside from python, which is insanely c-likeyou can make plugins for construct fairly easily using c++ , everything you do in construct is done with a plugin, from loading an image into a sprite, to applying a platform behavior, to playing a sound, to opening a file dialogue. they are as powerful and fast as the c++ that spawns them. the possibilities are endless.[/quote:19pjwdzh]

Lol the point of that was that the two are closely integrated, not that they were similar languages. GML was designed with gamemaker in mind, while python was simply designed to be an easy-to-use open-source alternative. You could code your entire game in GML if you wanted to without running into any issues (and with great ease, may i add), and it seems like the extent of python inside Construct is for nothing more than running intensive computations that wouldnt translate well into Constructs normal event system (at least it seems that way from my basic experience with it).

And python and the C languages really arent that alike at all. Aside from words like "if", "then", and "else", the similarities stop. I could go deep into this, but you could also do your homework and find this out yourself.

Finally, GM can be slow (mainly if you dont know what your doing), but it isnt weak. I wrote an entire skeletal animation program in it (for the curious: http://www.yoyogames.com/games/102929-animator) and it can maintain 127 fps running my entire animation engine AND the separate front end to it with a full skeleton across nine depth levels (on my old P4 3.2 Ghz). The source code itself is a few thousand lines long and it doesnt even choke. GM would be a great tool if... well im not going to get into all that here.

[quote="StAtrill":3j4e15rv][quote="lucid":3j4e15rv][quote="StAtrill":3j4e15rv]Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)[/quote:3j4e15rv]aside from python, which is insanely c-likeyou can make plugins for construct fairly easily using c++ , everything you do in construct is done with a plugin, from loading an image into a sprite, to applying a platform behavior, to playing a sound, to opening a file dialogue. they are as powerful and fast as the c++ that spawns them. the possibilities are endless.[/quote:3j4e15rv]

Lol the point of that was that the two are closely integrated, not that they were similar languages. GML was designed with gamemaker in mind, while python was simply designed to be an easy-to-use open-source alternative. You could code your entire game in GML if you wanted to without running into any issues (and with great ease, may i add), and it seems like the extent of python inside Construct is for nothing more than running intensive computations that wouldnt translate well into Constructs normal event system (at least it seems that way from my basic experience with it).[/quote:3j4e15rv]while python still has some issues as construct is in beta, there is no compromise in the power of python within construct. I can code most of my game (and have) in python. it isn't specialized for things that don't translate well into constructs normal event system, or running intensive computations; I don't see how it can "seem that way" from any amount of use. it's a scripting language that can be used for whatever you want to use it for. However, unlike Gamemaker, the event system is powerful enough that you don't need scripting for even very complex tasks, like Quazi's 3d What I Learned at School Today, or whatshisname's randomly generated perlin landscape thingy, let alone the superbasic stuff in gamemaker that required scripting.

[quote:3j4e15rv]And python and the C languages really arent that alike at all. Aside from words like "if", "then", and "else", the similarities stop. I could go deep into this, but you could also do your homework and find this out yourself.[/quote:3j4e15rv]that's a silly thing to say. I had used gml enough to realize it's limitations before switching to construct. I've developed several c++ plugins for construct, and I've written thousands of lines of python code. They are very similar. I have a few hundred lines of codes I'm going to convert from python to c++, and it will begin with a copy paste action, and the only changes that will be needed are a couple of ()'s and {}'s here and there, and type information. how is gml more c like? because you can't write user defined functions?

[quote:3j4e15rv]Finally, GM can be slow (mainly if you dont know what your doing), but it isnt weak. I wrote an entire skeletal animation program in it (for the curious: http://www.yoyogames.com/games/102929-animator) and it can maintain 127 fps running my entire animation engine AND the separate front end to it with a full skeleton across nine depth levels (on my old P4 3.2 Ghz). The source code itself is a few thousand lines long and it doesnt even choke. GM would be a great tool if... well im not going to get into all that here.[/quote:3j4e15rv]it has nothing to do with not knowing what you're doing. it is slow, weak, don't really see the difference in this context. After experimenting with simple loops of simple math functions, I discovered the interpreter for gml "chokes" once it reaches several hundred operations per frame. of course if your project never reaches that point of complexity it will never be a problem. A bone animator isn't exactly a basic project as far as most gamemaker projects go, but it also doesn't require an extraordinary amount of power. linear interpolation of a few angles, that's all, 20 bones at the most? you could run that on a celphone. construct gives you the power and speed to choke your PC due to actual computation as opposed to using too many events or scripting lines. if you want to do anything reasonably complex in gml, it always bottlenecks with the interpreter after a few hundred commands per frame. don't believe me, try looping 2+2 in gml, and see how many times you can do it per frame before you bring gamemaker to it's knees.

That isn't to say it's impossible to reach that limit on construct, since my current procedural bone animator, which executes over 1000 python commands per skeleton per tick, does in fact reach the interpreter bottleneck if I try to animate several skeletons at once. Which is again why it's nice to be able to switch off to c++ if need be.

gamemaker and gml are fun toys.construct and python is more fun, but it's actually powerful enough to be a serious development tool as well