Disappointed over bad communications!!!

0 favourites
  • I never wanted to sound like I'm angry about C2 at itself.

    I just wanted to say that if we pay 100€ (in my case), get a 1st class game editor and tons of possibilties to make games, we expect the game to at least run stable and bugfree on every plattform that is mentioned and promised, not only the PC.

  • I think what is happening to Construct 2 is basically what happened to Construct Classic. It's buggy, unfinished but Ashley has moved on to Construct 3, leaving behind an unfinished product with which only a handful of developers, if even that, made a succeeded game with.

    CC - Iconocaust (or whichever the name was, didn't remember it properly) and Minitroid (non-commercial, apparently was a nightmare to make).

    C2 - The Next Penelope, Cosmochoria, Airscape

    Correct me if I'm wrong, but in both iterations of those Construct programs, haven't the developers of their games left Construct while Ashley moved onto the next iteration?

    At least with the transition from Classic to 2 we were getting a new engine and language. From 2 to 3 we're getting a new editor.

    When the transition from 3 to 4 comes what are we going to get then? An improved toolbar?

    I don't know C1 that well, but I heard it had a lots of crashes and a bad exporters and that was why the development stopped (correct me if I'm wrong).

    And I'm afraid of C2 happening the same...

  • You should not blame beta releases, because that's what they are "beta releases". It's quite normal for them to have bugs.

    As of the rest... I really do not care anymore, after all posts I made and read

    I'm just glad I'm working on a project that don't need high or steady fps to work, but current wrappers situation (that lasts 3 or 4 months already!) is just a big lol.

    Q3D is nice and all, but it's just too damn confusing. I bought it, tried to understand it for whole week and then I gave up. Now if I need some 3d for desktops I'm happily using UE4, where things do work like I want them to work and always at 60 steady frames per second for me and others. So yeah C2 is currently my tool for making small, stupid and slow mobile and web games.

  • I think what is happening to Construct 2 is basically what happened to Construct Classic. It's buggy, unfinished but Ashley has moved on to Construct 3, leaving behind an unfinished product with which only a handful of developers, if even that, made a succeeded game with.

    There's a lovely thread but kind find it now, about Node Webkit working "fine". There's a lot of nice posts in there about C2, exporters, and almost very same thing like in this thread. As far as I can remember, the ultimate answer to everything was something like "it's just a bug, they will fix it (chromium team) eventually". And guess what? They did. They fixed it. Everything was perfect.... for two or maybe three months

  • To be fair, construct 2 works really well in browsers. The major complaints i see are with people using construct 2 for mobile games, a place they will not excel because of hardware constraints that make even java-script itself perform poorly. If you want to make a game for mobile with javascript you absolutely have to scale back and be very frugal with the resources you use.

    Mobile games aren't complicated, and that's because you really need to develop them from the ground up to get any kind of good performance. Making a complicated mobile game in C2 is easy, however it wont work because it's too complicated. The more difficult an engine is to work with, usually the better the performance you can squeeze out of it but the slower your development will be, ESPECIALLY if you are inexperienced.

    You could very easily code a fast HTML5 game for mobile, however you wont have the wonderful abilities like picking which construct allows you to use, you'd have to build the game in an optimized manner. If your game is GPU bottlenecked, then that's going to be a problem no matter what. There's a lot of inexperienced developers using C2 (which is understandable) and they end up complaining that their game is working poorly because it works on desktop "just fine" but dies on a mobile platform. The only answer that can be given is that their game is trying to do too much, regardless of if it's doing "a lot less" than other games they've seen on the platform.

    As an example, anyone familiar with demoscenes will understand that some people can squeeze a ton out of very little. Take for example classic c64 games and their graphics, and compare them to some of the more impressive demos for c64:

    demos:

    Subscribe to Construct videos now

    vs.

    games:

    Subscribe to Construct videos now

    A lot of low level optimizations that have to do with using smart memory structures and reusing data in an intelligent way mean you can get "way more" out of something. This is what mobile developers manage, even if they're using html5+javascript from the ground up, vs construct. Construct 2 will allow you to very easily trim down recursively through lists of objects with picking conditions / actions, however the fact this is used everywhere to make events "easy to use" means the performance suffers, ESPECIALLY on weaker platforms where performance is constrained. Things like "creating" and "destroying" in construct are very high level and generally expensive even with the recycling systems in place. They're general so that when something is gone it's gone and everything knows it's gone, however this is expensive compared to just pretending something is gone and controlling at a low level. In most cases a game with limited actors could much more efficiently be constructed by having a short array of references and never having to really pick anything.

    To top things off, most people abuse the hell out of collision detection in construct since they have a poor understanding of the costs associated with it and the mechanisms behind it's operation. It's very easy to blindly apply collision detection throughout code for repeated conditions, but really most engines have a SINGLE collision detection run per frame because it's so expensive, when in construct you can end up with many many many collision detections per frame, which make things "tighter" at tremendous cost. Behaviors are also a big issue because of how general they are, the expense they incur quickly adds up.

    If you want great performance, you need a powerful platform, or you need to fine tune your game from the ground up, there's no magic bullet and complaints are misdirected for the most part.

    shinkan

    Q3D is confusing because of the limited editor SDK of C2, so if people want powerful plugins with good editor integration, im afraid supporting C3 development is the only way they can do it... Regardless Q3D is constantly improving, and hopefully i'll have time to get some documentation out after the next update which finalizes a lot. I can guarantee using Q3D is way easier than trying to make a 3D WebGL game directly, and it works quite well at achieving that goal. In any case UE4 and Q3D have entirely different purposes, UE4 doesn't really work in browsers, regardless of what their poor HTML5 emscripten demos that barely work try to prove, they really aren't trying to make an engine for WebGL.

  • Q3D is confusing because of the limited editor SDK of C2, so if people want powerful plugins with good editor integration, im afraid supporting C3 development is the only way they can do it... Regardless Q3D is constantly improving, and hopefully i'll have time to get some documentation out after the next update which finalizes a lot. I can guarantee using Q3D is way easier than trying to make a 3D WebGL game directly, and it works quite well at achieving that goal.

    I'm all aware of that my friend. You have put tremendous amount of work to make this plugin happen and it is really great and powerful . But unfortunately, currently C2 is not making it any easier to use. I never found your plugin hard to use - speaking about event logic. But rather what confuses me a lot is C2 editor itself, placing 3d object in 2d inverted space is not fun for me at all. That's why I stopped using it, not because it's bad but because it takes too much time from me to set things right. That's why for time being I choose UE4 to do 3d stuff only cause i can do what I want faster and in full 3d space. I know I could build myself a nice 3d editor in C2 and use it to for my needs, but that's not the point here. I really hope I could use Q3D in a nice environment

    "Mobile games aren't complicated, and that's because you really need to develop them from the ground up to get any kind of good performance."

    And that is true as well, people tends to forget about that. But again current crosswalk do not help making even that easier, while having problems with almost empty projects

  • 3D is by its very nature just confusing in General and building a Realtime Engine that will satisfy People is a whole different story as well so don't just think it's that easily done. I think a new Editor with a better SDK may lead to better Exporters being developed but i'm technically not clever enough to really say this... But one things for sure: a dedicated 3D Engine like Unity with something like Playmaker might be the better Solution. I went to school for 3D Animation and i can tell you that the workload is quite a different story especially for one-man shows so i think Construct should stick to what its best at which is 2D.

    If someone really is unhappy with how things develop though maybe they should look at other Options out there?

  • 3D is not confusing. All you need to do, is to know what you want to do and how you want to do it. It's simple as that.

  • Okay let me rephrase: compared to 2D it adds a lot of complexity, agreed?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Yup, Now i can agree to that statement

  • Is geometry confusing?

    A little.

    Is trig confusing?

    Fkia@$k yes.

  • To top things off, most people abuse the hell out of collision detection in construct since they have a poor understanding of the costs associated with it and the mechanisms behind it's operation. It's very easy to blindly apply collision detection throughout code for repeated conditions, but really most engines have a SINGLE collision detection run per frame because it's so expensive, when in construct you can end up with many many many collision detections per frame, which make things "tighter" at tremendous cost. Behaviors are also a big issue because of how general they are, the expense they incur quickly adds up.

    .

    As far as I remember, C2 compiles those in to one list on export/preview.

  • megatronx

    No, it doesn't. That would break the logic in a lot of way if for example you move an object between checks etc.

  • Even the people that Ashley posted on his front page to showcase Construct 2's "capability" have said themselves they will not be using Construct 2 in the future for any more projects and that they are losing money because Construct 2 is incomplete.

    (...)

    I find it very ironic that on the Construct 3 page, there's one of the three developers that swore off Construct 2.

    Hi, I'm the guy on the C3 website : )

    Just to be clear on this subject, cause it's not that simple in my head.

    - Yes, I won't use C2 anymore for future big projects. Mainly because of the lack of (real) console exporters (< many devs really need this to make money now)

    • BUT I will continue to use C2 (and C3) to make PC only projects, smaller games, or prototyping. I've never been so in love with an engine from a workflow point of view.

    I know how to use GM (Penelope started as a GM project for 4 months), and I'm having fun with Playmaker and UE4 blueprints from time to time.

    It's great, but I miss C2 pretty quickly every time.

    - No I don't feel like C2 is a scam or something. I came here 2 years ago to ask "can I make this game for PC using C2?" and now my game is out and runs great using NW 10.5.

    Job done, as far as I'm concerned! Hell, the game even now has a boxed version! ( https://twitter.com/AurelRegard/status/ ... 8071988225 )

    Yes, as many I had issues to fix with this, but devs using Unity for consoles sometimes waited more than a YEAR to be able to export their games in a proper way. I know there is no magic tool to export games for multiple platforms.

    Making it to run on Linux and Mac is tricky, but again friends using Unity, GM or their own engine have similar issues, so I'm not complaining this much.

    [Every X days - Trigger Once while true] > - At the end of the day, I know I wish for something which can't happen (a +50 people team with a shitload of money to back them for native + console exporters). So now, I take C2 for what it is: a fantastic piece of software which allows to craft complex games at the speed of light on PC and Mac. And sometimes Linux. And small games / prototypes for browsers and mobiles.

    I have no regret, and I still LOVE C2.

    This is why I'm happy to be on the C3 website (note: I don't have any partnership with Scirra of any kind). I'm sure the UI and the logic will be as brilliant, maybe better than today. And I'll use it for sure for (yes, only a small part of) my next projects. I also deeply respect how Ashley takes time to answer here to mostly every thread where he's targeted.

    Since a few months, I have to answer 100/150 messages a day by email/twitter/steam forums. This is exhausting and life-sucking, I can't imagine how hard it is for him to do this for this long, and I understand he just can't profile every game on earth / fix all bugs with only 24 hours in a day. Aaaand, then back to [Every X days - Trigger Once while true] > cause at the same time I feel so frustrated to see such a great tool only based on html5 and only on a one man army.

  • Thanks for your response Aurel, couldn't agree more.

Jump to:
Active Users
There are 2 visitors browsing this topic (0 users and 2 guests)