There have been several preview builds released, currently Alpha Preview Build 29 ( http://www.scirra.com/forum/viewtopic.php?f=35&t=8661 ), and talks of a licensing model so they can make money off of it in the future and turn it into a full time job deal. As well as threads on the direction they're taking construct in.
The overall design of Construct 2 is absolutely fabulous. The idea of an external plugin-like runtime system blows my mind. Anyone could code and release their own runtime, making it 100x more extensible than Multimedia Fusion.
...its more of a subscription fee than a one time license purchase. And the prices? they're damn expensive. 150 pounds for 2 years of updates, 700 pounds for 10 years of updates? seems like a bit of a gamble to me. Other than the construct and click communities, not many people are even aware of construct, afaik. It seems kind of ballsy to go out and charge an arm and a leg for software that was originally completely open source and free.
This totally kills the idea of construct as a clickteam alternative for me.
i do hope clickteam takes a page from construct 2's design philosophy of having the runtime be extensible by third parties. if they did that they mmf3 would blow it out of the water.
thats another thing. no. construct 1 has not been released/completed and iirc there are no plans to finish it. i do believe they said they would occasionally release some updates with bug fixes for it, but as it stands the original construct will simply be 'Construct 0.x' and their focus will now be on Construct 2.
People are still making updates for Construct 1. The latest version was done without Ashley doing anything. Construct 1 is still fairly stable, and a very nice program.
Construct 2 is £39 for 2 years of updates (less than that if you get it while its young), or theres different options (even the option to use it for free). So yeah, lol.
I like that it's going to be based on html5/canvas, but unfortunately they're keeping the ribbon interface, which means it will still be a steaming pile of crap. Too bad...
Hi Cecil - Alastair John Jack is right, it's only £39 for the indie license, and we'll be running reduced early-adopter licenses too. The prices you quoted are (the proposed prices) for the commercial license, which means you'd be earning at least £20k/yr from Construct 2. I don't think even the commercial license is a big cost if you're making that much!
@Alastair - "i do believe they said they would occasionally release some updates with bug fixes for it, but as it stands the original construct will simply be 'Construct 0.x' and their focus will now be on Construct 2."
@Adam - please keep the negativity to a minimum. As should everyone.
@Ashely - Thank you for the response Ashley. However whats the difference then? When paying for different tiers of licenses there is usually a drawback for choosing the lesser of the two. Whether its having to credit the software with endless or nagging splash screens, or even paying royalties, or having less functionality. I tend to go all out when purchasing software. I will either pay nothing and use a slightly gimped version, or the full price for all the features.
I also realize these are just proposed licensing structures and there are less expensive licenses. I'm just kind of peeved how it went from "free and open sourced", to "hey pay what you want", to "oh, its gonna cost you, and if you want to continue getting updates down the line you gotta pay some more". I love everything about how Construct 2 is being made, and the potential of what its going to be sounds fantastic, but at the moment the way its being licensed is kind of absurd. 1000$ for a commercial product is something i would expect to pay for software from a well known software company, not a bunch of college students/community developers trying to jumpstart a profitable company.
However, if the £39 indie license gets me everything the commercial license does, without royalties or splashes, then i will probably buy into it. I still do not like this idea of "future-proofed with [set amount of time] of free updates". I would gladly pay another £39 for a new Major revision like Construct 3. or even an amount for a new exporter.
@Cecil, there is no functionality difference, no gimping, no splash screen, no forced credit, no royalties - it's just a different license. Exactly the same software, just a cheaper license for indies who might not have much income.
I'm sorry you're peeved over going from free and open source to the licensing system, but we've actually worked really hard on 0.x (it's over a quarter of a million lines of code) and just about could cover the website hosting cost from donations, so we never actually earnt anything from it. To be honest I think what we are doing is perfectly fair - once the product is mature I think it's a very fair price, and we're not tieing it up with DRM or copy protection either.
Originally Posted by Sketchy I like that it's going to be based on html5/canvas, but unfortunately they're keeping the ribbon interface, which means it will still be a steaming pile of crap. Too bad...
I don't understand what's so wrong about the ribbon interface, specially since you barely use it in construct. Also I don't see how a bar in top of the program make it a "steaming pile of crap", but perhaps that's just me.
Originally Posted by SiLVERFIRE Programing in C++ is free and has a world of more flexibility than MMF2. Does that mean it sucks even worse?
Just keeping things in perspective here. No need to hate.
I was talking in general about ribbon interfaces (does anyone prefer Office 2007 or later over 2003?). For example in office 2007 do I really (please tell me if I do not ) have to sacrifice that much screen space for styles? As far as I know I have no option to set it back to the 2003 method of choosing styles which took up a lot less screen real estate. This is my big gripe against ribbons, I have no control (as far as I know) on optimising the interface for things I use often. These things I would have as toolbars, and items I use rarely I would leave in the menus. It's as if MS just had to change the interface to make office look new. Thank god I hardly use office these days, LaTex for the win !
My job involves programming in C (no object orientation), assembly and VHDL. Not one piece of professional software I use for my work features the ribbon interface, because engineers know what works - its kind of part of the job description .
On that note I keep threatening to make the jump to SDL/Irrlicht.
The fact that the ribbon interface wastes a lot of space is just one of the reasons it sucks. Minimizing it may solve that one problem, but the fact remains that when you do use it, it sucks.
If the best thing you can say in it's defense is basically "well you don't have to use it very often", then why bother changing it, bearing in mind pretty much everything else is just a direct rip off of MMF to begin with?
My guess is they think it somehow looks more modern/professional, because Microsoft use it - and to hell with functionality/productivity. It's just retarded...
@Hagar:
I think 2010 is supposed to be a little more customizeable, but 2007 really isn't. There are actually third-party programs you can buy though, that will give Excel 2007 the 2003-style menus and toolbars. Just goes to show how much many people hate it...
Personally, I uninstalled 2007 (came bundled with my new computer), and replaced it with 2003.
If the best thing you can say in it's defense is basically "well you don't have to use it very often", then why bother changing it, bearing in mind pretty much everything else is just a direct rip off of MMF to begin with?
Would you call openoffice a ms office rip off ?
You seem to forget construct is free and developed by volunteers, your tone make it look like a big ass corporation stole an idea from a small and poor company in the hope of making big bucks when all they did was provide everyone with a free (and imo improved) alternative to mmf2.
Until now you haven't provided a decent reason why construct sucks so bad in your opinion.
Obviously it's hard to call one office suite a rip off of another, as there have been many rival companies gradually perfecting them, over a very long period of time. No one company can really take the credit for inventing the modern office suite.
In the case of "game makers" though, Clickteam single-handedly invented the genre with Klik 'n' Play, and while MMF2 is much more powerful, the concept and interface is virtually unchanged. The makers of Construct just ripped off that concept and the bulk of the interface, while adding very little themselves (apart from the crappy ribbon). I hardly think it's a coincidence that the designer of Construct was himself, a long time kliker.
You seem to forget that it shouldn't matter if it's a "big ass corporation" or "small and poor company" - they should all play by the same rules.
Your tone makes it look like you think it's okay for volunteers to rip off a big ass corporation, but not the other way around?
Even if they were making no money at all out of Construct (and they obviously intend to), they're still depriving Clickteam of income. If you reproduce someone else's work, you should expect to have to pay them for it - even if you then pass that copy on to someone else, free of charge.
My personal experience of Construct:
Obviously most of Construct is copied directly from MMF2, so it's neither better nor worse. Flexibility/performance isn't an issue either - there's nothing you could make in Construct that you couldn't make in MMF2, and perhaps vice versa (apart from MMF2 having more export options, and crashing less often).
So, you have to focus on the differences.
The Construct interface is bad. Not just the awful ribbon, but all of it - simple tasks like coding an event take more clicks, or require a double-click when a single click could have been used instead. It's stuff like that - many small details, that eventually start to stack up. The whole point of these kinds of programs is that they are supposed to make game-making quick and simple - and Construct just doesn't.
Basically, with a few exceptions, everything that's the same is the same, and everything that's different is worse.
For once I agree with Sketchy. What also saddens me is the lack of loyalty in the community. Its amazing how many faults people list with Click products as soon as a clone arrives on the scene, as if using it will suddenly help develop their game making skills, even though they've been using click products for years and still release perfectly mediocre games that could be made in KnP.
Or they release no games at all, but still like to spout off joining in the debate because they're technical nerds and only give a shit about the interface of the product, or experimenting with applications which get abandoned because they lacked programming knowledge (but its actually MMF's fault!)
urbanmonk:
Buggier doesn't necessarily mean worse, and other than the occasional weird crash when exiting the program I don't recall experiencing any other bug or crash with the last build.
If I wanted to point out what construct has that mmf2 doesn't I could start with default movements that actually work, built in physics, object selection that doesn't break if you use many objects, built in pathfinding etc...
sketchy:
"Obviously it's hard to call one office suite a rip off of another, as there have been many rival companies gradually perfecting them, over a very long period of time. No one company can really take the credit for inventing the modern office suite."
I don't know how openoffice is right now since I haven't used it for some time, but the interface in most if not all applications used to be exactly the same. They even supported ms office's formats. It's not just that they are both office suites, they are simply identical. It's as much as a rip off to ms office as construct to mmf2.
I spoke about open office like I could be talking about any other open source software that is based on a commercial product.
"In the case of "game makers" though, Clickteam single-handedly invented the genre with Klik 'n' Play, and while MMF2 is much more powerful, the concept and interface is virtually unchanged. The makers of Construct just ripped off that concept and the bulk of the interface, while adding very little themselves (apart from the crappy ribbon). I hardly think it's a coincidence that the designer of Construct was himself, a long time kliker. "
What about game maker and the other countless game makers that came after ? The interface is different but the concept is the same. Should clickteam sue them all ? Would construct be acceptable to you if they changed the interface ?
"You seem to forget that it shouldn't matter if it's a "big ass corporation" or "small and poor company" - they should all play by the same rules.
Your tone makes it look like you think it's okay for volunteers to rip off a big ass corporation, but not the other way around? "
Taking the openoffice example, it's ok to rip off Microsoft but it's wrong to rip off clicteam ?
"Even if they were making no money at all out of Construct (and they obviously intend to), they're still depriving Clickteam of income. If you reproduce someone else's work, you should expect to have to pay them for it - even if you then pass that copy on to someone else, free of charge. "
They aren't reproducing someone else's work, they did everything from scratch. The only based themselves on mmf2's interface not because they wanted to rip off clickteam but because it was the interface they were familiar with.
But this isn't about construct copying the interface or not. If construct sucked so much as you said, it wouldn't be a problem for clickteam. The problem is construct is good actually, if clickteam can't cope with the competition that's their problem.
"there's nothing you could make in Construct that you couldn't make in MMF2"
That's not entirely true. For example, try stress testing mmf2's object selection and it will eventually break. Try doing the same with construct and it will work all the time. This, along with the built in RTS/pathfinding movement make it possible to make a full scaled rts in construct while in mmf2 sooner or later the game will break.
"The Construct interface is bad. Not just the awful ribbon, but all of it - simple tasks like coding an event take more clicks, or require a double-click when a single click could have been used instead. It's stuff like that - many small details, that eventually start to stack up. The whole point of these kinds of programs is that they are supposed to make game-making quick and simple - and Construct just doesn't."
The interface isn't bad, it's identical to mmf2's. If anything you're not used to the few differences between both, but they aren't enough for anyone to claim one is great and the other is terrible.
You probably tried construct with a certain mindset, and when you're convinced that the program had to suck before you even tried it then it will suck for you.
"Basically, with a few exceptions, everything that's the same is the same, and everything that's different is worse."
This sums up your entire post well. You said construct was a pile of crap, but judging by what you just said construct is, barring some slight differences, is identical to mmf2.
Your problem isn't so much about construct being bad or good, it's that according to you it rips off clickteam, hurting them.
Clickteam going under can be frightening thought to a lot of people and I can see why.
Adam:
"What also saddens me is the lack of loyalty in the community. "
Loyality to who ? Clickteam ?
Usually it's the client who expects loyality and support from the company, not the other way around. I'm not used to lick anyone's boots, specially if I don't owe them anything.
Originally Posted by SiLVERFIRE Programing in C++ is free and has a world of more flexibility than MMF2. Does that mean it sucks even worse?
Just keeping things in perspective here. No need to hate.
I was talking in general about ribbon interfaces (does anyone prefer Office 2007 or later over 2003?). For example in office 2007 do I really (please tell me if I do not ) have to sacrifice that much screen space for styles? As far as I know I have no option to set it back to the 2003 method of choosing styles which took up a lot less screen real estate. This is my big gripe against ribbons, I have no control (as far as I know) on optimising the interface for things I use often. These things I would have as toolbars, and items I use rarely I would leave in the menus. It's as if MS just had to change the interface to make office look new. Thank god I hardly use office these days, LaTex for the win !
My job involves programming in C (no object orientation), assembly and VHDL. Not one piece of professional software I use for my work features the ribbon interface, because engineers know what works - its kind of part of the job description .
On that note I keep threatening to make the jump to SDL/Irrlicht.
I have never really made anything worthwhile or complete with either mmf gamemaker construct or otherwise. I have made a few odds and ends here and there but nothing on a grand scale. I've always wanted to but i just get bored after awhile. I tend to code more technical things, like engines, widgets, plugins, etc, or just try to see if something is possible. I also don't limit myself to Game Making Software. I am currently working in XNA and as a game making framework its pretty badass. Lots of code to work from on the internet, and its super easy to use.
With that said, the only reason im interested in products like these is to see what its all about and fiddle around with the software. Maybe put out a few technical pieces, help other users complete their own projects, solve problems, etc.
As far as the interface being "crap", well thats your opinion, imo its far better than mmf, aside from the ribbon. I also think MS KNOWS that its kind of crap because their mainstream software uses it but their developer software doesnt. Developers would be outraged if Visual Studio or Expression Studio used the Ribbon Interface.
Originally Posted by Johnny Look urbanmonk:
Buggier doesn't necessarily mean worse, and other than the occasional weird crash when exiting the program I don't recall experiencing any other bug or crash with the last build.
If I wanted to point out what construct has that mmf2 doesn't I could start with default movements that actually work, built in physics, object selection that doesn't break if you use many objects, built in pathfinding etc...
Yeah, the built in movements are better, but, but...
They still don't have any worth while exporters yet, even though html 5 is great it's nothing compared to iphone, java, and flash.
EDIT: Aaaand I don't feel it's worth my time to develop a game/app in something that has a very limited opportunities for exposure.
Yeah, the built in movements are better, but, but...
They still don't have any worth while exporters yet, even though html 5 is great it's nothing compared to iphone, java, and flash.
EDIT: Aaaand I don't feel it's worth my time to develop a game/app in something that has a very limited opportunities for exposure.
You must realize though that this is like super early for C2. It's like a fetus. The whole idea C2 is based around is to be super flexible. HTML5 may be the only runtime they are focused on right now, but its being built with the idea that run-times can be added onto the software like a plugin.
I like Construct's pairing system, picking system, behaviours and event system (especially subevents), image editor (unlimted action points too), and it feels more powerful (though I dont have much experience with MMF2's HWA version). The only thing I like better about MMF2 at the moment is that it has more exporting options.
Originally Posted by DCI Hagar I was talking in general about ribbon interfaces (does anyone prefer Office 2007 or later over 2003?). For example in office 2007 do I really (please tell me if I do not ) have to sacrifice that much screen space for styles? As far as I know I have no option to set it back to the 2003 method of choosing styles which took up a lot less screen real estate. This is my big gripe against ribbons, I have no control (as far as I know) on optimising the interface for things I use often. These things I would have as toolbars, and items I use rarely I would leave in the menus. It's as if MS just had to change the interface to make office look new. Thank god I hardly use office these days, LaTex for the win !
Outside of the MMF2/Construct2 debate, I actually prefer the new ribbon system over the old menu system (where it makes sense). The menu system isn't bad, but, let's be honest, it's not great either. Menus do an adequate job of organizing an applications functionality - but they have their own inherent issues.
To address some of your issues:
- Do I have to sacrifice that much space for styles?
No, you don't. You can remove nearly all of the styles from your Quick Access Gallery and the style portion of the ribbon will shrink dramatically. You can even remove styles from the ribbon entirely if you'd like.
- This is my big gripe against ribbons, I have no control (as far as I know) on optimising the interface for things I use often.
You have a lot more control over the ribbon than you did the old menu system. You can add and remove tabs. You can customize each tab. You can create your own tabs (in much the same way you had custom toolbars before). Or, if you don't want to click on a custom tab, you can add the stuff you do most "often" to the Quick Access Toolbar. For example, I've added the Print option to the Quick Access Toolbar in Word. But, if you really want to do things fast then you should stick to hot keys - which are (and always will be) the fastest to do something.
- Stated by others: Takes up too much space.
If you're not using the ribbon, minimize it (CTRL+F1 or use the minimize arrow). You can still access it quickly... even by hot keys.
Anyway, everyone is entitled to their opinion on ribbons. I'm a long time user of many office versions and think the biggest issue here is that "it's different." The issues people have sound a lot like the ones I heard when everyone switched from WordPerfect to Word. Except it was hot keys vs. toolbars back then.
Originally Posted by Johnny Look urbanmonk:
Buggier doesn't necessarily mean worse, and other than the occasional weird crash when exiting the program I don't recall experiencing any other bug or crash with the last build.
If I wanted to point out what construct has that mmf2 doesn't I could start with default movements that actually work, built in physics, object selection that doesn't break if you use many objects, built in pathfinding etc...
Yeah, the built in movements are better, but, but...
They still don't have any worth while exporters yet, even though html 5 is great it's nothing compared to iphone, java, and flash.
EDIT: Aaaand I don't feel it's worth my time to develop a game/app in something that has a very limited opportunities for exposure.
I was talking about Construct 0.X actually. Construct 2 doesn't even have built in movements yet.
Originally Posted by DCI Hagar I was talking in general about ribbon interfaces (does anyone prefer Office 2007 or later over 2003?). For example in office 2007 do I really (please tell me if I do not ) have to sacrifice that much screen space for styles? As far as I know I have no option to set it back to the 2003 method of choosing styles which took up a lot less screen real estate. This is my big gripe against ribbons, I have no control (as far as I know) on optimising the interface for things I use often. These things I would have as toolbars, and items I use rarely I would leave in the menus. It's as if MS just had to change the interface to make office look new. Thank god I hardly use office these days, LaTex for the win !
Outside of the MMF2/Construct2 debate, I actually prefer the new ribbon system over the old menu system (where it makes sense). The menu system isn't bad, but, let's be honest, it's not great either. Menus do an adequate job of organizing an applications functionality - but they have their own inherent issues.
To address some of your issues:
- Do I have to sacrifice that much space for styles?
No, you don't. You can remove nearly all of the styles from your Quick Access Gallery and the style portion of the ribbon will shrink dramatically. You can even remove styles from the ribbon entirely if you'd like.
- This is my big gripe against ribbons, I have no control (as far as I know) on optimising the interface for things I use often.
You have a lot more control over the ribbon than you did the old menu system. You can add and remove tabs. You can customize each tab. You can create your own tabs (in much the same way you had custom toolbars before). Or, if you don't want to click on a custom tab, you can add the stuff you do most "often" to the Quick Access Toolbar. For example, I've added the Print option to the Quick Access Toolbar in Word. But, if you really want to do things fast then you should stick to hot keys - which are (and always will be) the fastest to do something.
- Stated by others: Takes up too much space.
If you're not using the ribbon, minimize it (CTRL+F1 or use the minimize arrow). You can still access it quickly... even by hot keys.
Anyway, everyone is entitled to their opinion on ribbons. I'm a long time user of many office versions and think the biggest issue here is that "it's different." The issues people have sound a lot like the ones I heard when everyone switched from WordPerfect to Word. Except it was hot keys vs. toolbars back then.
I tried adding things to the quick access toolbar ages ago, yet they still remained on the ribbon. As far as I know in office 2007 there is no option to actually reorder/optimise the deafult ribbon tabs. The styles setting in 2007 is just stupid in my opinion - I do not need to see little pictures of the styles all the time when the ribbon is not minimised, hence the waste of space. Only tutorials I found on optimising 07 involved using XML, and I am too damn lazy to do that .
As Sketchy said a lot of people dislike the ribbon as there is software available on sale to make 07/10 look like 03 haha.
I have still yet to see a professional/academic (academics lol at the thought of using Word, as references and formatting are a million times better in LaTeX) software package to use ribbons .
To be honest I dont really care what people use to get the job done, but I think the software should allow menu/toolbar or the ribbon interface .
Perhaps they should consider something more like Unity - in terms of licensing that is.
Originally Posted by Sketchy I like that it's going to be based on html5/canvas, but unfortunately they're keeping the ribbon interface, which means it will still be a steaming pile of crap. Too bad...
Glad I'm not the only one that hated the interface.
Originally Posted by DCI Hagar I tried adding things to the quick access toolbar ages ago, yet they still remained on the ribbon. As far as I know in office 2007 there is no option to actually reorder/optimise the deafult ribbon tabs. The styles setting in 2007 is just stupid in my opinion - I do not need to see little pictures of the styles all the time when the ribbon is not minimised, hence the waste of space. Only tutorials I found on optimising 07 involved using XML, and I am too damn lazy to do that .
As Sketchy said a lot of people dislike the ribbon as there is software available on sale to make 07/10 look like 03 haha.
Adding items to the Quick Access Toolbar does not immediately remove them from a tab on the ribbon. In Word 2010, you'd click File > Options > Customize Ribbon to remove items.
To reorder the tabs, again File > Options > Customize Ribbon and use "Move Up" and "Move Down" buttons.
The Styles section will take up as much space as you let it. Sounds like you need to remove styles from your Quick Style Gallery... which is the visual section you're not liking. Removing styles from the Quick Style Gallery does not remove them from the document and they can still be selected and applied.
Agreed. A lot of people do not like the ribbon. But, I'd argue it's mostly an issue with change. If find that new users typically find it easier to navigate.
Originally Posted by DCI Hagar I have still yet to see a professional/academic (academics lol at the thought of using Word, as references and formatting are a million times better in LaTeX) software package to use ribbons .
Not sure about academics, but I'd estimate that more than 90% of professionals use MS Word (at least in the US) as their word processor. The only migrations I see these days are towards Microsoft Office (and away from Lotus Notes, GroupWise, etc.). Some smaller shops may have other office packages but most large corporations have licensed MS Office Professional Plus.
Formatting and referencing are pretty easy (even with the new ribbon system) and I haven't heard much griping from the technical communication community (my wife is a technical writer and a member of the STC - http://www.stc.org/). I don't know much about LaTeX, but I can tell you this... I've never heard of it before. So, it may be a niche title in the academic community. It certainly has no footprint in the professional community.
Anyway, not trying to argue here. Just pointing out that not all folks hate the ribbon.
What's all that talk about ribbons? Who doesn't love ribbons? I think they're real cute.
And I think the ones in MS Office 2007 works really well, but yeah the ribbon tends to take up a lot of screen estate. It just like the new windows 7 taskbar which isn't 32 pixels high, but more like 48 px. Fortunately my screen resolution also was upgraded with my new laptop, so it doesn't really matter because overall I have more screen estate to use
But you people probably are right that the interface and not just the ribbon of construct isn't as efficient as it could be.
I like html5 with canvas 2D and javascript a lot, in fact I've been programming almost exclusively with it for almost over a year. But it isn't the holy grail and especially on low spec machines it's dead slow or was it dog slow? That's quite a bit of drawback and lacks some other features like a high resolution timer for measuring performance, etcetera. It's a healthy technology in development, but I doubt they can improve it so much that it will run on low spec machines.
The fact that everyone can write plugins for it is a nice one, but why isn't that possible for MMF2? I am not up to date with that situation.
Not tried Construct 2, though i will get round to having a look sometime. Surely competition for MMF2/Clickteam can't be anything but a good thing for us lot? If it's better, we get a choice and Clickteam have to "up their game" to compete. If it's not as good, then we don't lose out anyways. Either way, i don't feel any kind of loyalty to Clickteam or any other company: i simply use the program that fits my needs best. If a better alternative for me comes along (and it will one day, no doubt) then i'll probably stop using MMF2 and use that instead.
The ribbon-talk puts me off though - for the record, i hate ribbons and the change in MS's Office suite was a big pain in my arse!
Originally Posted by DCI Hagar I tried adding things to the quick access toolbar ages ago, yet they still remained on the ribbon. As far as I know in office 2007 there is no option to actually reorder/optimise the deafult ribbon tabs. The styles setting in 2007 is just stupid in my opinion - I do not need to see little pictures of the styles all the time when the ribbon is not minimised, hence the waste of space. Only tutorials I found on optimising 07 involved using XML, and I am too damn lazy to do that .
As Sketchy said a lot of people dislike the ribbon as there is software available on sale to make 07/10 look like 03 haha.
Adding items to the Quick Access Toolbar does not immediately remove them from a tab on the ribbon. In Word 2010, you'd click File > Options > Customize Ribbon to remove items.
To reorder the tabs, again File > Options > Customize Ribbon and use "Move Up" and "Move Down" buttons.
The Styles section will take up as much space as you let it. Sounds like you need to remove styles from your Quick Style Gallery... which is the visual section you're not liking. Removing styles from the Quick Style Gallery does not remove them from the document and they can still be selected and applied.
Agreed. A lot of people do not like the ribbon. But, I'd argue it's mostly an issue with change. If find that new users typically find it easier to navigate.
Originally Posted by DCI Hagar I have still yet to see a professional/academic (academics lol at the thought of using Word, as references and formatting are a million times better in LaTeX) software package to use ribbons .
Not sure about academics, but I'd estimate that more than 90% of professionals use MS Word (at least in the US) as their word processor. The only migrations I see these days are towards Microsoft Office (and away from Lotus Notes, GroupWise, etc.). Some smaller shops may have other office packages but most large corporations have licensed MS Office Professional Plus.
Formatting and referencing are pretty easy (even with the new ribbon system) and I haven't heard much griping from the technical communication community (my wife is a technical writer and a member of the STC - http://www.stc.org/). I don't know much about LaTeX, but I can tell you this... I've never heard of it before. So, it may be a niche title in the academic community. It certainly has no footprint in the professional community.
Anyway, not trying to argue here. Just pointing out that not all folks hate the ribbon.
I think 07 is a lot more limited in configuration options (as Sketchy mentioned 2010 is better in this aspect) becuase all I get is options to add things to the quick access bar from the other tabs in Word Options, I think Sketchy mentioned this too. I am still of the opinion that I have been using Word since version 6 on Windows 3.11 and the system remained the same pretty much until 2003. I had years of familiarity, why on earth change something? It would be like deciding to redesign a car and putting the pedals/steering wheel wherever I fancy .
Anway LaTex and Bibtex bibliographies are very common place in UK universities and a lot of technical papers I have read from academia, industrial guys and research labs have also been produced in it. LaTex is just the type setting package, but many options exist for using it. LyX and Jabref are great tools I use quite often, and they are free.
I would seriously suggest anyone writing a thesis to check it out. Referencing and formatting is so much easier once you have got used to it .
Anyway on a more on topic oriented point, I do think having construct is a good thing - competition is always a good thing. Hopefully it will make Clickteam pick up the pace (how many years have the default movements been pants ? )
i noticed that. they are open for 7 weeks though, and they hope to release a new build at least every 7 weeks so you arent without a usable build. but it does put me off even more. the current builds cant do much more than put static pictures on the screen and move them around. not much incentive to use them over any future builds with a pricetag. rediculous.
Maybe it is just me, but there is an issue that has been bothering me for some time. The Klik range of products has been around for a long time, over 10 years. Additional, if my understanding is correct, MF2 was created from the "ground up". In other words, Clickteam didn't just add to MMF when they made MMF2, they started from scratch when they created MMF2.
Now Construct is MANY advantages over MMF2, for example, with Construct a person can do physics without any difficulty. This is done with an easy to understand panel that handles physics with no problem. If you try to do physics with MMF2, you have to spend a great deal of time understanding and working with the physics extensions that are available for MMF2. Creating good physic code in MMF2 is NOT easy!
So here is my point:
1. Has Clickteam been looking at Construct, and seeing what it can do that MMF2 can NOT do, so that they can include more features to MMF2 that Construct already has? I hope so. For example, Construct’s platform movement is better and has more features than MMF2. Yet MMF2’s platform movement has been panned by many people for being buggy, even though the MMF products for been around much longer than Construct. It STILL is NOT “cleaned up”. What is wrong with this picture!? I for one would welcome more features in MMF2 platform movement, like being able to prevent the player from changing directions while in mid-air. I also am thinking of Construct’s bone movement, easy zooming during game play, and other features.
2. Anyone for has ever used both image editors from MMF and MMF2 will notice that MMF2’s image editor has a lot less features and tools than MMF image editor! Why?
Now Construct is MANY advantages over MMF2, for example, with Construct a person can do physics without any difficulty. This is done with an easy to understand panel that handles physics with no problem. If you try to do physics with MMF2, you have to spend a great deal of time understanding and working with the physics extensions that are available for MMF2. Creating good physic code in MMF2 is NOT easy!
Why do you expect game making to be made easy for you? If you really want to make good games you need to be willing to learn, its not handed to you on a plate.
I understand what you are saying. And of course I DON'T xpect game making to always be made easy for me. We really do need to be willing to learn in order to make good games. However, my point is NOT just the fact that physics is VERY easy in Construct while it is MUCH more difficult in MMF2. My point is also that I am hoping Clickteam will take a very careful look at Construct and try to include many of the features that Construct already has. I don't mean just the way physics in done in Construct, I also mean many of the other features as well.
Futhermore, I can't help but wonder what the platform movement in MMF2 is still so buggy even through it was made from the "ground up". Why not take care of this after all of these years. Additionally, why is MMF2's image editor missing so man of the features that WERE in MFF?
These are questions I am just asking because I love Clicktean and some people would choose a free product that has what they want as opposed to paying over $100.00 for a product that does NOT have what they want. So why not do all that can be done to improve MMF2? Maybe in the next builds?
By the way, some thing ARE handed to you on a plate when you are using Construct, like physics in Construct. Just a thought.
Originally Posted by -Adam- Now Construct is MANY advantages over MMF2, for example, with Construct a person can do physics without any difficulty. This is done with an easy to understand panel that handles physics with no problem. If you try to do physics with MMF2, you have to spend a great deal of time understanding and working with the physics extensions that are available for MMF2. Creating good physic code in MMF2 is NOT easy!
Why do you expect game making to be made easy for you? If you really want to make good games you need to be willing to learn, its not handed to you on a plate.
But that is the point of MMF2! I bought it so i would have things handed to me on a plate - i've learnt other languages before and to get really good you need to spend a hell of alot of time learning it inside-out. The point if click products was to short-cut that. Asking for more from Clickteam is a valid request.
Are you being serious? If you want that, buy Warioware DIY. It does everything for you
Even with Click products you can't expect to have it handed on a plate. Making games with them is easier than most ways of developing, saying that you expect it handed on a plate is actually rather stupid, hence why I cant tell if you're being serious or not.
I know theres plenty of fanboyism and irrational and biased views of construct vs mmf2 and all that blah blah blah. But I take a look from a more utilitarian standpoint, and I'm not all that impressed with construct 2. And I really liked tigerworks, mind. I think its the fact that Construct 1 was never a finished project that really rakes against it. Imagine anyone who actually tried to create a serious project and learned that it will never be finished, the loose ends never sewn, and construct 2 not backwards compatible. Its not a suitable platform for developing major projects.
And now Construct 2 comes with a hefty and inconvenient and non-package price tag, but the promise isn't there.
Frankly, the level of abstraction presented in a computer science standpoint of the language/compiler/ide of Construct vs MMF2 goes against logic. The entire point of MMF2 is to give you an environment where you trade efficiency and scope in exchange for easy and fast development. The more ambitious and well programmed you get in either MMF2 or Construct, the less difference there is in development time from creating it all in say, C++. For example, I really wish I had created Asunder in C now, but at least its functional enough to finish.
But what you need to realize is that these are rapid prototyping tools/languages/ideas. Not meant for large ambitious professional projects, but for smaller scale rapid game and application making. Even in large game projects, MMF sees use by developers who want to create mockups or even just dev tools. But for creating things like flash applications - its absolutely the ideal product.
But all the advantages Construct seems to offer over MMF2, its tools and abilities that stretch towards the domain of DIY large complicated projects- not rapid prototyping. MMF2 shines when you can get almost all your coding accomplished by built in extensions, built in active objects and animations, built in effects and the plethora of 3rd party extensions, scripting tools, and community support. Especially the latter.
And that doesn't even scrape the range of exporters that MMF2 has due to being firmly planted in the ground for so long now. I can take the same game with the same graphics and code, and export it as a .exe, a flash app, a java application, a java applet, a unicode text .exe, a hwa .exe, or a python binary that can run on unix/max/windows all together.
Construct 2 might have been better than MMF2, if you uprooted everything in MMF2 and gave all that community, extensions, exporters and plethora of work thats been done to it. But it doesn't have that firm ground. And its not an argument about fairness or "what ifs". Sure, it [i]could[/i] have been better, but MMF2 has the advantage of having been around so long with so many people and garnering all that support. And that software engrainedness is a hurdle in many places of adoption, not just MMF2 vs Construct or w/e. Look at Ubuntu vs Windows, heh. And its not all one sided stories- look at Firefox & Chrome against IE.
From a utilitarian standpoint, if you want a rapid prototyping tool, one you can pick up and develop with, without large amounts of CSci background- MMF2 is just the logical choice, as much as I like Construct. Even the risk analysis alone should tell anyone that, because as much as I respect the work they've done, theres no stable footing for Construct, period. And maybe some day it will indeed outstripe MMF2, and if so, good for them! But it doesn't yet.
Originally Posted by -Adam- Making games with them is easier than most ways of developing, saying that you expect it handed on a plate is actually rather stupid, hence why I cant tell if you're being serious or not.
I'm being serious. And if you say that is "rather stupid" then that is your opinion, not a fact.
To quote the MMF2 page on the Clickteam website, "...you can get superior and impressive results with no programming skills or knowledge required". So yes, i want it handed to me on a plate, it's what they promised.
Originally Posted by Marko
To quote the MMF2 page on the Clickteam website, "...you can get superior and impressive results with no programming skills or knowledge required". So yes, i want it handed to me on a plate, it's what they promised.
That means that you need no programming skills to make great games with MMF2, you still have to make it yourself.
I don't get it - why is asking for better built in movements in a drag-and-drop game-making application asking for too much? Especially when the competition does give you better built in movements?
What I think marko means is that mmf2 does most of the work for you, not necessarily everything.
When most of the hard work is already done either via hard coded mmf functions or extensions I think it's fair to say that by using mmf you do have things handed in a plate. You just need to know how to use them.
Originally Posted by -Adam- Now Construct is MANY advantages over MMF2, for example, with Construct a person can do physics without any difficulty. This is done with an easy to understand panel that handles physics with no problem. If you try to do physics with MMF2, you have to spend a great deal of time understanding and working with the physics extensions that are available for MMF2. Creating good physic code in MMF2 is NOT easy!
Why do you expect game making to be made easy for you? If you really want to make good games you need to be willing to learn, its not handed to you on a plate.
Isn't your post contradicting itself a bit?
You say that Construct makes Physics easy (IE: the feature is handed to you on a plate) and that Physics are very hard to pull off in MMF, yet you use this as an argument for "learning" to use Construct as not everything should be handed to you on a plate?
Originally Posted by -Adam- Now Construct is MANY advantages over MMF2, for example, with Construct a person can do physics without any difficulty. This is done with an easy to understand panel that handles physics with no problem. If you try to do physics with MMF2, you have to spend a great deal of time understanding and working with the physics extensions that are available for MMF2. Creating good physic code in MMF2 is NOT easy!
Why do you expect game making to be made easy for you? If you really want to make good games you need to be willing to learn, its not handed to you on a plate.
Isn't your post contradicting itself a bit?
You say that Construct makes Physics easy (IE: the feature is handed to you on a plate) and that Physics are very hard to pull off in MMF, yet you use this as an argument for "learning" to use Construct as not everything should be handed to you on a plate?
Actually the first paragraph isn't mine, I just didn't quote it properly.
I think it's obviously difficult to make a single product that will please both lazy beginners and advanced developers - there are just going to be too many compromises.
For anyone serious about making decent games, MMF2 is clearly better than Construct, while Construct may have more noob-friendly features.
Where Clickteam have gone really wrong, is with TGF2.
It *should* be noob-friendly, with solid built-in movements, physics, etc...
But it isn't - it's just as complicated and requires just as much effort to make a game (if not more, since it lacks extensions) as MMF2.
Anyway I haven't used an MMF physics extension and I haven't used Construct's built-in physics, but looking down your nose at the latter is just ridiculous - in either case you're using someone else's engine which is typically the done thing when implementing physics in a game. Construct just happens to do it better, as it does many things
Everything except having the huge resources of extension equivalents and built in tools that make it useful for rapid prototyping. When you're choosing to use a tool like MMF2 or Construct over say C++, the advantage is faster development time and ease of use, at the cost of power and efficiency. MMF2 has vast advantages over Construct in terms of ease of use and faster development due to the resources already available to it. Construct has marginally higher efficiency and power, but not on orders of magnitude. Its the same level of abstraction and high order- its not like you're working in machine code.
Take, for example, Microsoft Windows 7. Someone could create a new operating system from scratch that was far more efficient and elegant and secure than Windows by abandoning the huge feature bloat in it and starting anew. But its that same feature bloat, and the fact that its engrained as an industry and personal use standard, that makes Windows so hard to replace. Would you start programming games that could only run on a Unix box? Neither would I.
Because being new and shiny just isn't enough. Theres such a wealth of benefits to the age of MMF2 and its community. And construct may indeed be a stronger, more efficient and sleeker engine- but it doesn't have the same resources at its disposal. And I applaud them for the job they've done on it, and indeed in years to come Construct may reach a phase where it is a serious contender. But from a strictly utilitarian point of view, theres no reason to develop in it over MMF2 yet. The facts that its not stable and has a horrid pricing model and that construct 1 was a dropped project are easy and cheap ways to detract from Construct 2- easy to score points, but the underlying issue is really just that of community support and resources.
Construct is great, but the only thing it has going for it in these discussions is wanton fanboyism, something clickteam supporters are just as guilty of. And frankly, that shouldn't be the case- they are not just similar products with similar communities, but rather the latter is largely the same. There shouldn't be any bitterness there. I think its more important to take a objective point of view and just look at what it has going for it, before you swear by either.
And frankly, by the time you are strong enough at programming to be able to argue meaningfully for either of them, you should already be primarily C or Java or SQL or whatever, anyway.
Can't quite agree with Pixelthief, although many of his points are valid. Of course there are reasons to choose Construct over MMF. Some of which he mentions himself. Not only are we talking a "stronger, more efficient and sleeker engine", but also a vastly superior event editor and easier syntax. It gives me a headache trying to achieve even a remotely complex event structure in MMF's editor. There is a reason many of the current Construct users are former users of Clickteam products. Just like myself. Which has nothing to do with fanboyism, but common sense to choose the superior tool. Like others have already mentioned, I would only use MMF for the ability to export the game to different platforms. That's the main thing it still has going for it. A temporary advantage, seeing the multi-platform design of Construct 2.
I don't want to diss Clickteam or put Scirra on a pedestal, I couldn't care less. If Bin Laden made the next great WYSIWYG game creator app, I would be all over that. One has to use the tool that does the job best, it's as simple as that.
And if you still sport the opinion that Construct 1 isn't up to the task of creating a game of commercial quality, you probably haven't seen the following videos yet:
The Animations in Yokai totally let it down. The character moves faster than his running animation. Also, you're pretty much going by the artwork, claiming that they're "commercial quality", but if you take that away, they're pretty much regular platformers that could quite easily be made in MMF2.
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
Originally Posted by -Adam- you're pretty much going by the artwork, claiming that they're "commercial quality", but if you take that away, they're pretty much regular platformers that could quite easily be made in MMF2.
I was going to say this earlier, but figured I'd just get called an asshole for doing so, LOL. Thanks.
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.
I've helped build several RTS's from the ground up, so actually yeah I would have quite the idea of what I'm talking about.
And frankly, its the sort of thing you need to try to tackle to understand why its so important to understand every facet of it.
The support forums get flooded with requests by people trying to build RTS's once in a while, and they are mostly lost causes. To have anything on say the level of Starcraft, you'd need to construct a node map with traversals for the pathfinding, and 'fog of war' opens up a whole can of worms, and thats even before getting into the guts of the necessity of efficient unit grouping / finding algorithms.
Lets say something as basic as wanting your unit to attack anyone who comes within "600 range". How do you do this? You'd need to group all objects and compare their range, and over N objects shooting each other you'd have an O(N^2) algorithm? Or you could have tiles on the map store the positions of objects and iterate over them for an O algorithm with lesser results with huge memory constraints, or you could use clever tricks to sort objects by their X/Y positions and quickly pull them for AOE's, but you'd need to implement something like quicksort.
You can't do these sorts of things from widget style extensions. These are the core of an engine. You have to know how to do them and build them yourself to have any sort of respectable end product- you can't just plug a public pathfinding object into a public selection object and how for something that doesn't shrink down to 5 FPS when only 20 objects exist and doesn't do at all what you wanted.
We're talking about the fundamental data structures of a game. The need for pathfinding that explicitly maps into the level editor of your game- its not going to be the same from one game to another, and an extension based pathfinding would either have to be so incredibly general (ie a tree traversal algorithm) that it wouldn't save you any work, or it would have to be so exclusive that it would only work with a specific kind of structure that makes it worthless for unique projects- the paint-by-numbers problem.
You can't just hope for a one-size-fits-all solution. Thats naive, that doesn't work. You're better off using the Warcraft III World Editor and modding from there. If you want to know how to build an RTS from the ground up, I could explicitly describe all the pseudocode of what you'd need, and its not a short list.
What you're failing to identify is that movements such as "move in 8 directions based on keyboard" are so basic that the discrepancy between what you can accomplish with custom coding and built in movements is marginal. Yes, most serious projects will need everything coded from the ground up. Simple flash games might get by with them, especially when you're just rapid prototyping. But built-in RTS movements? Don't be too nutty now. Theres no way to build a 'small scale custom RTS' like you could poop out a flash bat&ball game. Its the difference between building a car out of legos and a car out of auto parts. And if you know the mechanics behind it, its not impossible.
I'm aware theres plenty of irrational fanboyism on each side of the debate, and clickteam diehards are just as prone as constructors, but you should both really tone it down a notch. You have to stop seeping so hard into one category and take a look at things from a broader view. Construct is a great little piece of coding, but its new and unpolished and lacks the community behind klik. Klik is being heavily updated enough to prevent it sinking as a legacy software, but still has quite gaping holes. But if you can't step back and see both sides of it, all you'll accomplish is moving a lot of wind, not informing anyone or swaying opinions.
I like it better than Construct 1, cause it can export to HTML5.
In fact I'm going to pay for it when it's decent enough to make a game with.
I think they should make it compatible with iphones and such, but at the moment there doesn't seem to be a way to intercept touches
Originally Posted by Johnny Look 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.
Johnny, if he doesn't know what he's talking about then you most certainly do not.
Out of everyone on the site I'd have to say that Pixeltheif has the most knowledge on this subject.
Please don't think of yourself more highly than you ought.
After reading this entire thread, I have come to a conclusion. MMF2 is more powerful, more customisable, and requires you to know what you're doing in order to create your own product. On the other hand, Construct has better built in features that make you not have to do anything on your own. I quote, "Better built in movements, built in physics, etc.". Physics in MMF2 are easy once you know what you're doing. And since Construct 2 is just coming out, MMF2 had them first
Good day to you all
Have you even been far as decided to use even go want to do look more like?
We'll see jacob. Construct 2 is not Construct. It is an infant in comparison to both Construct 0.x and MMF2. The only selling point for me right now over a new mmf is that contrary to what you said, "MMF2 is more powerful, more customisable" Construct 2 is actually potentially FAR more powerful and customisable (emphasis on 'potentially'), with its supposed development around addon runtimes. Not like mmf2 where they keep having to code proprietary runtimes. or maybe the mmf2 runtimes ARE easily made as addons, but they arent letting the users in on that, Construct 2 is. The vibe Scirra is sending out is that their focus is on extreme extensibility for the forseeable future, to the point where there really won't need to be a Construct 3 for a long time.
Edit: And considering all the time I've been spending doing actual work in Java, C/C++, and C#, i would rather code extensions and runtimes FOR these products than actually using them myself.
They say that the HTML5 runtime will be open source but that is not exactly the term that should be used because it's useless for anything other than C2 so it would be more like a runtime SDK with HTML5 as a default example. The HTML5 runtime source code is currently not available to anyone yet either.
The thing is though C0.x is buggy and they basically gave up on it, the open source code is also not so "open" as it requires commercial library's before you can build it. Even though it's still a really early for C2 they now have put some time trial on it plus it's now closed source so it seems like they have totally dropped the whole open source thing other than the plugin and runtime SDK's. I like the way the current javascript plugin SDK works for C2 work though so it's not all bad but since it's just javascript i could just code this easily anyway in notepad if i wanted so i am hoping they will have a C++ runtime soon.
For Java and C/C++ you can already code extensions for these in MMF2 and there is the .net extension which allows coding with C# and i am also guessing there will be some sort of C# based SDK when the XNA runtime is released. I am sure C2 would have these at some point also but currently there is not much and i guess it could be a long time before they are done.
People forget that MMF3 could be released at some point also, since they already have the source code for many runtimes and extension even if they make it 100x better and totally re-made they could do this much faster since they have a load of code to work with. I have been using Construct 0.x for about 2 year now but found it to be totally buggy as i have had many crashes and found bugs. Construct has a nicer editor, good for HWA effects and nicer for built in movements but even with a GUI that seems a bit more retro now i still find MMF2/MMF2 HWA much more stable and powerful with what it can do and think it's the best game/app maker to use other than coding.
Guys honestly just forget about the whole MMF&Clickteam vs. CS/Scirra thing.
Hands down MMF wins and anyone that says Construct will give it a run for its money is forgetting the fact that in 2+ years they were unable to achieve stability with an even more simple version of construct, let alone finish it. The only worry for you clickteam fans is the software being pirated.
CS can output to HTML5, and you can make your own runtimes... Still got to take into consideration that these guys lose steam quickly.
As for the excuse of a quarter million lines of code being worth the extra money (even though proof of a WORKING CONCEPT has never been delivered in all these years with Scirra)...
The entire code base (including scripts) for Khan Adventures nears half a million lines, and on top of that I've completed all the graphics, sounds, music, scripts and storyline myself - so, the amount of work you have done is not a legitimate reason to ask for money. Producing something FINAL, that WORKS AS IT SHOULD is worth money. People buy results, not half-finished ideas.
And that is not to mention they wouldnt even have a community to sell to if it werent for those of us that pushed it so much through word of mouth.
They could have at least had the audacity to finish the product we promoted for them for free, before deciding to abandon it thus wasting 2+ years of our time helping to report bugs and help with ideas on how to improve the product. Asking for money doesn't sit well for many of us - not until there is something to buy.
As an engineer whom does software and hardware for a living I agree with Codemonster in a way.
Construct was buggy and unstable. Instead of fixing it, they have instead decided to make another version from the ground up, which you may think is a good idea presuming a process of simplification would be carried out to help increase the odds of producing something commercially viable. Instead of this, it seems they have decided to re-write an unfinished product, and in the process make it more complex.
I would love to see Construct become a real finished product, but I think in terms of planning they are going in the wrong direction.
Gamester - Absolutely not, I'm assuming you didn't understand my point. With that being said, even if I did wish to sell such a product, it would clearly be that way from the beginning, worth the money and without bugs that affect the core functionality of the product. Excellent critism though, from a guy whos claim to fame are two projects (with either minimal or stolen artwork) that, much like Scirra, are obviously buggy and not updated for huge amounts of time.
Originally Posted by Codemonster Gamester - Absolutely not, I'm assuming you didn't understand my point. With that being said, even if I did wish to sell such a product, it would clearly be that way from the beginning, worth the money and without bugs that affect the core functionality of the product. Excellent critism though, from a guy whos claim to fame are two projects (with either minimal or stolen artwork) that, much like Scirra, are obviously buggy and not updated for huge amounts of time.
Hagar - Yes, that is precisely what I mean.
I was just messing with you, and i'd give you props if khan is completed whether I like it or not, but wow you're an idiot. I never "claimed fame" over my unfinished projects, or anything for that matter. The projects aren't being worked on, you're right about that, but the art is far from stolen. The art in the game with the frog was 100% done by me in very little time. The first screenshots of Eden (the really bright colored one) contained my art (everything but the character/bird) , a friends art, and ONE sprite taken from zelda which was mentioned and replaced as soon as my friend got around to it. I just needed something with flying animations to see if the movement looked alright - that is probably the first time I've ripped a sprite since I was 9. The screenshot with the large sprites was 100% my friends artwork.
I hate to pull the jealous card, but why would you go so far as to claim that some half-assed mediocre artwork is stolen? Not to mention neither engine had any bugs in it as I refuse to release or show anything with bugs. The only thing I remember ever being "wrong" with Eden that wasn't really a bug was a misaligned hotspot that made it look like you were floating off the side of a platform. Something that I, frankly, dgaf about as that can be fixed at any time.
Consider suicide
Edited by GamesterXIII
Admin Note Do not abuse other members (Rule 4). You have been warned.
"To have anything on say the level of Starcraft, you'd need to construct a node map with traversals for the pathfinding, and 'fog of war' opens up a whole can of worms, and thats even before getting into the guts of the necessity of efficient unit grouping / finding algorithms."
Fog of war can be done rather easily using the active overlay object for example, as for unit grouping and finding it's relatively easy when you know how it's done in any other language.
"Lets say something as basic as wanting your unit to attack anyone who comes within "600 range". How do you do this? You'd need to group all objects and compare their range, and over N objects shooting each other you'd have an O(N^2) algorithm? Or you could have tiles on the map store the positions of objects and iterate over them for an O algorithm with lesser results with huge memory constraints, or you could use clever tricks to sort objects by their X/Y positions and quickly pull them for AOE's, but you'd need to implement something like quicksort."
Or you could just have a circular sprite with 600 pixels of diameter attached to the unit sprite and then check for collisions. If it's colliding, attack. Pretty simple I think. Alternatively you could just check for distance with the closest enemy unit much like you would if it would have been done in c or c++.
Anyway I think it's pointless to discuss if it can be done or not and why, this discussion will only end when someone shows if it can be done or not. I know it can be done in construct at least because I did a basic rts skeleton with it before. I'll try to find the source and post it here, if not I'll recode it again.
"Johnny, if he doesn't know what he's talking about then you most certainly do not.
Out of everyone on the site I'd have to say that Pixeltheif has the most knowledge on this subject."
Ahah sure. On what grounds do you base your opinion ?
Or you could just have a circular sprite with 600 pixels of diameter attached to the unit sprite and then check for collisions. If it's colliding, attack. Pretty simple I think. Alternatively you could just check for distance with the closest enemy unit much like you would if it would have been done in c or c++.
Ye haven't actually tried this, have you? Thats exactly what I'm saying doesn't work, as you scale up a game. A 600 pixel sprite will either not give you a proper distance value (square) or will require vast amounts of processing for the collision map (circle) that makes such a method extraordinarily slow past a few units. You can't create a game where 200 units are fighting 200 units using "circle detectors", it don't work. Thats ok for doing little platformers and flash games, but once you approach RTS's, you need to build the mechanics behind them soundly to scale it up.
One possible way is to sort all objects into two lists, one by their X value and one by their Y value, using a quick sort algorithm (note: I don't mean "quicksort" itself) to add/remove objects, and apply a search algorithm (ex, binary) to this sorted list within the bounds of a coordinate, in order to quickly retrieve a list of all objects within a specific range of a point, for use in attacks, AOE spells, orders, AI, etc.
What you cannot do is simply compare every unit to every other unit. That quickly gets you high polynomial time complexity algorithm. Every unit on the stage comparing to every other unit on the stage using a square root, 50 times per second in a worst case? Hah. Is that O(N^3) or O(N^4) or what?. Even using an approximation distance algorithm thats optimized like the min/max one, your game would fall apart as it scales upwards- too many units would make it slow the bejesus down, and "too many units" would be about 30.
If you want to build something like Starcraft, you have to look at how its programmed. You can't seriously think that they made their RTS by putting a big 600 diameter circle on a collision map for every unit every timer ticker
Anyway I think it's pointless to discuss if it can be done or not and why, this discussion will only end when someone shows if it can be done or not. I know it can be done in construct at least because I did a basic rts skeleton with it before. I'll try to find the source and post it here, if not I'll recode it again.
"Johnny, if he doesn't know what he's talking about then you most certainly do not.
Out of everyone on the site I'd have to say that Pixeltheif has the most knowledge on this subject."
Ahah sure. On what grounds do you base your opinion ?
I can't believe I missed the whole part about the circular object.
Thats where theory and practical application come in to play. In theory it would work, but that is far from optimal as PixelThief has already pointed out.
Why do you think unticking "use fine collision detection" on large objects and perfectly square objects drastically speeds up MMF games? I guess you could get it to work if the game was tiny.
Originally Posted by Johnny Look Alternatively you could just check for distance with the closest enemy unit much like you would if it would have been done in c or c++.
I had to laugh at that.
So, how would you know which one is closest if you don't know the distance, eh?
I'm actually curious how a game like SC or WC3 or SC2 finds their (objects in a radius). I think the approach of sorting object by x/y, searching over those lists, and then culling the circle-edged objects, would probably be so damn efficient it makes me imagine they did something entirely different, given how poorly coded many parts of those games were
Of course that really gets into how costly the loop overhead is against executing a distance check- it gets down the fundamental idea of how many clock cycles it takes. Using a distance equation that takes an insignificant amount of time compared to elementary instructions on most hardware, this would be no more efficient than just iterating over all objects and checking their dist. But in an abstract sense it might be more efficient.
One thing you'll learn in computer science is that its very easy to write a program that will solve any computer problem. The problem is in solving them in any meaningful time and space (hey, look, the two themes of my indie project ^___^). A naive algorithm trying to solve an NP-complete problem might "guarantee" the right result, but it might take 7 billion years to compute and more memory then there are atoms in the universe. You can easily write an algorithm that will "solve" a 1024 bit RSA encrypted key message given a ciphertext and plaintext pair. Just iterate over all 2^1024 possible vectors. Your computer might blow up when the sun goes nova before then.
Its not hard to write an RTS "engine". Its hard to write one that will actually run in a meaningful way, where you can have large amounts of units all doing their pathfinding, collision detection, fog of war, AOE effects and so on all at the same time while running at 60 FPS on a modern personal computer. You *could* use a 600x600 pixel circle detector over all objects, and then I'd have to explain to you why that takes 600*600*N^2 loops to do collision detection on N objects.
Honestly, I think the truth lies somewhere between what Pixelthief and Johnny Look are saying.
RTSs aren't an easy genre by any means (and circular detectors are certainly not the way to go), but I don't believe they're as bad as Pixelthief is making out, and I know from experience that some parts of what he has been saying are not right.
Anyway, all that's besides the point.
The original argument was over the value of a built-in RTS movement.
I would say that RTSs are generally *very* formulaic. You can look at the slew of C&C clones released in the mid/late '90s, and the unit selection / movement systems used in those games are every bit as similar as the movement engines used in different platformers.
As for it resulting in "cookie-cutter" games - well, I don't see anyone criticising StarCraft, which if we're honest, is just a C&C clone with a few extras tacked on.
pixelthief: I don't know about MMF2 but I tried stress testing construct with over 1000 objects in a level in a 4 year old laptop with no major slowdown, if at all.
Anyway, that was the first thing I thought of, I never really tested it but even if that was the problem construct has a built in turret movement that checks for the closest entity within a specific range. If you want to see it for yourself there's a basic rts example that comes with construct.
urbanmonk: Perhaps because you don't necessarily need to ?
Originally Posted by Codemonster Gamester - Absolutely not, I'm assuming you didn't understand my point. With that being said, even if I did wish to sell such a product, it would clearly be that way from the beginning, worth the money and without bugs that affect the core functionality of the product. Excellent critism though, from a guy whos claim to fame are two projects (with either minimal or stolen artwork) that, much like Scirra, are obviously buggy and not updated for huge amounts of time.
Hagar - Yes, that is precisely what I mean.
I was just messing with you, and i'd give you props if khan is completed whether I like it or not, but wow you're an idiot. I never "claimed fame" over my unfinished projects, or anything for that matter. The projects aren't being worked on, you're right about that, but the art is far from stolen. The art in the game with the frog was 100% done by me in very little time. The first screenshots of Eden (the really bright colored one) contained my art (everything but the character/bird) , a friends art, and ONE sprite taken from zelda which was mentioned and replaced as soon as my friend got around to it. I just needed something with flying animations to see if the movement looked alright - that is probably the first time I've ripped a sprite since I was 9. The screenshot with the large sprites was 100% my friends artwork.
I hate to pull the jealous card, but why would you go so far as to claim that some half-assed mediocre artwork is stolen? Not to mention neither engine had any bugs in it as I refuse to release or show anything with bugs. The only thing I remember ever being "wrong" with Eden that wasn't really a bug was a misaligned hotspot that made it look like you were floating off the side of a platform. Something that I, frankly, dgaf about as that can be fixed at any time.
By the way, I hope it's clear that I agree with you when you say that mmf2 or construct aren't the best way of making a rts. It's definitely not. But to make even a really simple rts in c++ you need to have quite some knowledge in quite a few areas, but to make the same thing in construct or mmf2 is much simpler but when going past that everything gets harder.
I know it is possible to make a starcraft or warcraft clone in construct and I believe that, at least in theory, it should work in mmf2 too.
My point being, if you are not fluent in c++ and don't know jack about pathfinding then construct or mmf2 are both viable alternatives if you're not too ambitious.
I think you really need to understand the underlying algorithms for how these "closet object finding" and "aoe effect" mechanics work. Like I said, its very easy to build something- its harder to make it *work*. While you can put together an RTS engine that will work on paper, it will fall apart at the seams as you start scaling upwards with it. Inefficiencies compound, and you need to have built upon a firm base to make the whole structure stay standing.
For example, that "turret movement" that finds the closet object may need to iterate across every single object in your stage and run a fast loop to calculate the distance and compare. And when you have N objects with turrets comparing 50 times per second, you will have N^2*50 comparisons going on; having 1000 objects on screen will lead to 50,000,000 distance checks, which may take 20-50 clock cycles on architecture compared to basic operators that take 1 cycle. You end up doing 2.5 billion cycles per second just to find distances between objects, not even accounting for the overhead of the structure, overhead of the compiler, overhead of the game itself and overhead of the CPU. Now how that translates into machine code and architecture is beyond me, or anyone on this planet really, but one thing I can tell you is: It will be slow. A single core might run at 2.27 GHz
Now these numbers are meaningless- they are gross simplifications of much more complicated architectures. But the point is simple. If you try to naively make an RTS with an inefficient architecture, it will fall apart as it grows. You either have to make it stay small, or know what you're doing, or else use someone else's architecture and make it a complete "paint by numbers" game like RPG-maker.
MMF2/Construct can be great for small flash games and platformers and bat'n'balls and so on, because they are small and not resource intensive. But attempting to build a fully functional moderate sized RTS in them is like building a house with 3 car garage out of tinker toys. Its not impossible, but it would probably take more work than actually learning how to build a house the right way.
I have never understood why MMF is so painfully slow even in fast loops, but this is the plague of high level languages.
Many people at uni use Python and Matlab to do data processing, which takes hours. My first matlab based analysis application did. I re-writ it in C , and the processing now takes about 20 seconds. My point? Trying to make an RTS in MMF is kind of like placing a bet on a 3 legged horse. It could win, but the odds of it winning are low.
By the way many modern processors can do many instructions and MAC's per clock cycle. Some i7's can do over 40 instructions per clock. A run of the mill core 2 duo can theoretically do 22.4 ( double precision) or 44.8 Giga FLOPS (single precision floating point operations per second), not that you will ever get there performance wise.
An RTS should be trivial computationally wise for any modern PC, given efficient algorithms and an efficient language.
My radius finding algorithm would be to first use a rectangular bounding system, and create a list of objects falling within this rectangle. Then calculate the distance to each object on this list (upon finding them) using trigonometry, and then create another list with objects falling under the distance desrired. I think this should be fairly quick, as you would optimising out units which are bound to be outside the desired radius and only performing the "heavy" arithemetic on plausible objects.
(in reality i would only use one list, but conceptually thats the algorithm)...
My job: DSP/High speed instrumentation researcher , re-writing "slow" C functions in hand optimised assembly is part of life for me. I can beat a C compilers optimiser in terms of cycles per iteration. Writing assembly is unfortunately more involved though, as you must consider how many cycles each instruction will take before the result is stored in a register.
And remember, if you see NOP in assembly, it stands for NOt oPtimised!
Well, the easiest and most efficient system would be to just not check every object every frame.
I mean seriously, if a tank comes within range of a turret, sure the turret should notice - but does it really need to notice within 1/60th of a second?
And of course, you could just put a cap on the number of units allowed.
eg. "Age of Empires" limits you to 50 units, which improves both performance and gameplay - http://artho.com/age/bruce50.html
I guess my point would be that there are lots of ways to get acceptable performance, that don't require some complicated algorithm.
Sure you might not be able to make an RTS to rival "StarCraft", but so what? I don't see anyone here making platformers to rival "Super Mario World" either, and that's supposedly an easy genre to make.
Originally Posted by ..::hagar::.. I have never understood why MMF is so painfully slow even in fast loops, but this is the plague of high level languages.
Because MMF2 is a very high level intepreter. When you have a fast loop, it simply adds that many lines of MMF2 code to the event tree. So when you have a loop that reads 50 times, it will just parse that same event 50 times in a row; it wont shortcut and reduce that event to its elementary actions and repeat them based on jump statements or anything like C->Machine code would. Its a very, very high level language with tons of overhead.
Many people at uni use Python and Matlab to do data processing, which takes hours. My first matlab based analysis application did. I re-writ it in C , and the processing now takes about 20 seconds. My point? Trying to make an RTS in MMF is kind of like placing a bet on a 3 legged horse. It could win, but the odds of it winning are low.
By the way many modern processors can do many instructions and MAC's per clock cycle. Some i7's can do over 40 instructions per clock. A run of the mill core 2 duo can theoretically do 22.4 ( double precision) or 44.8 Giga FLOPS (single precision floating point operations per second), not that you will ever get there performance wise.
An RTS should be trivial computationally wise for any modern PC, given efficient algorithms and an efficient language.
Well see, thats the key- given efficient algorithms, efficient language. And then yes, they can be trivial. But you really need both. An inefficient language may not be able to pull off efficient algorithms. I just did a project on hash chaining in C that took 4 hours to execute in C, didn't even get 1% done in that time on python, and in MMF2 may have taken many solar ages.
My radius finding algorithm would be to first use a rectangular bounding system, and create a list of objects falling within this rectangle. Then calculate the distance to each object on this list (upon finding them) using trigonometry, and then create another list with objects falling under the distance desrired. I think this should be fairly quick, as you would optimising out units which are bound to be outside the desired radius and only performing the "heavy" arithemetic on plausible objects.
(in reality i would only use one list, but conceptually thats the algorithm)...
Mind thats still an O(N^2) algorithm for N objects comparing to N objects. Its probably the exact method that games like Starcraft use, checking in a rectangle and then culling in the ellipse. But I think an approach that uses a sorted list could vastly reduce the time complexity by not requiring a comparison on every single object. See, you'd have to compare every single object against that rectangle, and while the math is trivial its still an O(N^2) process. If you used a sorted list that ticked up once in each direction until it found the rectangle edges and culled from there, I imagine you could pull off an N*Log sort of complexity.
My job: DSP/High speed instrumentation researcher , re-writing "slow" C functions in hand optimised assembly is part of life for me. I can beat a C compilers optimiser in terms of cycles per iteration. Writing assembly is unfortunately more involved though, as you must consider how many cycles each instruction will take before the result is stored in a register.
And remember, if you see NOP in assembly, it stands for NOt oPtimised!
Yeah, its easy in theory to say that a distance algorithm will be 'costly' compared to elementary arithmetic, but I'm not expert on hardware or low level instructions. And I imagine theres cases where the cycles used in instructions is irrelevant due to overhead. For example, the approximation algorithm for distance thats in sketchy's examples is actually slower in MMF2 than just plain sqrt(dx^2 + dy^2), because of the huge overhead on the MMF2 interpreter. And I don't know how that applies to stuff like C and its square roots in the math library.
But one things for sure- you have to have at least some moderate idea of what you're doing. If you're comparing collision by iterating over a 600x600 collision map on every single object against every single object, it doesn't matter what hardware or language you're using- its going to suck. RTS's spiral upwards so quickly that it definitely matters to have some grasp of efficiency.
Yeah like Sketchy says, its not going to be worst case scenarios 60x per second per object against all objects. Modern RTS's use all sorts of methods for conserving computation- pathfinding might be done a single time per movement and then save its movement, timer ticks control how often something checks for radius, many RTS's cap units. But in something like MMF2 or construct which are so high level, even these small amounts of units with conservative computations still spiral upwards incredibly fast. Pathfinding is costly. Fog of war is costly. Radius grouping is costly.
Hey guys. Arima (disclaimer: a moderator) from the scrira forums here. Thought I would mention a few things:
First of all, the licensing model is not a subscription. You buy the program, it's yours. It doesn't expire like a subscription would.
The reason for the purchase the program and get two years of updates model is because the developers want to have a continuous development model. Instead of purchasing construct 2, then waiting for construct 3 and paying for the upgrade when it's completed, construct 2 remains in continual development and releases numerous smaller updates more frequently. This way you get new features continuously instead of having long gaps of waiting between versions.
If you think about it, it's not really all that much different from the normal model, where you buy a .0 upgrade and then receive free updates until the next .0 upgrade - and .0 upgrades often can take a year or more to arrive.
As for Scirra not completing C1, it was a good idea in my opinion. C1 wasn't designed as well as it could've been, and made things like making extra exporters prohibitively difficult. Since they started on C1 they've had industry programming experience and have learned a ton. It would have taken far longer to improve C1 than it would have for them to simply start over from scratch. Having used both C1 and C2 at very early stages of their development, the difference is like night and day. C1 was barely useable at the start, C2 is quite stable with very few issues.
Even still, it is possible to complete a medium sized project in C1. I'm doing it myself. There are some quirks and bugs you have to learn to navigate around, but a lot of programs, including MMF and game maker, have quirks that you have to learn to navigate around as well.
Pixelthief - something I don't think you realize is that construct's behaviors are coded in C plus plus (why don't plus symbols show up in the post preview?), making them much faster than events. As an example, I made a quick test that has 2000 sprites on two teams 'battling' each other. Using the turret behavior, on an older processor (AMD athlon 64 x2 4400 plus), having each sprite check for the closest enemy sprite every tick, I'm getting 150 frames per second. So that's 2000 sprites each checking for the closest of 1000 other sprites 150 times per second on an older processor. Behaviors are quite fast.
Well thanks for the information pixeltheif . It has just put me off MMF even more .
Sketchy: Age of empires is quite old although sometimes I think limiting unit count is good for gameplay in an RTS. Makes strategy more important than just tank rushing (pick unit of choice relevant for the game ). I have no want nor desire to make an RTS either.
Just to back up Arima (and my argument) up, Supreme Comamnder can have 8000 units in play on a multiplayer map (1000 per player), and this cap can be upped with mods. My PC runs it fine, and it's 3D too so its inccuring a lot more computation than just a 2D RTS. Gieven a decent language and algorithms a 2D RTS should be compuationally trivial for any modern pc. If it's not, its due to the language or the algorithms used.
I fully understand what Sketchy and Pixeltheif are saying though, about MMF overheads, I have already done experiments with MMF (hence the horse betting analagy i used earlier).
Actually, thats the same problem you run into in Construct as MMF2 (both being high level interpreted languages). It can surely put someone off MMF2, but it shouldn't be putting you on construct unless you're failing to comprehend it. To get the same raw efficiency from either language you have to jump through the same hoops; programming in C. Whether that is through extensions or behaviours, doesn't really matter.
Pixeltheif of course I comprehend it , hence I am planning on using Irrlicht for future projects (Construct has never had a second look, sorry guys!). I never mentioned Construct as my new "choice" (jumped the gun a bit there dude!). I know Construct has addons/extensions to do this in C++, and they are not using events. I gave an example of what is possible when using decent algorithms and a decent language (Supreme Commander). I was agreeing that using C gives massive benefits over events in Construct or MMF.
I still love MMF, but for straight forward 2D games.
It's kind of ironic that Construct guys changed their pricing model to, let's say, less user-friendly direction just recently, as now they actually would have better chances to win MMF2 users over and convert them into Construct users, as Clickteam are apparently also moving towards quite different type of pricing than what the Click community has been used to before. I.e. the upcoming iPhone exporter has been mentioned to cost $249 + $99 for each released game without Clickteam advertisements. It's not final yet, but those are their plans. Give Construct more relevant runtimes and cheaper price - surely someone would jump over the hedge. With the current pricing model of Construct, that's much more difficult.
I'm not liking that new pricing model, and if that's true I won't be purchasing (or using) the new exporter, and Clickteam will lose me as a customer.
I do plenty of advertising for them myself, and I've converted many people to the klik way. This would be a slap in the face.
I surly hope this isn't being considered.
I say we boycott the new exporter if this is indeed true.
Originally Posted by MJK I.e. the upcoming iPhone exporter has been mentioned to cost $249 + $99 for each released game without Clickteam advertisements. It's not final yet, but those are their plans.
That just sounds terrible. It means you couldn't release your game for free without taking a loss, and that you'd have to sell at least 100 copies of a $1.00 app to break even. Not everyone wants ads in their creations; it can make them look less professional than games made without MMF2.
That makes the minimum price of a $1.00 app $249 (exporter) + $99 (yearly fee for iOS developers) + $99 (ad-free production) = $447.
Nothing has been finalized yet and they said they are monitoring the thread and consider all the comments posted there on the pricing model. Also the size and looks of the Clickteam logo that is planned to be forced to each application (also MMF2 Dev, but which can be removed with that $99 extra price per each released app), has not yet been announced.
Actually, having read the actual terms of the ad placement, I'm not sure it would be a problem for me personally, although again, I can see it being a problem for those who want their game to look professional. It's only on the loading screen that iOS shows when you first load the app though (which could be a very short amount of time) and there aren't ads interspersed as the user interacts with the app.
I boycott any subscription type affairs (WoW, Xbox live etc). I pay my money once for the software, and then that copy is mine to do with as I wish forever as far as I am concerned.
Unfortunately I think CT are falling into the trap of believing the iphone is a goldmine, and people will be willing to pay over the odds for a shovel and a pick. Plus we would not have a problem if Steve Jobbs actually allowed flash, but that would lead to his cut (the apps store and the apple developer license) missing out. That's the real reason he disallows flash...
Yeah paying for MMOs is totally dumb and it doesn't cost them anything to run thousands of servers with millions of people on total at any given point in time.
Originally Posted by GamesterXIII Yeah paying for MMOs is totally dumb and it doesn't cost them anything to run thousands of servers with millions of people on total at any given point in time.
I think you've got yourself a little fan Gamester.
However hagar wasn't saying that MMO's asking for monthly payments was dumb, just that he didn't do it himself.
So do you think that Clickteam's pricing model for the new runtime is fair Gamester?
Judging by the fact that this runtime doesn't require thousands of servers with millions of people?
Always ready to try and take the piss aren't you Clyde Frog? I do not have the time or inclination to sit on my arse all day playing an MMORPG or any other multiplayer game with a load of acne ridden basement dwellers I do not know or care to know.
Construct 2 sounds pretty good! I can see myself trying it out sometime in the future. I think the best thing about Construct 2 is its position as the up and coming dev tool and its active and suportive community.
Originally Posted by ..::hagar::.. Thanks Urban Monk & Hayo .
Always ready to try and take the piss aren't you Clyde Frog? I do not have the time or inclination to sit on my arse all day playing an MMORPG or any other multiplayer game with a load of acne ridden basement dwellers I do not know or care to know.
Its called flawed logic. "I boycott any subscription type affairs (WoW, Xbox live etc). I pay my money once for the software, and then that copy is mine to do with as I wish forever as far as I am concerned."
I didn't say I think you're dumb for not wanting to pay for MMOs. They're a waste of time.
my main problem with construct... the games never work on my computer.. they didn't work on my old computer.. they don't work on my girlfriends pc or her netbook and they don't work on my brand new one with a fancy 3D card and all the latest drivers etc. i'm not going to go on a hunt to download a directx 8 (wtf!!?!?!) driver to play a (most likely) shitty game.. hardly anyone else would bother either... does anyone else get this problem? i've never once been able to play anything made with construct.
I've never played a game in construct since theres never really been any big namers, but I saw people commenting on IGN about how the minitroid demo was very slow for some computers, because of construct. Compatibility issues that need to get worked out I suppose.
i've only ever attempted to try the example games on the construct website, not a good impression. us hobbyist game makers have enough troubles with motivation as it is.. i couldn't persevere making a game with construct having thoughts in the back of my mind that a large amount of people who try to play it will have prolbems running it..
Doesn't matter if you have a higher numbered DirectX you still need to have a lowered number DirectX. Would be good if Microsoft included DirectX in their updates. But yeah, DirectX installing is probably the worst thing about Construct.
Necroing this thread in order to provide an update: C2 now has built in turret movements and pathfinding along with a very simple RTS template built-in. It also has a tower defense example that when compared to mine http://community.clickteam.com/threads/87092-Tower-Defence-Kit-1-0 performs quite well, but 1/2 as good as F2.5.
Starcraft scale RTS is possible. Certainly possible. Check out my TD example, it can be easily scaled up. Re range checks per unit, Pixelthief's concerns can easily be overcome by only running the loop for every unit that is ready to shoot. Again, check out my example, 2000+ units able to do pathfinding and AoE stuff.
I feel like a traitor for saying this (I started out on Klik 'n' Play, TGF etc.) but...I love Construct 2 and could never go back to MMF (I have both an MMF2 license and a Construct 2 license). The way the events are set up lets me have as much freedom as I feel I have when I do something in real code (C, C#, PHP etc.). I'm working on a pretty big dungeon crawler project at the moment and I really love the way everything works.
Advertisement
Post Reply
Edited by Cecilectomy
)
.
jenswa.neocities.org
algorithm with lesser results with huge memory constraints, or you could use clever tricks to sort objects by their X/Y positions and quickly pull them for AOE's, but you'd need to implement something like quicksort.
