>
>
> >
> > 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)
> >
> aside from python, which is insanely c-like
> you 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.
>
>
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).
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.
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.
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