C3 Architect Request list

Ashley and everyone else

With the announcement of C3 on the horizon. I thought I would write down a list of mostly development flow suggestions. This is a Google doc editable by anyone. The idea is that anyone who has a suggestion that enhances C3 should be able to write them in a location for everyone to find.. Now I had started this shortly before the announcement and have only worked on the doc here and there. So it's still an early work in progress. Feel free to make corrections or clarifications by leaving a comment.

But everyone feel free add suggestions that mostly target

work flow

architect design

and overall game design improvement

and not suggestions that can be done now, especially if it's a plugin. Also these suggestions should be inspiring so that Ashley and staff know that if he doesn't want to create the feature, to allow C3 be workable enough that others can do the feature themselves.

https://docs.google.com/document/d/1pNRLro04cVYz6f2MUDT5ycDTKHOASVwDEPAI717ZGe8/edit?usp=sharing

I've also put the link in my sig

Cool idea, it could replace all those posts that are being lost in history. 1 File to look at much better.

Good work, jayderyu. Most of your suggestions are practical, well thought out, well explained, and would not be possible in the context of C2.

I added one minor addition: Bool/Array as a new global/local variable type.

I added one minor addition: Bool as a new global/local variable type.

Quantrillion times this. Should be easy as pie in C2 already, why isn't it?

I added one minor addition: Bool as a new global/local variable type.

+1, aswell as some sort of json object / dictionary where you can quickly set/create/delete values/keys.

I did not added this as I am not sure it has its place (it seems unfixable in C2 IIRC and was introduced to prevent crashes as far as I read)

correcting the "pick just created instances in sub events", this bug is plain annoying, and has confused also people in the past in believing that events are not read one after another.

Aphrodite

I'm not sure how to relay this. As far as I know as soon as an Object is created. The ES following the creation of the object directly refer to the newly created object. You can also use OnCreated Event for an object for doing that pick.

However, you are right on a few occasions I create an object but needed to SOL Pick the object immediately. I'm not sure how to convey this issue, but I'll think about.

Ashley will understand the issue.

"Allow picking an object regardless of when/where it was made". Ref: You can not use a Pick event on a newly created object until the next top level event.

Aphrodite

I'm not sure how to relay this. As far as I know as soon as an Object is created. The ES following the creation of the object directly refer to the newly created object. You can also use OnCreated Event for an object for doing that pick.

However, you are right on a few occasions I create an object but needed to SOL Pick the object immediately. I'm not sure how to convey this issue, but I'll think about.

The thing is that currently, doing this:

destroys the already present sprites but not the newly created one (aka it is not picked)

than this:

destroys all of them (it is picked too)

Then finally:

Destroys all of them (it is picked by the pick by UID, which is Direct)

Where all should act the same way (destroy them all)

CC had it where often used conditions were highlighted, and at the beginning of the list for system, and objects.

It would be nice to have something like that as it takes a while to find what you are looking for.

Likewise it would be nice to have that feature for the other parts of the editor, like for objects, behaviors, etc.

Several different orders would be nice, like an official plug listed first.

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

• Textures independent from objects (reusable textures, preserve imported texture atlas)
• Multiple textures per object (color, normalmap, heightmap... accessible to shaders)
• 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)
• Directly draw to layers as a primitive (built-in Canvas plugin functionality)
• 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)
• Support for shaders with multiple passes (at least display as one in the IDE with all collected parameters)
• 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

• 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)
• Physics interactive with all movement behaviors (use verlet physics like Chipmunk as base that handles the set position problem)
• Support all physics features (prismatic joint, kinematic body...)

Event Sheet

• 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)
• Flexible data structures as primitives (list, arrays, dictionaries, trees, nodes... )
• 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 )
• 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)
• 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)
• Expressions automatically generated for each settable plugin/behavior parameter ("if one can set, one should get", being automatically generated ensures consistency always)
• "compare [property]" events being automatically generated for each expression (...or not exist at all: compare only through system compare, but it should be consistent)
• 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...)
• Pick objects by name / Get objects name

Interface

• Support for interface addons (third-party editors)
• Improved form controls for plugins/behaviors/effects (color picker, slider (or blender-like editbox), checkbox, bezier curve, display forms conditionally, forms grouping...)
• 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)
• Editboxes support math operations during edit-time ("position.X: 100 * 2/3 + 10")
• 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]
• Built-in visual data editors (for long text, arrays, nodes, etc...)
• 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)
• 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...)
• 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)
• Custom colors for events and actions (for better organization)
• Color coding for expressions based on the returned value type instead of segmented sub-attributes (clearer for reading complex expressions)
• 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

• Group objects on layout editor (physical parenting, move and rotate all as a single entity, accessible in events... replacement for containers)
• Improved inheritance/family system (support mixed object types, sub-families, changing from object to family later is extremely inconvenient and should be re-thought, ...)
• 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)
• Copy/paste/create instance variables from object (ability to transfer or clone instance variables from one object to another)
• Preview in layout editor (live preview)
• 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")
• Circle collision primitive besides polygon
• 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)
• Merge sprite and tiled-background ("tilling" as a property of sprite)
• Sprite distortion (similar to CC mesh)
• 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)
• 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)

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.

Animmaniac

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

Ashley

Please, please, read the above post. This is what C3 should be.

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.

shinkan

Like a dummy object, but I would add the ability to import an object at runtime.