Can you provide a capx.

but as a heads up.

A pinned object can't be moved until un pinned.

You can't apply sin to the IP. just the objects

A list of add-ons that are not available would be a good idea. At the moment I think your notified of only one plugin missing at a time.

A lot of good ideas. Though all of them are not architecture issues that C2 prevents. However please present them so that they can be examined and take a deigns look to see if there is a block. Sooo

* Collision Group/Layers - no blocks for C3

* Exporting ES Group as a Behaviour and Modular object - requested and the doc supports the idea a MAJOR feature

* ES to Objects. The above suggestion would support this design

* Save/Cloud - no block

* IAP - no block

* Leader board - no block

* Achievements - no block

* Steam integration - can't say. Depends on Steams own API and bindings to Cordova, however - no block from C2/C3

* Spline based system - you can read the thread and note that this is a major reason why C3 needs to exist - no block

So the document is up to 23 pages. 24 with some sectional white space. More than I thought it would reach. I'm not sure that's a good thing though

Mabaet

I suspect earliest testing period for hardcore SDK developers will be 8 months, and this will be just for a select few. Then 14 months for signs of a select few developers to have early access. And then apx 16 months before C3 is in open beta.

currenct C2 owners will get a great deal on getting a C3 license. As I understand C2 started at $50 for super early users, apx $90 for beta, and 130 after reaching release 1.0(r100). So i suspect a similar cost release will occur for c2 owners. Keeping in mind that C2 had only a few plugins and C3 building on top of the runtime right now. So I suspect c2 owners will get early access for about $50. Once 3 is released however any C2 license upgrades will be on parity costs to be about the same.

duuuuh, now I remember why Ashley won't implement it. Ok first I stand by my prior statement of popup. However there was another reason.

JS doesn't support asynchronous asset loading. Which means popup or not the image will cause the game to freeze. Now I still feel this is a worth implementing and can be a consequence and just part of the game design. I also searched up and there is a way to asynchronous load. Which is now added to the document.

HeadClot

Unfortunately Ashley feels that layout asset management should only be his responsibility. He feels that loading and unloading assets would confuse newer developers and they would complain. The complaint being that this would 100% create popin and popout issues. However this pop in/out is normal and require zone buffering and level design to avoid players seeing pop in/out. however since that requires people to take that into account in design and would be a more advanced development feature, Ashley for that reason has elected to not allow it. So yeah. We have made the request. but I doubt it's one we will see it until it more of the community becomes vocal. But C3 may allow better developer control to do so anyways. It's just a matter of seeing what comes from C3.

Skinnable is a result, not a low level feature. What I put in the request list was changeable IDE, even if such a feature does not appear on release. As long any someone can make the feature. That's good enough for Ashley to focus on. Low level architect.

A lot of good ideas, but it seems so far that all can be accomplished with the current running architect suggestions.

I'm crossing my fingers. Waiting for some more news down the road

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.

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.

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.

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.

gamecorptm

You might want to check the post date a few posts back