jayderyu's Forum Posts

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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

  • I'd been keen on a Kickstarter if it would include them hiring a couple of extra developers. This one man team is amazing, but 2+ would be better.

  • eh. The Event Sheet system has the benefit of making the way we program so much better. The draw back to the ES system now is how C2 requires so much over head to make the system interact with C2. If it was easy to just pre-tag information and then C2/C3 could interpret that for the ES system. Then I think more people would jump on board with the entire ES system.

    Code would be written as a form of classes, but not directly related to game functionality.

    ES would be the glue between it all. This would increase overall development. But as it is. the SDK ACE system is heavy.

  • I'm not against a native exporter, but I know Scirra won't do so. I know why too. Browsers do more than just execute JS. Browsers have huge amounts of features to take advantage of. For C2/C3 to support native would require breaking all those Browser features and linking to an abstraction layer.

    Is it impossible. No, but it's not going to happen as a two man team. If C3 proves so successful that Scirra expands to 100+ staff. Who knows.

    megatronix

    I'm hoping that SceneGraph based Object is added as a new core object. Pin would then be obsolete, though thep lugin would exist to be backwards compatible.