C3 Architect Request list

Discussion and feedback on Construct 2

Post » Sun Feb 01, 2015 9:54 pm

Since this thread seems more serious in organizing things, I'll post my C3 feature suggestions here.

This is what I gathered over the years from using CC and C2. It includes only the main ideas that I remembered to take note. There's a lot of smaller things about use flow and UI that could be improved, but I think that listing all of them is not viable.

I don't know if everything complies with what the OP expects, so if needed be selective.
*The suggestions are loosely organized and in no particular order.


Rendering

  1. Textures independent from objects (reusable textures, preserve imported texture atlas)
  2. Multiple textures per object (color, normalmap, heightmap... accessible to shaders)
  3. Enhanced pixel compositor (access to world normalmap, depth buffer, heightmap... for post-process effects like 2.5D lighting (like Sprite Lamp), depth of field, ambient occlusion, fog... see Rayman Legends)
  4. Directly draw to layers as a primitive (built-in Canvas plugin functionality)
  5. Easier layer/object masking (auto duplicate objects/layers under the hood and apply proper blending mode to mask non sequential objects/layers, should only require what object/layer to use as a mask)
  6. Support for shaders with multiple passes (at least display as one in the IDE with all collected parameters)
  7. Define input-field's value transformation in the shader's XML file (like "x/255" or "x^2", so the user can work with more friendly numbers in the editor, without the need to include these in the shader code and waste resources recalculating for every pixel, the IDE/runtime could do this before passing values to shaders)

Behaviors

  1. Special interactive behavior stack for quick AI/auto-movement (steering behaviors rocks - seek, flee, wander, avoid obstacle, path/wall following, separation, alignment, flock, brake... - they add on top of each other, each have a weight slider that sets the degree of influence to the final movement, interactive with regular movement behaviors)
  2. Physics interactive with all movement behaviors (use verlet physics like Chipmunk as base that handles the set position problem)
  3. Support all physics features (prismatic joint, kinematic body...)

Event Sheet

  1. Functions as primitive with multiple return parameters (like it has for calling - allows to create contained functions that processes and returns multiple parameters without the need for parsing and using extra variables)
  2. Flexible data structures as primitives (list, arrays, dictionaries, trees, nodes... )
  3. Vectors for composite parameters (position, size, etc... with support for vector math, similar to GLSL: "sprite.position + vec2( cos(angle), sin(angle) ) * speed" - evaluates X and Y in a single expression )
  4. Local variables easily made global and vice-versa (set globals through a checkbox - not based on positioning, allows support for eventsheet-scope local variables, and to position globals anywhere for better organization, less unnecessary globals polluting var lists)
  5. Better handling of error and missing references (display events with broken references as red instead of hiding, even if references are invalid, but make them commented under the hood to not execute - allows to replace references later which facilitates migration of code between projects)
  6. Expressions automatically generated for each settable plugin/behavior parameter ("if one can set, one should get", being automatically generated ensures consistency always)
  7. "compare [property]" events being automatically generated for each expression (...or not exist at all: compare only through system compare, but it should be consistent)
  8. Manipulate SOL directly in eventsheet (save SOL to variable, pick by loading SOL, expression for SOLs intersection, expression for joining SOLs, expression for subtracting SOLs...)
  9. Pick objects by name / Get objects name

Interface

  1. Support for interface addons (third-party editors)
  2. Improved form controls for plugins/behaviors/effects (color picker, slider (or blender-like editbox), checkbox, bezier curve, display forms conditionally, forms grouping...)
  3. Improved blender-like editbox that favors value experimentation (demo here, works only on chrome and has some small bugs, but you can get the idea. The same features could be added to directly edit values in event-sheets)
  4. Editboxes support math operations during edit-time ("position.X: 100 * 2/3 + 10")
  5. Editboxes support expressions during edit-time ["position.X: round( sprite2.X ) + sin( sprite.angle )", pressing ENTER leaves the expression as a linked reference and SHIFT+ENTER evaluates it]
  6. Built-in visual data editors (for long text, arrays, nodes, etc...)
  7. Quicker event placing with improved wizard (filter lists in a single screen - no multiple wizard screens, auto-selects the last used actions when a new event is created, auto-casts the event selections when the object is changed, supports categories and folders filters, makes quick and easy to edit events - object, condition, parameter and expression selection in a single screen)
  8. In place events editing (similar to CC but better, use blender-like editbox features to edit values in place: drag to increment, ctrl to snap, shift to edit decimal...)
  9. Tags for event groups to reference them instead of the group name (separate organization name from functional tags, allows groups with same name for better organization, and to toggle multiple groups with same tags)
  10. Custom colors for events and actions (for better organization)
  11. Color coding for expressions based on the returned value type instead of segmented sub-attributes (clearer for reading complex expressions)
  12. Layers display all object instances contained in z-order when expanded (similar to Adobe Illustrator layers - improve the usefulness of the layers panel and eliminates the need for a specialized z-order panel, individual instances could be re-ordered and selected in this single panel)

