C3 Architect Request list

Discussion and feedback on Construct 2

Post » Thu Feb 05, 2015 1:19 am

I'm not against a native exporter, but I know Scirra won't do so. I know why too. Browsers do more than just execute JS. Browsers have huge amounts of features to take advantage of. For C2/C3 to support native would require breaking all those Browser features and linking to an abstraction layer.

Is it impossible. No, but it's not going to happen as a two man team. If C3 proves so successful that Scirra expands to 100+ staff. Who knows.

megatronix
I'm hoping that SceneGraph based Object is added as a new core object. Pin would then be obsolete, though thep lugin would exist to be backwards compatible.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Fri Feb 06, 2015 12:08 am

That is why I suggested basic4android for native support, it is maintaned by a single person, who is done wonders, showing that much can be done if someone know what to do and how, Xamarin with all that people programming still has 5mb Hello world app on Android.

But, don't want to turn this thread in pro/contra about native support, I was wondering if we could get animation system like in Unity, at least triggers, and some simplified states, morphing frames would probably be too much, but one can hope.

Also some tighter integration of sounds and objects, so we can assign sounds to objects or, now when I think about that, maybe easier solution would be to link specialized sheets to objects, not just for sound, but animation management, instance functions (not just varibles) as well, thus mimicking classes which I think is already suggested somewhere.
B
58
S
9
Posts: 22
Reputation: 3,953

Post » Fri Feb 06, 2015 2:37 am

Agreed. This is not a pro/con for native support.

You did remind me that I would like Object EventSheets, but outside of better organizational programming. I have been unable to convince Ashley as of yet. but I'm going to put it in :). However if Ashley supports the idea of a SceneGraph root object, then I'm not sure if Objective programming will be needed as much. Because every world object would be just the same object anyways.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Fri Feb 06, 2015 12:09 pm

SceneGraph concept looks nice as I understand it, it would be something similar to Unity approach to GameObject.

But it doesn't necessarily exclude Object EventSheets. With Object EventSheets it is easier to implement multi language/resolution/graphics support, you just include/exclude Sheets. Right now only way to change Sprite image is through code. My way of dealing with this problem right now is Groups, not very nice after some time, especially since it is reference by name which I addressed before.

If we are to get some resource management like in Android projects then multi language support won't be a problem, but EventSheets looks easier to implement with backward compatibility in mind. Even if you implement some property based support for graphics, resolutions, sounds... there are always some things that you need to do manually. Also possible include/exclude feature on export or loading level would also be nice for optimization.

Mentioning Unity reminded me that Sprite at least should be some kind of a generic GameObject with extensive material(texture) property.

What I hope Ashley has in mind is when to totally disregard our suggestions if that complicate usage to novice user :)
B
58
S
9
Posts: 22
Reputation: 3,953

Post » Fri Feb 06, 2015 3:28 pm

