DiegoM's Forum Posts

  • Rory You really want that Prefab goodness don't you? :P

    There will definitely be an editor tool to build hierarchies that can later be used at runtime.

    As for reusing a hierarchy... I think it could work like the Set Instance action of the Timeline plugin, where you can define a base timeline in the editor and then at runtime use it with different instances other that the one used in the editor.

    Something similar could work in this case.

  • TackerTacker We initially imagined the feature as a way to build structures of instances, with no connection to rendering... having said that, a couple of actions to control the z indexing of related instances sounds like a pretty sensible idea.

  • dop2000 newt

    The next beta adds the option to choose what should happen to a nested child if it's parent is destroyed. It will either be destroyed with the parent, or just detached.

    As for containers, as I said, nothing has been even tested, just don't take what is said in this thread as a final answer. The next beta introduces a few new conditions to pick parent's and children so that will give more control.

    We are trying not to get ahead of ourselves, because it is not clear what the best approach is in some cases, we are trying to cover the basics and only after that is working look into the issues that people might have from actually using the feature.

  • Mikal I think what you did to build the hierarchy would be pretty much how it would work... as far as a pure runtime actions solution goes.

    What you did with instances variables will eventually be covered by a tool in the editor which hopefully will be more friendly, but ultimately will do the same as you did, tell each instance who is it's parent. Later that information will be exported to the runtime and you won't even need to set it up in events, the whole thing will be built automatically to mimic what was configured in the editor.

    The editor tools are still a bit far way, so for now this is the best we have.

    I do find the two family trick a little bit weird myself, I wonder if it could be promoted from hack to feature just for this purpose... we'll see how that turns out.

  • There isn't anything implemented yet, but containers do sound like a logical choice.

    Chances are high that when a hierarchy between instances is established, all the instances involved will be automatically added to a container, so picking will work as expected from that point onward.

    None of this has been tried out yet, but it sounds like it should work.

  • Introduction

    As some may be aware of, the latest beta introduced the first pieces of Construct's own implementation of a scene graph.

    Some people are excited, for good reasons. But I read from quite a few that have no idea what the fuss is all about. Allow me to explain...

    First, what is a scene graph?

    Scene graph is a fancy name for a tree structure, in which a root parent object can have children and then those, children of their own. A quick search in Google let's me find an image to convey this, here it is.

    In the context of Construct, this new feature allows you to establish that kind of relationship between plugin instances (at the moment only Sprite instances).

    With that hierarchy created, it is possible for the runtime to calculate translations, rotations and scaling of a child based on that of it's parent.

    • Example 1: a parent is translated in X for 100 pixel, all it's children will follow to ensure they maintain their relative position to the parent.
    • Example 2: a parent rotates then all children will adjust their positions to rotate around the parent's origin as well as adjust their own rotation.
    • Example 3: a parent changes it's scale, all children will adjust their positions as well as scale in response to the parent's changes.

    The most common case would we for any of this things to happen at any given point and Construct will calculate the correct position, rotation and scale for all the instances involved.

    Keep in mind that all child transformations occur around the parent's origin. I think this is better demonstrated by this small example project.

    https://www.dropbox.com/s/etwun316sox4lne/SceneGraphExample.zip?dl=0

    New runtime actions

    The latest beta introduced 3 new actions, Add Child, Remove Child and Remove From Parent. To make things easier on ourselves, at the moment these are only supported on the Sprite plugin, as the feature matures and we iron out bugs and implement user feedback more plugins will be supported.

    • Add Child: This one is used to add a child to another instance. It's pretty straight forward. When an instance is added as a child of another one there is no immediate change, it is only when the parent is modified that the child will respond accordingly.
    • Remove Child: This is pretty straight forward as well, remove the specified child from the picked parent.
    • Remove From Parent: This is similar to Remove Child, but allows you to remove the picked instance from it's parent, without knowing to which instance it belongs.

    I think this is it for now, I will update this thread as more features are added. If you have any questions I'll try to answer them here.

    Tagged:

  • This is a difficult problem.

    The gist of it is that the client should never be trusted, the server is the only source of authority. As such the server should always perform validations on a score before it deems it valid.

    That is the difficult bit, what is a valid score? That is completely tied to each game and depending on it's logic it might be impossible to determine if a score is fake or not. Even if you can determine if a score is fake, how can you handle a client sending the maximum valid score every time?

    Short story, validating a single value sent over a single request is difficult if not impossible.

    Possible solution:

    I guess you could try using web sockets so the client communicates constantly with the server about what it is doing, sending messages each time the score increases. When the game ends the client could send a message saying the game ended and the server can tally the final score.

    If a client get's funky and starts sending too many messages to increase it's score, you can determine it is trying to cheat. Sending messages with score amounts you know can not happen in the game? Cheater. Like that there are many things the server could do to spot unusual behavior on a client.

    The problem with that approach is that to send a valid highscore you need a stable internet connection, if you don't the server can't make real time validations, so it won't accept any scores. This might be a compromise you are willing to make, you could have two modes, "For fun" which does not perform real time validations and can not save highscores, and "For score", which does all the validations but needs the stable connection.

    Maybe there are easier solutions, but can't think of them right now. Good luck!

  • Yes, at the moment only the sprite plugin supports this new functionality. It's a big feature so we are taking small steps to be able to catch problems more easily.

  • Coincidentally this feature has been added to Timelines, and will be landing at the start of the next beta cycle.

    It was implemented by means of the "initial frame" property of the Sprite plugin. This means a timeline will interpolate the value of that property and assign a new frame as the timeline progresses. There will be a few things to look at for when using it.

    Because the timeline will be changing the frame of the animation, the plugin itself will not be playing the animation, so all triggers and conditions that the plugin would normally execute, will not happen. Instead you will need to rely on similar triggers and conditions on the timeline itself.

    The only exception to this, is the On frame changed trigger that the sprite plugin will execute while being animated by a timeline.

    Furthermore, attempting to play a Sprite animation normally while it's current frame is modified by a timeline will result in strange behaviour. So it will be a case of picking one or the other, but not both.

    I doubt this will be added to Tweens, it is a rather specific behaviour and while it is possible to implement it, it would be a pretty ugly monkey patch.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • That's not a good way of getting around things in general. It's all mostly in your head, the possibility of someone actually stealing your stuff and then go on to make it big because of it are quite slim, almost non existent.

    No one wants ideas, most people want results. Thieves don't want to put in the hard work. Ideas while great on paper, need the hard work to realize them, which is what gives them value.

    If you are still worried, get feedback from people you trust, like friends and family. You might also consider people who are NOT into software development as they would be less likely to take interest in the nuts and bolts of what you are working on, and just look at the flashy colours on the screen.

    On the same note, feedback from people who are only consumers of software, tends to be more honest because they are not aware of the struggle of game development. In short, they are more likely to say something that you might not want to hear, just because they have no idea how hard it is :P

  • I found a couple of things with that project of yours.

    1) The track for the instance was disabled, that means it wouldn't do anything at runtime. You can see if a track is disabled by either clicking on it and checking the properties bar or by looking at it's corresponding check box in the timeline bar. You know all the check boxes to the left most of the bar? They are from left to right Visibility, Locked, Enabled, Show UI Controls.

    You can read more about those in the manual entry https://www.construct.net/en/make-games/manuals/construct-3/interface/bars/timeline-bar

    2) You almost got everything right with the Set Instance action, but you missed setting the track id property.

    You can view the track id property by clicking on the track in the timeline bar and checking the properties bar. That value has to match the one you use in the Set Instance action.

    The manual has more information on the action https://www.construct.net/en/make-games/manuals/construct-3/plugin-reference/timeline