will construct3 be as strong as unity??

Discussion and feedback on Construct 2

Post » Thu Sep 24, 2015 8:53 pm

I have uscript and dont understand why you think it is similar to construct's event sheet :D
They are nothing alike. Uscript is a node based approach, c2 is an even sheet approach
B
40
S
15
G
4
Posts: 426
Reputation: 5,848

Post » Thu Sep 24, 2015 10:15 pm

eli0s wrote:@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.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
92
S
30
G
22
Posts: 1,987
Reputation: 20,178

Post » Thu Sep 24, 2015 11:31 pm

blurymind wrote:I have uscript and dont understand why you think it is similar to construct's event sheet :D
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.
B
81
S
30
G
35
Posts: 340
Reputation: 23,046

Post » Fri Sep 25, 2015 12:05 am

megatronx wrote:
eli0s wrote:@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.
composer - multimedia artist
www.eli0s.com/en/
B
69
S
27
G
6
Posts: 1,146
Reputation: 10,379

Post » Fri Sep 25, 2015 6:54 am

eli0s wrote: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.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Fri Sep 25, 2015 8:24 am

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)
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Fri Sep 25, 2015 8:43 am

If C3 is multi-threaded... awww yeah, one can wish!
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Fri Sep 25, 2015 9:49 am

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.
ImageImageImageImage
B
158
S
66
G
43
Posts: 2,603
Reputation: 35,868

Post » Fri Sep 25, 2015 11:09 am

Scirra Founder
B
399
S
236
G
89
Posts: 24,543
Reputation: 195,430

Post » Fri Sep 25, 2015 11:26 am


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:
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 :D
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,848

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 2 guests