People, keep in mind that this thread is for architectural features in C3.
I'm going to give a list of suggestions that ARE NOT APPROPRIATE for this thread:
  • Path Movement (I'm not talking about pathfinding, but a simple "follow the nodes" movement): If we can have plugins and behaviors drawing on the canvas, this will already be possible with the SDK, so this is a shitty suggestion for this thread, even if it is immensely useful for development. Same goes for bezier curves, for instance.
  • Instead of asking for pin behavior should take size into account, why not ask for expressions during edittime? this way we could set the X position of an object to something like "parent.X*parent.size+self.variable", turning the pin behavior almost obsolete (don't take the pin behavior out, though, beginners can still use it before they wrap their heads around variables)
  • AI Editor or similar. Ask instead for "plugins should be able to define and spawn their own editing windows, just like the sprite animation editor", this way we'd be able to create finite state machines, 3D map editors and all sorts of things
  • Instead of asking for multiple collision masks, why not ask for collision masks to be decoupled from the animation? This way different objects can share the same collision mask. Even better, why not ask for "collision mask" to be something you can store in a variable? Heck, it doesn't even have to be a "collision mask", it can be just a "mask", that we can crop, apply effects to, etc. Also who said masks have to be edited? Maybe I can just choose on a list from a few presets, such as a circular mask, or a square mask, or an editable mask. Maybe I can have a little "mask editor" where I can do operations such as "fit inner" or "fit outer"

There's no point asking for features piecemeal, it's about asking for architectural changes that will enable us to create the most things using the least stuff. It's about making the engine versatile instead of a bag full of special cases (i.e. the tilemap and spriter extensions)

Also, for people talking about exporters, this is crazy talk. Don't ask for "native XYZ exporter", ask instead for "an exporter SDK"! I may or may not agree with you, but at least it's an architecture request.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Fri Feb 06, 2015 3:38 pm

My first experience with SceneGraph was back in my early days of Java over a decade ago. A fiend of mine want to make a simple 2d game engine. I elected I wanted to work in a parent child model of effect. So I wrote it up. It was only later that I realized that there was this thing called SceneGraph. I then learned more about Affine transforms from Java3D, but I do admit I use them a lot in Unity these days. All of this while Unity was in it's infancy stages. Heck I remember the early days of Unity when it was just an API :D before it ever had the IDE.

I still think it might be moot. If Modular CAPX are support, and Modular Behaviors. Then developers can write entire Object Modules. Which then would be ES objective programming. Especially if its more behavior than the current world object. So you create a ESGroup that exports as a Behavior. Since Behaviors effect the PluginObject you then have Object Orientated ES Programming.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Fri Feb 06, 2015 3:51 pm

@Fimbul
Actaully interesting enough. Pathmovement by Node was the big turning point for my understanding of C2. There is an SDK thread with about widget drawing. When I found out C2 couldn't handle this and this leading that modularity is locked due to C2 IDE. eh. That was understanding the C2 growth was going to hit it's limit. So my NodePath(in the store) could not be effectively made in C2 as any kind of Plugin :( So widget drawing and manipulation in in the list.

With custom windows(in list). Then AI state machines can be made. Then all it comes down to is being able to store custom data objects into an objects(behavior/Plugin) property list. Which is also in the list. If those are supported then AI visual state machines can be made.

It's in the request that Collision can be placed as a behaviors. In fact there is a request that while C2 is supported, that there can be a modular Behavior based design path. Where there is only a Basic WorldObject(just xyz,scale, angle) and everything stacks on as a Behavior. So collision is a behavior, Sprite is a behavior etc.

So right now. The list would support all your posted ideas. Though it does come down to. how flexible the current system is, how much needs to be redone, and what Ashley's values of the suggestions.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Fri Feb 06, 2015 4:53 pm

I also think each one of us should write down what is annoying bout current IDE workflow.
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
85
S
27
G
21
Posts: 1,969
Reputation: 19,167

Post » Fri Feb 06, 2015 5:06 pm

jayderyu wrote:So right now. The list would support all your posted ideas. Though it does come down to. how flexible the current system is, how much needs to be redone, and what Ashley's values of the suggestions.

Oh, I know, I just wanted to make it clear for everyone that this is not a place to request trivial things. As it stands, people will eventually jump in this thread asking for things that can already be implemented (i.e. "there should be a plugin for adbizz" or "make a physics plugin using PunyPhysixz"), or features that are too niche and would be better expanded as an architectural change (i.e. "make a plugin for damage types" - this could be made much easier if we had a better way to fold away or abstract object variables, or using your "generic object" idea).

Some (imho bad) ideas already requested:
  • Make the editor skinnable (a.k.a. "make a dark theme") sounds like a nice idea, until you realize you can just say make the editor support CSS and get something much more versatile, while still getting everything you want
  • Support for multilanguage also sounds nice, but you can instead ask for make the editor support third-party javascript libraries and get access to tons and tons of free, open-source translating libraries already available as well as other nifty stuff for drawing, maths and lots of other things
  • we need a menu editor is desperately needed, but nowhere near as flexible as make the runtime support sub-layouts

Some grandiose ideas are better here (some great ones already in this thread and the document!), such as increased versatility for the layout editor , allowing you to customize it in such a way that in addition to supporting top-down and sidescrolling views (which is what we have currently) it will also be able to handle isometric, 2.5D and 3D. This should be done preferentially via plugins or config options, avoiding hardcoding as much as possible.

I also think each one of us should write down what is annoying bout current IDE workflow.

Want to start another topic? I'd post there.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Fri Feb 06, 2015 5:27 pm

@Fimbul

I understand your opinion but as a designer I disagree with it. If you suggest make the editor support CSS instead of make the editor skinnable your not giving the real problem to Ashley solve, your are giving only one limiting solution. The end user needs a skinnable editor, if it's better to do it through CSS or other method is up to Ashley to decide based on all the other decisions he will need to do for the engine. If in the design path chosen by Ashley CSS ends up not being an option, then by your suggestion we will not have a skinnable editor, even though maybe there's other ways it could be implemented inside those restrictions.

So in my view there's no harm in asking requests that are not strictly architectural. Ashley can analyze what's needed to make that particular feature feasible and decide what is needed to change in the Construct architecture to make it happen. If Ashley is willing to make architectural changes...
Scirra Employee
B
149
S
53
G
17
Posts: 711
Reputation: 17,725

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: SubtleCoder and 7 guests