My 3¢ about c2 and c3

Discussion and feedback on Construct 2

Post » Mon Sep 28, 2015 3:25 pm

@megatronx
Hehe, you live and you learn, that's how it goes!

I keep trying and testing to get features to work exactly as I want, even if its unorthodox or "hackish".. I only care about the end result. :D
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,614

Post » Mon Sep 28, 2015 4:04 pm

Silverforce wrote:I know the engine already does this per layout, but the option to do it manually for a sprite that we want when we want it is what allows more flexibility. Sure, people can mess up if they don't know how to use it, but that's a poor excuse to not have that level of control at all.

Completely agree with this. Its no different in my opinion than people can screw up loops, that doesn't mean that loops should be removed as well. Almost everything can be screwed up if done wrong, but what matters is the ability to be able to do something when its actually needed and to use it where it doesn't hurt performance, which should be a decision made by the person designing the game and not those making the software, because sure in some cases it would be a bad idea, but that doesn't justify that then its bad in every single case and therefore shouldn't be an option.
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,838

Post » Mon Sep 28, 2015 4:17 pm

shinkan wrote:Everytime when I see post like that instantly I'm seeing UE4 blueprints in my head. There is really no point to compare epic to scirra (hundreds of hands vs only few couples) but they have nice system with object blueprints and level blueprints working together.
So maybe this is a thing worth do some tests. Not only to make events more clear - you could have object events on objects only and everything else on level events, but maybe level events could work on 1 cpu and objects on another etc.
And on the other side this kind of system have more sense, at least from my point of view. Even for beginners who tends to make one huge and messy event sheet with everything on it. "Double click on sprite to add some logic to it" feels more natural and most engines are using similar approach. You don't make just one text file full of code for entire game to compile.

But I'm just a user, so I'm just saying what I see xD


Maybe that makes sense, given that Blueprints also evolved like that. The Kismet predecessor only had global level scripts, then the system was extended to be (optionally) object oriented with Blueprint.

Maybe it wouldn't need anything complex even to make this useful. Simply being able to assign event sheets to objects could be helpful already, with no major difference other than defaulting to "pick all instances of this object" for all events in such a sheet. Allow sheets to be assigned to more than one object and you even have reusable sheets that work on different object types, which would not be far off from adding behaviours. Perhaps also add an abstract object type to hold data and/or events only, so Sprite doesn't have to be abused for this.

Another thing I'd like to see is an evolution of the Function object, perhaps by creating a function behaviour that can be assigned to objects to create "member" functions. So we could do something like MyObject.Function.Call("MyFunction"), which triggers MyObject.Function.OnFunction.

The only issue with that (and Function in general IMO) is that the syntax is really cumbersome, so why not make Function a first class feature of the editor, with its methods exposed by each object? Then you could just write Call("MyFunction") or MyObject.Call("MyFunction") instead of Function.Call("MyFunction") and MyObject.Function.Call("MyFunction") respectively.

I don't believe those changes would make the editor significantly more complex if you don't need those features, but provide a pretty significant quality of life improvement for more complex development.
B
4
S
1
Posts: 7
Reputation: 324

Post » Mon Sep 28, 2015 4:42 pm

One of primary goals of my post, was to add features and plugins that would do what we all do when making our games - stuff that is pretty much always made same way, to save us time and hustle, simultaneously expanding plugins with new functionality, while taking care of fixing glitches of the software and it's plugins. And only after those basics are fulfilled I think the talk about multi threading and other hardware related features could be included.
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
89
S
30
G
22
Posts: 1,985
Reputation: 20,099

Post » Mon Sep 28, 2015 4:43 pm

@eli0s
#4: check
viewtopic.php?f=146&t=161617

Anyway...
If C3 does not have a way to make plugs via events we really need to shim up the javascript side of plug creation.
There's little info for beginners to go on.
There should be forums dedicated to scripting, examples, object types, behaviors.
We have an sdk that's absolutely cryptic to a novice.
Image ImageImage
B
169
S
50
G
170
Posts: 8,291
Reputation: 108,726

Post » Mon Sep 28, 2015 5:02 pm

This contains some gem ideas. My 3 cents:

Add a tween behaviour. I know there's a couple of 3rd party plugins, but I mean something a bit more substantial... One you could incorporate into a sprite/variable animator (like the one in Godot engine or a better version of the animator in Unity). Imagine an animation behaviour where you could easily animate anything, with tweening. Because that's what I want to use and have to create every time I want to do something in c2, even if it's just to animate a button effect or a layer opacity.

Oh, and give us access to full box2d because the demo physics plugin is OK for creating a quick game demo but, strewth, it's frustratingly limited.

And what @newt just posted too. I would love to create my own plugins but if I'm going to bother to learn to write code then that defeats the point of using a no-code engine. Just imagine a Blueprints style of plugin creator... Mmmmm.
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,212
Reputation: 43,846

Post » Mon Sep 28, 2015 5:22 pm

@Colludium I think what it needs is like what @eli0s said

6) An animation timeline to create key-framed animations that can be triggered with actions!!!

If that could be a little curve editor with key frames, beziers etc, then it will sort out every animating property needs: position, rotation, opacity, scale.....
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,599
Reputation: 34,825

Post » Mon Sep 28, 2015 5:32 pm

@shinkan - yes! An animator with curve adjustment. That's exactly what Godot uses: everything can be animated by simply using it in the editor.... I support @eli0s ' suggestion!
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,212
Reputation: 43,846

Post » Mon Sep 28, 2015 5:47 pm

I'm totally up for making plugins with events, animator editor with curves and tweens, but also for expanding vanilla plugins with more functions and fixing its current existing issues and limitations.
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
89
S
30
G
22
Posts: 1,985
Reputation: 20,099

Post » Mon Sep 28, 2015 6:06 pm

@megatronx exactly, Like I wrote in some post in the past, plugins and behaviors should be all compatible with each other, should do what you expect them to do and every single parameter of the plug/beh should be visible in ACE to be set or modified.

Solid is probably the best example here. You would expect that it will block every other solids no matter what, unfortunately Solid only works with selected and very specific other behaviors. It should be the other way, if I set Sprite to be Solid then it is solid for everything - drag and drop, bullet, 8dir etc.
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,599
Reputation: 34,825

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: goodboy69, The Mnk and 21 guests