Originally Posted by Pixelthief I can translate pretty much any algorithm into any programming language, be it from C to MMF2 to Construct to Lua to Java. They are all just different syntaxes doing the same thing. I can't imagine that a talented coder would have any problems understanding what makes MMF2 tick and provide any disadvantage over Construct in terms of grokkability, considering its set up with specifically that in mind. In fact, quite to the opposite, the core reason for using either product being rapid prototyping, it is, by general, far easier to do such things in MMF2, where default movements and extensions are plentiful to cut down on coding, which is precisely the point.
Its not an argument about which is a stronger or more elegant language with greater power for talented programmers. To be honest thats almost antithetical
High level programming these days is all about linking together libraries. With regards to the comments about translating algorithms, I think it's probably more natural to translate between languages of a similar style. Indeed MMF2 is limited by its current functionality unless you are willing to write extensions. I challenge you to write an application that reads in two images and produces a dense 3d reconstruction with MMF2 (to prove a point about how non-trivial it is even for experienced programmers to translate such algorithms to MMF2). I don't believe that the only differences are syntax either; obviously the machine code that gets executed on your cpu at runtime is different. If the algorithm cannot be made to be efficient on the platform (VM/interpreter) that it's running on then it's simply not possible to translate to that target language. You would probably argue that if you can't do it with MMF or it is easier with another tool/language you are probably using the wrong tool, which would be correct. Use the right tool for the right job. The argument in the sphere of problems solvable by MMF2 and Construct really comes down to preference of style and what you have already learnt.
For those of us who face problems with MMF2 that are not problems in general purpose programming languages, surely a tool similar to MMF2 that addresses these issues is going to be useful. It's quite impossible to convince people to switch tools when they already understand and took the time to learn the tool that they are currently using. Experienced programmers have a generic understanding and so switching tools is really a non-issue, but I imagine that switching tools really does take some effort for the vast majority of MMF users so it has to be worth the effort. Users will be unwilling to switch to a new tool particularly if they don't experience severe limitations with the tools they are using or if they don't feel that learning a new tool is going to benefit them. If you really want to convince a MMF2 user that they should be using Construct instead you would have to find notorious examples that are made significantly easier by Construct to contrast the two. Examples that affect and benefit the average user. I don't think that is very easy to do.
If I knew the algorithm for meshing together two images in 3d reconstruction, as well as any fair amount about their image format and headers, I could write you that in MMF2, yes. And I'm sure it could be written in Construct 2, also. And in neither would it be efficient or operate in any meaningful capacity, because neither language is suitable for intensive computation.
And indeed, the right tool should be used for the right job, and in general that would be C or C++ in this context.
The problem is, MMF2 and Construct 1 & 2 heavily overlap in terms of their targeted usage. Their is very, very little that you could do efficiently in one that couldn't be done in the other, compared to their similarities. Their are different, but mostly equivocated (*) libraries and built in features for HWA and physics and all that jazz.
Construct 2 could easily be marginally more efficient or powerful than MMF2, and kudos to it for that. But it is not on orders of magnitude, it is not a lower level language suitable for cutting edge performance. And so most every category of application that a person could want to develop on say MMF2 and learn it is not suitable for, the same would apply to Construct 2. Let me put it this way. If someone came to me asking advise on what language to use to build a large scale epic RTS game for wide commercial release, on the lines of Starcraft II, I would tell them "C/C++", which is of course what it (and its own scripting language) was written in. If someone asked me what to develop their online game for their website, I'd tell them "MMF2" (or flash, for that matter, but it seems MMF2 is much better at what flash does anyways!). But would I say Construct? I couldn't whole heartedly give advise like that.
It is hardly a "simple online applet". I had to write my own level editor, scripting language & parser, physics engine, and things with temporal mechanics that frankly have never been done before and don't even have a name (I'm keeping a few good secrets for now). Now, if I went back and started this project from the ground up, I would clearly have done it in C++ with how much I've improved since I started. But this project was possible in MMF2, and its going to be finished in MMF2. But would I have been able to make the same project in Construct?
Technologically, sure. Construct has the raw power, the moddability, the extensibility. But is that really the answer?
The answer is a resounding "No". Because a great deal of what I've accomplished in MMF2 has been due to the large klik community. How much I owe to greyhill/retriever for working with me on xLua, or clickteam for weeding out issues as I find them and add new features as I need them. And the vast amount of existing libraries (extensions) to work with, to give it some ground to start flying off of. I'm sure Ashley would be glad to work with anyone who is trying to make something large in Construct, but they just don't have the same sized community. And that really *is* orders of magnitude. And that brings me back to that (*); those extensions, those libraries, those vast amounts of preexisting content and coding that have been done in KNP, CNC, MMF, MMF1.5 & MMF2, that have all added up over time, have created a beast of support. And its not the kind of thing that could be lightly replaced or made up for, in just a few short years of effort.
And maybe some day Construct will have as huge community as klik too, and I look forward to that. Its certainly got a good start on it! It would be great to see what could be accomplished in it. But its just not suitable for medium to large projects, yet. Its not stable, and the community is only just starting to take off, and theres a air of uncertainty and lack of backwards compatibility to turn off anyone seeking to make something with a long development cycle. Its not suitable- *yet*. MMF2 is a finished product, being refined to great effect. Adding new functionality and compilers and cross platform exporters, with a wealth of preexisting extensions, scripting, and community support. Construct is of yet nascent, and very promising. And I'm looking forward to seeing how well it buds up.
Originally Posted by ~Matt Esch~ If you really want to convince a MMF2 user that they should be using Construct instead you would have to find notorious examples that are made significantly easier by Construct to contrast the two. Examples that affect and benefit the average user. I don't think that is very easy to do.
And Construct and MMF have practically the same interface for coding, since construct was an obvious rip off.
It certainly wasn't the brain child of tigs that's for sure.
Here's an example that affect's and benefits the average user, Constuct can only export to pc's, while mmf can export to flash, java, javame, vitalize, pc, blackberry, android (soon), iphone (I'm a beta tester for it), ipad (I'm a beta tester for it). and mac (soon).
Not to mention the huge community behind it that's building extensions, tutorials, games, applications, ect.
Heck, you can even build a webserver with it.
The fact that MMF has (deep) lua support alone should be enough to convince anyone with the money to buy MMF after they've played around with construct for a day.
We heard it all before urbanmonk, construct also has it's advantages over mmf2 such as actually working built in movement (including a awesome rts movement, something that is almost impossible to make in mmf2), built in physics, built in hardware acceleration support etc...
Each product has it's weak and strong points, using one of them depends on what you're after. For instance, being able to export iphone or android apps looks cool in the paper but very few people will actually use it. MMF2's price+ the exporter's price+App store yearly fee all put together can be pretty steep price for a hobby and most mmf2/construct users are hobbyists. Those probably won't need to make a webserver or use lua scripting either.
It's pointless to make comparisons, let alone state as if it was a fact that one is incomparably better than the other.
Its quite possible to make RTS movements in MMF2. I think I made one when I was 12
Frankly anything thats Turing-complete is going to do 'anything' in the end. I imagine if there was enough interest, someone would make an RTS movement for MMF2 or MMF3.
Originally Posted by Johnny Look We heard it all before urbanmonk, construct also has it's advantages over mmf2 such as actually working built in movement (including a awesome rts movement, something that is almost impossible to make in mmf2), built in physics, built in hardware acceleration support etc...
You're going to keep hearing it because it's true, Construct has no advantages over mmf2.
You act like built in is something people would want. I prefer modular, where I can add features as I need them rather than bloat my exe with code I'm not using.
Frankly I think RTS's fall firmly into the sort of games you really shouldn't be trying to make unless you plan on doing them from the ground up. I don't feel them to be the domain of any sort of prototyping language, MMF2 or Construct 2 or whatever, you shouldn't be trying to make them if you don't understand how to do basic tree traversal and selection algorithms efficiently. And if you do, you should be doing it in C -.- Sort of a moot point, but still
Originally Posted by Johnny Look We heard it all before urbanmonk, construct also has it's advantages over mmf2 such as actually working built in movement (including a awesome rts movement, something that is almost impossible to make in mmf2), built in physics, built in hardware acceleration support etc...
You're going to keep hearing it because it's true, Construct has no advantages over mmf2.
You act like built in is something people would want. I prefer modular, where I can add features as I need them rather than bloat my exe with code I'm not using.
LOL for how long did you try construct to state that construct has no advantages over mmf2 ?
Construct is free, mmf2 costs 99$, that's a big advantage already. Being open-source is another one. Working built in movements is another, real time shadowcasting is another, builtin hardware acceleration, the way construct handles variables is much better, etc.. Those were the first advantages over mmf2 I thought of, there are many more. You just need to be familiar with both programs to know them.
"You act like built in is something people would want. I prefer modular, where I can add features as I need them rather than bloat my exe with code I'm not using. "
Hum...what difference does it make, exactly ? Also just because they are built in the program, it doesn't necessarily mean you're going to use them for your game. If you can use them right off the bat without having to code them then it's a good thing, right ?
pixelthief:
Making a rts requires more planning than the average game, but you don't need to know exactly how pathfinding works, you just need how to use it. So if it's already done and works well what's the point of re-inventing the wheel just for the sake of knowing how it works ?
Isn't "construct isn't free" the point of this thread?
pixelthief:
Making a rts requires more planning than the average game, but you don't need to know exactly how pathfinding works, you just need how to use it. So if it's already done and works well what's the point of re-inventing the wheel just for the sake of knowing how it works ?
Unless you're going to do a "paint by numbers" game generator to make an RTS, you're going to need an intimate knowledge of the inner workings to have any sort of respectable product at the end. And while you can churn out a prototype-quality newgrounds game by the bucket with MMF2, no product is going to let you create say "Command and Conquer" with little knowledge of pathfinding, collision detection, los, etc.
Its possible to create some workable games using more basic built in movements and controls like the platform & racecar & 8 direction, since they leave the guts of the game mechanics up to the designer. But unless your goal is the game design equivalent of "connect the dots", you wouldn't even have an end product on the quality level of those kinds of games where you just sub out the sprites.
If someone handed you "rts movements" on a silver platter, there would only be a single game produced in it and the rest just clones of that. Because the more you diverge from the built in qualifications and intentions and usages, the more you need your own coding. Look at the platform movements in MMF2, and why nobody uses those in 'good' projects- now apply that to something as core to a game as an RTS doing radial grouping and AI commands. You would be so hard pegged into the built in archetype that it wouldn't just be inflexible, it would also dominate the entire structure of your game. So you'd wind up with, as I was saying, the equivalent of painting by numbers.
And is that the worst thing in the world? Naw, heck naw. Some people like that stuff. Many may rag on it, but theres a time a place and a vector for 'one button game creation', but I think its self evident that neither Construct nor MMF2 are tailored towards that- they are meant as intermediate rapid prototyping tools that allow much faster and easier development at the expense of power and efficiency.
I think the rule of thumb is, if you want to make an RTS, you have to get your hands dirty
Originally Posted by alastair john jack Can HWA MMF2 export to any other system? Or is MMF2's exporters only for little simple games?
Currently, HWA applications can only be exported to .exe and run on Windows.
Flash has its own minimal amounts of hardware accelerated features, accessible through the Flash FX object
but bear in mind, flash itself is not meant to be HWA, it was a (relatively) recent development that sort of violates the sandbox (harmlessly)
I can't speak with authority on Mathias's Anaconda exporter nor will I divulge anything confidential, but it may have access to cross system portable hardware acceleration through OpenGL (mind, GLUT needs GLSL, virtually identical but opposed to HLSL, so it would take some recoding for existing projects, but HLSL<->GLSL converters exist for shaders anyway). Which would be nice, because that would run on anything, even if OpenGL is slower than DirectX on windows.
MMF2's current HWA exporter is hardly suitable only for "little simple games", its just a strict improvement on the standard runtime. Anything you want to release as a windows executable only should be made in it as far as I'm concerned. For example, my aforementioned project is being developed in HWA, and its not little or simple by any stretch
Even though you can look at the source code for Construct V1 it isn't true open-source because it requires commercial library's to build. It seems V1 will be a static project now other than a few people with the required library's that are fixing bugs and adding a few things. V1 is good but it is still very buggy and not the main focus so for free click style programming then Game Develop might now be a better choice.
Most of the V1 community liked it because it was a free alternative to MMF2. With that no longer the case for V2 i have already seen upset users now that the plan is to be closed source and commercial using a subscription so now it might have less users which also means less user content. There is not really much done with V2 yet either and it is currently only HTML5 export but i am sure it will get a lot better though. I don't plan to buy it until it is at least at the standard of V1 but by then MMF3 might be released.
I second what a lot of people have said though, i think Construct is great but other than a few nice graphics effects, a few better built in movements and editor improvements there was not a lot in Construct V1 to make me want to stop using MMF2. I find MMF2 to be a lot more powerful also and the HWA version makes it just as good for effects, the only thing it improves on with that is the options for multiple effects on objects but MMF2 improves on Construct for some things also like the built in code editor.
Having more exporters is a good option also and on the clickteam java forum it says there will be XNA export for MMF2 on the way also which will be great. HTML5 seems ok but you can do that easily enough with a free text editor at no cost anyway, i have read MMF2 plans to export that at some point also though, i think Construct V2 really needs to have a exe exporter though.
Having more exporters is a good option also and on the clickteam java forum it says there will be XNA export for MMF2 on the way also which will be great.
Originally Posted by Pixelthief Isn't "construct isn't free" the point of this thread?
pixelthief:
Making a rts requires more planning than the average game, but you don't need to know exactly how pathfinding works, you just need how to use it. So if it's already done and works well what's the point of re-inventing the wheel just for the sake of knowing how it works ?
Unless you're going to do a "paint by numbers" game generator to make an RTS, you're going to need an intimate knowledge of the inner workings to have any sort of respectable product at the end. And while you can churn out a prototype-quality newgrounds game by the bucket with MMF2, no product is going to let you create say "Command and Conquer" with little knowledge of pathfinding, collision detection, los, etc.
Its possible to create some workable games using more basic built in movements and controls like the platform & racecar & 8 direction, since they leave the guts of the game mechanics up to the designer. But unless your goal is the game design equivalent of "connect the dots", you wouldn't even have an end product on the quality level of those kinds of games where you just sub out the sprites.
If someone handed you "rts movements" on a silver platter, there would only be a single game produced in it and the rest just clones of that. Because the more you diverge from the built in qualifications and intentions and usages, the more you need your own coding. Look at the platform movements in MMF2, and why nobody uses those in 'good' projects- now apply that to something as core to a game as an RTS doing radial grouping and AI commands. You would be so hard pegged into the built in archetype that it wouldn't just be inflexible, it would also dominate the entire structure of your game. So you'd wind up with, as I was saying, the equivalent of painting by numbers.
And is that the worst thing in the world? Naw, heck naw. Some people like that stuff. Many may rag on it, but theres a time a place and a vector for 'one button game creation', but I think its self evident that neither Construct nor MMF2 are tailored towards that- they are meant as intermediate rapid prototyping tools that allow much faster and easier development at the expense of power and efficiency.
I think the rule of thumb is, if you want to make an RTS, you have to get your hands dirty
I don't want to sound offensive, but it seems to me you don't know much if anything about what you're talking about.
"Unless you're going to do a "paint by numbers" game generator to make an RTS, you're going to need an intimate knowledge of the inner workings to have any sort of respectable product at the end."
You already said that with other words, but you didn't explain why exactly. Why do you need to know how something works to use it ?
"Its possible to create some workable games using more basic built in movements and controls like the platform & racecar & 8 direction, since they leave the guts of the game mechanics up to the designer. But unless your goal is the game design equivalent of "connect the dots", you wouldn't even have an end product on the quality level of those kinds of games where you just sub out the sprites."
There is much more to a RTS than just moving units, why exactly is it any different from a platform or racecar movements ? I can easily tell you never designed a RTS or tried Construct's RTS builtin movement.
"If someone handed you "rts movements" on a silver platter, there would only be a single game produced in it and the rest just clones of that"
And why is that ? The only thing the rts movement handles is pathfinding and movement. The way the unit moves, speed, acceleration etc... are 100% configurable and can be used with other builtin movements at the same time. Even the pathfinding system can be configured and tweaked.
"Look at the platform movements in MMF2, and why nobody uses those in 'good' projects- now apply that to something as core to a game as an RTS doing radial grouping and AI commands. You would be so hard pegged into the built in archetype that it wouldn't just be inflexible, it would also dominate the entire structure of your game. So you'd wind up with, as I was saying, the equivalent of painting by numbers."
First off no one uses mmf's platform or any other builtin movements because they are broken and unusable.
Second, given that construct's builtin rts movements is fully configurable, how coding your own pathfinding and object grouping algorithm would make that any different ? You'd probably end up with very similar if not the same results.
As far as unit selection and moving goes, can you tell the difference from Age of Empires II and Stronghold or any other similar 2D rts ?
Third, there is much more to a RTS than just moving units, and that's the only thing the rts movement does. It's as important to the gameplay as a platformer's movement or car physics in a racing game.
It has nothing to do with AI programming, at least not directly and objecting grouping is handled in a different extension and is not builtin into the rts movement.
"I think the rule of thumb is, if you want to make an RTS, you have to get your hands dirty"
That applies to any game you make if you want it to be good.
"Isn't "construct isn't free" the point of this thread?"
I was referring to Construct 1 not construct 2.
Advertisement
Post Reply
Edited by Johnny Look