Misc

  1. Group objects on layout editor (physical parenting, move and rotate all as a single entity, accessible in events... replacement for containers)
  2. Improved inheritance/family system (support mixed object types, sub-families, changing from object to family later is extremely inconvenient and should be re-thought, ...)
  3. Use fixed time-step for events and interpolated steps for display (game behaves more consistently across different devices and frame rates, solves the problem of missing collisions in low frame rates due to the discrete nature of Construct's collision test, increases the processing budget for events if run at e.g. ≈30 ticks per second, and lowers the barrier for beginners by eliminating the need for dt in events)
  4. Copy/paste/create instance variables from object (ability to transfer or clone instance variables from one object to another)
  5. Preview in layout editor (live preview)
  6. Multiple collision polygons per object (allow a different movement collision hitbox, from damage hitbox, from attack hitbox - could work like imagepoints, index 0 used as default by behaviors, and others accessible as a parameter of "is overlapping" or "on collision")
  7. Circle collision primitive besides polygon
  8. Different types of layers instead of some objects (2D layer, tilemap layer... possibility to be extended in future with 3D layer and vector layer - allows to display specialized toolbars depending on the selected layer, less cluttered than using objects, easier to manage and edit)
  9. Merge sprite and tiled-background ("tilling" as a property of sprite)
  10. Sprite distortion (similar to CC mesh)
  11. Set anchor point for tiled-background (set if the texture is anchored horizontally to the left/center/right and vertically to the top/center/bottom - determines to what sides the texture expands)
  12. Object's scale detached from width and height (like the editbox demo *works only in Chrome, "obj.finalSize = obj.size * obj.scale", where obj.scale is an arbitrary value defined by the user and not derived from obj.size - more intuitive than current method, solves the obj.scale expression problem)
Last edited by Animmaniac on Wed Feb 03, 2016 6:29 pm, edited 19 times in total.
Scirra Employee
B
153
S
53
G
17
Posts: 710
Reputation: 17,825

Post » Sun Feb 01, 2015 10:18 pm

I'll die a happy man if Spriter can have a dedicated interface within C2, less plug-in, more bolt-on. Thoughts @lucid?

I'd also like to see better texture support, as mention by @Animmaniac - hopefully we can then get some Sprite Lamp support, or something similar, as these were limited by the 1to1 texture/sprite limit.
Last edited by Elliott on Sun Feb 01, 2015 10:20 pm, edited 1 time in total.
B
59
S
21
G
10
Posts: 643
Reputation: 10,293

Post » Sun Feb 01, 2015 10:19 pm

@Animmaniac

Image Image ImageImage

Absolutely the best list of suggestions yet, by anyone. Bravo. :D

@Ashley

Please, please, read the above post. This is what C3 should be.
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Sun Feb 01, 2015 10:28 pm

@Animmaniac just to add to your wonderful post. I would like to see "GameObject", "Prefab", "whatever the name is" approach to objects in C3. Just like Unity or UE. Where you place an empty object and then you add what you want and need to it.
-GameObject
- sprite (set texture)
- collision (poly, circle, line...)
- behaviors
- etc

and on top of that, don't know how it's like in Unity but in UE4 for each object you get blueprints to setup how this object behave in editor and in runtime.
ImageImageImageImage
B
157
S
66
G
42
Posts: 2,603
Reputation: 35,343

Post » Mon Feb 02, 2015 12:08 am

@shinkan
Like a dummy object, but I would add the ability to import an object at runtime.
Image ImageImage
B
169
S
50
G
173
Posts: 8,319
Reputation: 110,282

Post » Mon Feb 02, 2015 12:25 am

@Animmaniac Great list hopefully these are the type of features C3 adds or enables us to make yourself
B
42
S
17
G
2
Posts: 850
Reputation: 6,209

Post » Mon Feb 02, 2015 12:55 am

newt wrote:@shinkan
Like a dummy object, but I would add the ability to import an object at runtime.


Maybe not dummy but more like a component.
As for the import at runtime... Yeah. It depends of the C3 workflow (?) really, and I can think of only two possibilities:
1. You could make components made of previously defined objects - in this case this would be like a container, that holds included objects - So you can add to layout just the plain sprites or components (sprite1+sprite2+tiled background for example)
2. Component is just an empty name/place/thing and everything you want to add to the layout is made of whats inside of current component. You can't add a plain sprite to the scene, because by itself it's doing nothing. But instead you need to add a component - which contains: sprite, collision, behavior - and this makes an object complete and ready to use

Either way if that kind of control be possible in C3 than "wow".
ImageImageImageImage
B
157
S
66
G
42
Posts: 2,603
Reputation: 35,343

Post » Mon Feb 02, 2015 1:12 am

@newt
I like that suggestion. That's one of things about IDE control that I would like non Scirra developers able to do. IDE plugins.

@Animmaniac, @shinkan
We are soooo much on the same page. Much of the document that I'm writing is trying to tackle those issues. Not in a way that Ashley needs to re-write everything. but in a core way that those requests can be done. Either by Ashley or someone else.

I have SceneGraph Object to be minimalist for such a use, and Behaviour drawing so that Sprite rendering can be done from a behaviour. I also listed behaviours and plugins to be able to draw and manipulate widgets.... so yeah. I think we are soooo much on the same page. However I can put most if not all in either as sample use or engine feature that I have overlooked. I also added Quadtree collision and Circle and Box collision objects.

Great list, some covered. but good examples. Some need to be written up as they own section. Some are harder and I think will be added to a Wishlist. I would love Editime operations in a field, but I don't even see that in Unity :D. However I do see that in JavaFX.

Keep them coming :) and please feel free to edit the document if any of you feel any part can be written better. I know I sure take no pride in my grammar.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Mon Feb 02, 2015 12:46 pm

