C3 Architect Request list

Discussion and feedback on Construct 2

Post » Fri Feb 06, 2015 5:33 pm

Animmaniac wrote: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)
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Fri Feb 06, 2015 5:48 pm

Animmaniac wrote:@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.
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 » Fri Feb 06, 2015 5:59 pm

megatronx wrote: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.

Fimbul wrote: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.
Scirra Employee
B
153
S
53
G
17
Posts: 710
Reputation: 17,825

Post » Sat Feb 07, 2015 1:53 am

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.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Sat Feb 07, 2015 4:14 am

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

More info: ashley-could-you-please-confirm-this-behavior_p883775?#p883775
I got a game that you multiply, breath fire with two heads and brawl foes to oblivion with your clones: http://www.newgrounds.com/portal/view/660664 (use Chrome on Windows for best performance)

My sites:
http://twinblazar.deviantart.com
http://twinblazar.newgrounds.com
https://twitter.com/twinblazar
http://www.pixiv.net/member.php?id=15072448
B
30
S
11
G
11
Posts: 411
Reputation: 8,469

Post » Sat Feb 07, 2015 10:18 am

Commenting so I can read later...
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
141
S
23
G
8
Posts: 790
Reputation: 15,017

Post » Sat Feb 07, 2015 10:48 am

We really need c3?? c2 s great already
B
110
S
27
G
47
Posts: 1,887
Reputation: 35,799

Post » Sat Feb 07, 2015 7:00 pm

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.
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 » Sun Feb 08, 2015 10:07 am

So far all id like to suggest is naming it Construct 2 PRO and not C3. Feels more right in my opinion
B
47
S
10
G
5
Posts: 232
Reputation: 7,561

Post » Sun Feb 08, 2015 12:36 pm

A lot of great suggestions.
However the only one i want to bring up again is:
megatronx wrote:- 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.



EpicPixel wrote: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 :D

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 :P


------------------------------------------
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
B
40
S
8
G
3
Posts: 159
Reputation: 3,019

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 15 guests