will construct3 be as strong as unity??

  • > uScript is a nice VPL component linking software of apis. however you will end up needing code yourself for features that don't exist. I would suggest PlayMaker which is meant to be more a programming replacement.

    >

    > So UScript is about linking api's

    > Playmaker is similar to EventSheet programming( in a an abstract purpose sense)

    >

    playmaker is good but uscript is more like c2 event sheet and more powerfull and no need for coding at all !

    it even use reflection to get all unity things ! (functions,properties,...)

    and you can make new features with graphs and use all of that as one graph !

    c2 have little programing like expressions but uscript is just graphs

    Well I haven't used uScript for about 2 years. last I used it. uScript relied Reflection of existing code, and couldn't do much with out . So if you needed specific movement, you still needed to code that motion.

  • When you see the price tag on Unity you know why it has more features, bells and whistles.

    And while Construct 3 will not have the same features as Unity, Unity will be much harder to learn.

    As a programmer which creates mostly administrational software, I was (and still am) very surprised about Construct 2 ways of doing things. I just tried out the trial version to see if it would run on this old laptop. When I found out it does, I just bought a personal C2 license and start developing educational games to help our 6 year old daughter with her homework and school.

    Construct2 is a very good game engine for 2D for which it is intended. Scirra is a small company and as such, they already created a very good game engine. They already expanded their team, so in the coming years we will receive improvements and features we now only can dream of.

    A very satisfied and happy Scirra game creator.

  • megatronx I'm insanely glad I'm not the only one to notice that

    Cool. I noticed that from the start too, and I hope more people see that.

  • megatronx , Jayjay , perhaps because they use different technologies? Cc uses directX9 and C2 HTML5.

  • Isn't that down to the performance of out of control 3rd party wrappers (well, Chrome...)?

  • I have uscript and dont understand why you think it is similar to construct's event sheet

    They are nothing alike. Uscript is a node based approach, c2 is an even sheet approach

  • megatronx , Jayjay , perhaps because they use different technologies? Cc uses directX9 and C2 HTML5.

    Well, webGL trough html5 canvas, and that should work just as smooth.

  • I have uscript and dont understand why you think it is similar to construct's event sheet

    They are nothing alike. Uscript is a node based approach, c2 is an even sheet approach

    I watched a few videos of a Uscript tutorial. While it may not have the event sheets, it did look familiar to me. I saw actions, conditions, variables, animations, so on. The "node" approach is a little different, but I picked up on it pretty fast from my time with C2.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • > megatronx , Jayjay , perhaps because they use different technologies? Cc uses directX9 and C2 HTML5.

    >

    Well, webGL trough html5 canvas, and that should work just as smooth.

    But it isn't, evidently, as you already mention. HTML5 games just doesn't cut it (yet?) when it comes to a "smooth" experience, native exporters feel more "snappy" and responsive.

  • But it isn't, evidently, as you already mention. HTML5 games just doesn't cut it (yet?) when it comes to a "smooth" experience, native exporters feel more "snappy" and responsive.

    Only for a few of the broken Chromium versions. NW 10.5 is very smooth and snappy.

    Did you guys hear about 2K Games's Bioshock on iOS? It was removed. The recent iOS update broke the game. O_o

    So it's not just us little guys that get screwed over for problems created by Apple or Google.

  • I would say the editor overhaul is much, much needed.

    Also, not being native is not the only issue, some things in C2 are just not good enough (keep in mind that a game can have some crappy optimised parts and still run perfectly, a game engine not so much, as each quirk will be present in every single game and if someone is to rely on them well..):

    -AFAIK, the collision system is not perfect, ok, they used collision cells to make it "useable in larger worlds" but this is still a potential issue and bottleneck (I know, is overllaping is faster, but it is still not as good as it could be)

    -events runs on a single core, and other parts of the engine do, I know it might not be a big deal but I think some progress could be done regarding that (as I think big limitations can be implied with a multicore system)

    -the physic engine is simply not as complete as it could have been as far as I could gather, also, it is totally framerate dependant by default, try on a 120Hz monitor and the simulation will be twice as fast, I understand the logic behind that though (this may be the only case where locking the framerate to a value is a valid choice)

    -something doesn't work? Welp, too bad that thing could potentially break projects, won't fix

    -Users would rather rely on using events directly rather than using the plugins, if we are to reinvent the wheel, might as well go with another engine

    -third party plugins and official plugins are not treated equal, third party plugins are updated by hand, official plugins updates are tied with the engine (a quick analogy with IE updates being tied with windows updates in the past is enough to show how bad it is), also, needing to update third party plugins by hand rather than having basically a way to open C2, check a plugin store list, see which one can be updated and the changelog that goes with it (official ones too) would make using third party plugins a breeze I think (and believe me, some third party plugins are nice).

    More related to the exporters now:

    -well, this one is a big one : limitations are not consistent, they simply aren't, two differents hardware can work the opposite way we would expect them to, just by virtue of blacklisting, we can turn blacklisting off ? Hurray, but then the device simply does not support webgl and just displays a black screen, what then (my netbook will not support webgl, ok it is outdated but still, if your plan it to make simple games, it will even fail in that regard)? Or if the blacklist fails (AFAiK, I cannot turn webgl back on chrome on my galaxy tab 3, not that chrome was a good android browser experience anyway for me, but still that is a problem)

    -kinda related to the first one, games are not future proof, they are not dependant on browser features only, if one browser decides than it is over for platform X, then it is over for it, end of the line (I know nw.js and the likes can be a partial solution to that, but let's be honest a second, why people wanting to make a browser game exclusively would want their users to download an executable, it is even worse than downloading a plugin).

    We will always rely on third parties, yes

    We will probably won't benefit from having native exporters due to the amount of time needed to polish it, probably

    We can rely on browser vendors to keep things working in the long run C2 wise, absolutely not, They simply don't care enough for that, I would not be surprised to hear that chromium guys are only testing the most games related features on chromebooks, also mobile web browsers have issues that simply breaks games (the slow decoding chrome issue alone can render your game a painfull experience on mobile, we also had the time when a beta webaudio api was used in C2, and broken by chrome to the point it was unplayable), that doesn't mean we cannot do anything great inside a webbrowser (..well from an economic standpoint there is currently no point in doing that but I am staying in the non commercial kind of things) but we need to be sure they won't screw us with one change, or to be able to face it without issues.

    As for unity, for a native experience it is good, but from a webbrowser one I would be curious to see if it is worth it (not with the web player plugin obviously)

  • If C3 is multi-threaded... awww yeah, one can wish!

  • I really want to believe that C3 will be something more than just C2 editor update. I don't mind it being still just the web games maker (+3rd party exporters) but everything else could use a nice update.

  • Why do events only run on one core?

    Think its a good explanation, even though its never really been an issue for me personally at least. But none the less you write this under the sequential logic section:

    [quote:3mo2a70m]Running part of that workload on a different core doesn't help at all, since the tasks must still be done in order, one after the other - the same as on a single core.

    Construct 2's event sheets run in top-to-bottom order, conditions are evaluated top-to-bottom, and actions are run top-to-bottom. Anything an event refers to could have been changed by previous events

    Which of course is true. But was wondering when you add an event like "-> On object destroyed" these are triggered even though they might not be the next event or even on the same event sheet. So at some point these are executed before the next line of code right? Even though the object is not actually destroyed before the next tick. Can you elaborate on that, meaning does C2 jump to this event and destroy it, keep the object in memory, until next tick and then continue from where it were destroyed, or does it strictly follow the top-down order here as well?

    Anyway just wondering.

    EDIT:

    Nevermind that, since you are not referring to triggers, cheers

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