@Animmaniac @jayderyu Nice.

My additional suggestions, also those I remembered throughout the years:

- Disable Solid between selected objects only
- Solid behavior to work with movements behaviors
- Platform pathfinding
- Possibility of saving Array state in game/preview and then being able to view that saved table trough visual editor
- Array import form external file ( like csv, excel table )
- Option to display Array in the layout and in the runtime
- Proper Audio Browser, with insert sound that will automatically create audio tag
- Menu creator that lets create in game menu's easiliy
- Option to set keybinds and change resolution in game by default
- Support for In's, Main's and Out's for animations
- Pick n nearest/furthest objects ( fopr example "Pick 3 nearest" )
- Curve editors to supplement math, or some sort of default math to help those who don't really know how to do it well ( like doing a cigar shape pattern etc)
- Load layout from external file at runtime and in ide
- Simplified controller plugin ( especially for the sticks, just use degrees and then number )
- Looping layout
- Streamlined parallax editing
- Pick object by TAG
- SVN support
Last edited by megatronx on Tue Feb 03, 2015 2:47 pm, edited 2 times in total.
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 Feb 02, 2015 2:40 pm

Elliott wrote:I'll die a happy man if Spriter can have a dedicated interface within C2, less plug-in, more bolt-on. Thoughts @lucid?.

Definitely. There's a few requests I have for the plugin system (and it seems from the blog post Ashley is thinking in this direction already). I'll go ahead and respond to thread topic as well, with general requests for c3.

I don't have time at the moment to read back through the thread so I apologize if I'm rehashing anything.

capx based edit-time ui creation
I would like for the edit-time ui programming to be a alot more like runtime programming and eventing. You could include in the plugin directory something like a small limited capx that serves as the ui for your plugin when double clicked or hovered or whatever you set in the edittime. For instance, you could make a capx that has drag and droppable sprites, dials, combobox boxes, etc. There could be an editor ui plugin or system actions that let you set values that can be passed to the edittime of the plugin. Same thing for plugin input parameters. It'd be cool to be able to create an interactive ui for ACE parameters using a capx. You could make it so users could input your color parameters with a color picker, and some numeric values with sliders, dials, spinboxes, etc, instead of typing.

