C3 Architect Request list

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 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.

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.

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

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.

[quote:hxkchvw4]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.

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...

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...

Hm. Yeah you're absolutely right, requesting "CSS support" is no different than asking for "C# exporters", it's focusing too much on the means instead of the ends. Ashley should be the one dictating the technologies. 100% agreed.

I think megatronx gave a good idea in that sense, just start a topic where users can vent about their current frustrations with the current IDE and other users could propose solutions to them.

But you can see what I'm trying to say here, right? Just don't allow C3 to become a bag full of special cases, exceptions and niche features (C2 is becoming more and more like that recently)

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...

Customizable editors should remain further down the priority list from good UI and UX.

Customizable editors should remain further down the priority list from good UI and UX.

I agree. In my opinion having three predefined options for light, medium lightness, and dark UI is all that's necessary. I was just using the customization as an example to my point.

But you can see what I'm trying to say here, right? Just don't allow C3 to become a bag full of special cases, exceptions and niche features (C2 is becoming more and more like that recently)

I understand, I share the same opinion about Construct being more versatile. I just don't see C2 as having too much niche features, it's in a good balance with easiness of use for me. And I don't think Ashley is particularly fond of the idea of making "a bag full of special cases" either.

C2 core object is fill with LOTS of different stuff and special cases.

This is the minimal memory instance of a World Object. no graphics, plugins, no positional, no ace elements of anything. And it still has LOTS of stuff that has no meaning most of the time. If I make a Node, apparently I have stubs for a TileMap.

property: type

property: runtime

property: recycled

property: uid

property: puid

property: iid

property: get_iid

property: toString

property: extra

property: instance_var_names

property: instance_vars

property: x

property: y

property: z

property: width

property: height

property: depth

property: angle

property: opacity

property: hotspotX

property: hotspotY

property: blend_mode

property: compositeOp

property: srcBlend

property: destBlend

property: effect_params

property: active_effect_types

property: active_effect_flags

property: bbox

property: collcells

property: rendercells

property: bquad

property: bbox_changed_callbacks

property: set_bbox_changed

property: add_bbox_changed_callback

property: contains_pt

property: update_bbox

property: update_render_cell

property: update_collision_cell

property: get_zindex

property: tilemap_exists

property: tilemap_width

property: tilemap_height

property: tilemap_data

property: updateActiveEffects

property: uses_shaders

property: bbox_changed

property: cell_changed

property: visible

property: my_timescale

property: layer

property: zindex < Hey zIndes.. why depth?

property: collision_poly

property: collisionsEnabled

property: behavior_insts

property: properties

property: is_contained

property: siblings

property: onCreate

property: onDestroy

property: saveToJSON

property: loadFromJSON

property: draw

property: drawGL

property: getDebuggerValues

property: onDebugValueEdited

My opinion is that a WorldObject should be something like this

property: type

property: recycled

property: uid

property: puid

property: iid

property: get_iid

property: parent

property: children

property: x

property: y

property: z

property: worldX

property: worldY

property: worldZ

property: angle

property: worldAngle

property: scaleX

property: scaleY

property: scaleZ

property: worldScaleX

property: worldScaleY

property: worldScaleZ

property: hotspotX

property: hotspotY

property: behavior_insts

property: onCreate

property: onDestroy

property: saveToJSON

property: loadFromJSON

property: draw

property: drawGL

property: getDebuggerValues

property: onDebugValueEdited

property: toString

Everything else is a behaviour. thus only adding as needed.

I would like to put using and managing sprite sheets for preview just like exported projects and better sprite sheet management here.

More info:

Commenting so I can read later...

We really need c3?? c2 s great already

Effects:

• Toggle on/off inside the editor ( might have had already mention that )
• [Radical] Effect Scale Slider: This slider would be used to increase or decrees all effect values in direct proportions and at the same time.

Layout Ed:

• Jump between layers using combination of two buttons like alt+tab tab viewer in windows. Other layouts will be dimmed out and locked for ease of editing current layer.
• Ability to tag selected areas in the layout in order to quickly scroll to those by selecting its tag from the tag viewer. Option to toggle on/off visibility of the tag name in the layout. It would make working on bigger layouts much easier.

Navigation:

• Layouts Viewer: A place where I can scroll trough all layouts with their snapshots. Single screen snapshot will be fine. After hours of work it is easier to remember "the look" of the layout then it's name.

General:

• Export/Import layout with option to choose weather to only export code or together with objects, nicely packed in to rar or zip. When importing layout without objects, or if an object for some reason is missing, nicely ask the following "brows for object? / would you like to create this object?"
• Debug layer Preview: let program automatically create a debug layer as a top layer, so we can view and edit it and then turn it off, without need to switch between Debug preview and normal preview.

So far all id like to suggest is naming it Construct 2 PRO and not C3. Feels more right in my opinion

A lot of great suggestions.

However the only one i want to bring up again is:

- Disable Solid between selected objects only

Normal Solids:

Improved collision system so we can ignore/disable ~ collision/solids depending on picked objects.

NOT GLOBAL ONLY as it is right now. Please let us finally pick with C3 so specific objects collide while at the same time others go through!

Please keep that in mind in case you're touching anything related to it.

Online collaborative editing of your game in real-time like heroengine, run arround in your gameworld with friends sticking "post-its" on everything that needs some work ...ahhh it was so mutch fun to work with

I was working with such a feature using a MAP Editor.

It was kinda awesome to work simultaneously with multiple developers on the same map.

The development progress was way faster, and you were able to work truly together as all changes were live to look at.

Would have been a great feature, but never going to make it into C3

------------------------------------------

About all the "skinnable" which i was reading about through tons of topics over the past few months...

Really?

Is it so important for you to have a colored/darker or black background?

90% of all softwares have got a white background, so we're all used to it.

If it's to bright for you at night, adjust your monitor. Or invert your screen colors if you can't live without it.

Let Ashley focus on more important features and/or the re-design of the interface.

Unless it doesn't take to much time to be implemented.

Other than that it should be on the very bottom of any to-do list.

I understand Ashley willing to implement Multi-Language Support, as he will be able to offer Construct to a wider audience.

But skinnable is just a waste of time.

If the skin of Construct is your only problem... /sigh