But the real power would come from being able to combine several parameters within a single control. You could make a mini-capx that creates a visual speed (easing) curve editor that sets each control point and curve parameter, or see a preview of an animation at the time you're sliding to between 0 and animation length, or anything else you could create in C3 for game use, would be useable in the parameter input ui. You could make particles show an animated preview using the parameters you're setting with sliders, or a scrolling background showing you the speed that you're setting with an 8 direction behavior.

To avoid plugin UIs becoming too huge and bogging down the editor, there could be a simple restriction that you can only use a shared set of useful ui images for sprites, like triangles, dots, and all ui element type plugins, any images from the current project, and maybe a super small allowance for custom ui images. Maybe it could have a file-size or event limit as well, so they can either be loaded quickly or stored in ram. I believe Ashley mentioned in the blog the idea of being able to make plugins out of events, so if something like this was implemented, it'd make sense to give these same abilities to event sheet based plugins.

plugin access to create lists like the animation name or function name list
This might already be possible, but it would be good to be able to add to a combo_box or autocompletion list at edit-time, so for the Spriter plugin for instance, you'd be able to choose animations, entities, character maps, etc from a drop-down list.

additional variable types
Some of this could be made into plugins and behaviors for C2, but it would be a lot cleaner if it were built in. I'd like there to be dictionaries and arrays as regular variable types for object private variables and global variables. I'd also like to see objects as variable types, and any combination of the above, like a dictionary of arrays of objects as a private variable to another object.

new function object and variable objects
I'd like a function object that can take objects as parameters as well, and a special 'variable object' that you use a proxy to objects used as parameters or variable objects called into it. They would have all the commands that are common to many objects like create, destroy, set width, height, scale, angle, x, y, etc. You could then use this object as a proxy for the object using all the associated actions, conditions, and expressions are. The function object (and may even the global and private object variables) could also specify a specific object type, so you could make a parameter specifically for "sprite" or "particle" types, and then only those would be valid as parameters. In these situations you would get a variable object of that specific type and have access to all of it's functions even though you weren't sure which specific 'sprite' or 'particle' object type you were dealing with. Variable objects could also have set private variable by name, and if the object had a variable by that name it would be set.

behavior universal data sharing
For behaviors, I think it would be extremely useful if there was a concept of universal data sharing. Let's take the 8 direction behavior, the platform behavior, and the physics behavior, which all have the action setVelocityX, and an expression called velocityX (or something similar). Of course, any plugin could ignore the universal settings and keep their own local copies if needed, but each plugin would have access to a setGlobalVelocityX (always pixels per second), and getGlobalVelocityX, and others for rotation speed, etc. Now if you move a sprite with 8 direction behavior, physics behavior knows it's moving at that speed, and behaves accordingly, and vice versa. Or if you want to switch from platform behavior to 8 behavior on a certain event, when you switch over control it will automatically set it's velocity. As an alternative to the functions like setVelocityX, etc, you could just set the behavior to participate or ignore each value, and it would automatically make the velocity calls by checking the x, y, angle, etc, each tick and using those to determine velocity. I also like the idea of being able to set whether to update those values when you use common world object commands like setX or setAngle, so if you manually control your character with commands like setX or angle, the object will have appropriate momentum with any plugins. This universal data sharing for behaviors would also work well with the variable object concept, as you could also have a universal set of commands that could do something similar to all behaviors.

more granular SOL access and object picking
I'd also like to see some additional picking features, like splitting up a single object type into multiple selections, that you could call by a custom tag or index. One example usage would be having an array of objects, all with physics behavior and you want to make a rope bridge. You could just run a loop and say plank[loopindex] create hinge to plank[loopindex+1]. Or if you had a function with the object parameters "attacker" and "defender", then you could access two of the new Variable type object and be able to easily refer to one or the other in any actions, conditions, and parameters. For example, you could say : Set VarObject[attacker] position to VarObject[defender].x, VarObject[defender].y
Last edited by lucid on Wed Feb 04, 2015 6:25 am, edited 1 time in total.
Spriter Dev
B
99
S
21
G
12
Posts: 3,259
Reputation: 16,894

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 12 guests