dupuqub's Forum Posts

  • Odd. I tried "Physics: Rolling Platformer" with gravity=100 and it's vibrating like crazy.

    Edit: it's tied to framerate. Changed from V-synced, and now it's steady.

    YES! That's a breakthrough right there.

    Could anyone care to comment on the implications of not using V-Sync though? I've always assumed it is something desirable in gaming, although I have no technical knowledge on why that would be true.

  • Hi.

    I searched you Construct demos site, but couldn't find a demo with this title. Which one is it exactly?

    I'm currently trying out the step iterations and modes.

    EDIT: On 100 Gravity, I just went as far as 64 iterations for Velocity and 24 for position and there is still jitter with default settings. There was also no difference between modes (fixed or framerate independent).

  • We are still waiting on the Scene Graph, but that could take months. Meanwhile we have the Timeline, but its not the perfect solution AT ALL.

    I believe since you already use Spriter, that could be your best bet. There is even a Plugin that maybe you already use construct.net/en/make-games/addons/192/spriter .

    Hope it helps, cheers!

  • Thanks!

    That's a nice catch. Just closed the bug.

  • Hi there.

    So... I tweaked it a lot, hope it helps.

    github.com/dupuqub/constructs/blob/master/Shooter.c3p

    There are many cleaner cuts to the code and to the actors' hitboxes. I wasn't really sure where was the bug so I had to keep cleaning wherever I could. The bug now is gone, also the other bug is gone (the one that flickered the screen when your mouse got centered).

    Also, maybe I found a Construct bug while fiddling with your code, so thanks for that.

    github.com/Scirra/Construct-3-bugs/issues/4047

    It may turn out to not be a bug after all, but I'll update this thread when we get the results.

    Either way, I'd recommend for you to check the file I posted in the bug report because it shows a very sleezy trap in the ELSE statement behavior.

    Best of luck and feel free to ask anything.

  • They're confined to immovable physics objects, confining them to the layout and/or to the screen is not always viable, therefore it should not be considered a solution.

    Also I tweaked every setting, including friction and dampings from both parties (the squares and the immovable block). As stated previously, the problem lies in the Gravity setting.

    And yes, you're right, every time a physics object is moving, it is finding a resting place, can't see how it could be any different.

    And also yes, it is undesirable, therefore, as I mentioned, there should be some sort of note on the docs or maybe, if possible, something should be done about it in the engine.

    EDIT: As a last reminder, everything happened with out-of-the-box settings, except for gravity, that's why I'm confident in my findings and hoping something can be done about it.

  • EDIT: The final realization of this thread (discovered by blackhornet) was that when Gravity is set to higher than 50, "Properties > Framerate Mode" behaves jittery when in V-Sync mode and works flawlessly when set to any other mode. It could be a bug according to dop2000, but I would like to hear from Ashley first before reporting it because I don't have the technical knowledge on the matter.

    Hi there.

    I've tried a bunch of different settings and tutorials, but I just can't seem to stop these dice from trembling all over the place.

    Just left click to create a bunch of squares and see the behavior in action.

    I believe this is mainly something wrong with my input values, so if you could help with that it would be awesome.

    github.com/dupuqub/constructs/blob/master/Dice.c3p

    The GIF below is using the out-of-the-box settings that come with adding the physics behavior in both the green dice and the black immovable block. Should I file a bug Ashley, since it immediately fails without me touching anything?

    EDIT: After some testing with the out-of-the-box settings, I saw the jittering only occuring with a gravity higher than 50. Later I tested with many tweaked settings and gravity seems to always be the culprit. I couldn't find anything on the matter in the docs, so should there be some relevant note in the docs or is it a bug or am I missing something? It is very much a trap for anyone tinkering with physics, since there's no obvious reason to not go further than 50 in gravity, and there's also no clear indication that gravity is screwing things up.

    Deeply appreciate any feedback, Cheers.

    Tagged:

  • Well, there is the official save/load tutorial:

    construct.net/en/tutorials/savegames-313

    I'd suggest giving it a go, fiddle around with it a little, there's nothing wrong with making mistakes, it may help you a lot more than someone just giving you the code, but of course if you have any doubts just post it here and I'll totally help you out.

    Also, if you're familiar with JSONs from maybe other sources, I'd deeply recommend using them here. They are amazing for storing data and are my go-to data model when dealing with multiple saves. If you are not familiar with them, just let them go for now and comeback for them later, it could hinder your development right now because it's something new to learn, but in the long run they become very useful.

    Cheers!

  • Unfortunately I'm not familiar with tutorials on the matter. I could ask dop2000 who is a true Construct guru for something for you to grab on to maybe. He also has this website howtoconstructdemos.com which features MANY awesome examples, maybe some of them may shed some light on your game.

    On another note I would propose that you build a pseudo-code, which means just a general map of features you would like to have in the game and then if possible share it with the community so we can help you achieve what you want.

    If you can describe your goals I can totally help you with the logic, and I believe many other people too.

    We are here for you, never give up!

  • Hi there.

    howtoconstructdemos.com/saving-and-loading-system-with-multiple-save-slots

    Try this out, many useful demos in there.

  • Honestly, I was incapable of finding where the flaw was in your code because ultimately I was unable to untangle the code in my head. It was very nested and maybe not so organized, so I can't properly say to you what went wrong, sorry about that.

    On the skeleton note, you can still stop them from moving when attacking, since you have the boolean called "attacking", so... just make it not move when "attacking = true".

    The skeleton follows the player from a certain "Range" already, this is defined by the "Line of Sight" behavior. It also only attacks from a certain "Range", this one defined by the instance variable inside each skeleton.

    Also it's hard to properly give any insights on the matter because when it comes to combat, every behavior and every move is unique in their own way, and each game may handle them differently. I would suggest only for you to take your time and work the logic gates the best you can to avoid convoluted code, also make it modular. Treat movements apart from animations for instance, and in this way it will be easier to debug when things go south.

    Glad I could help, but keep me posted on your evolution. If anything comes up just continue this thread.

    EDIT: You also already have something like your old "following" boolean, which is "Has LOS to object" from the "Line of Sight" behavior. If it has LOS, it is following, so no need for adding an unnecessary variable.

  • github.com/dupuqub/constructs/blob/master/Melee%20(1).c3p

    Hi there.

    There is a lot of work to be done still. This is nothing but the simplest possible resolution to your problem, but I had to do a lot of work to get here. Mainly notice that every animation had their hitboxes "fixed", by that I mean they are all rectangular and that is incredibly good for movement.

    You can see that now the skeletons move to the left without stutter. This is because every point in their hitbox is a round number. Before you had a lot of floating numbers as points and it causes many weird behaviors.

    The player also had a lot of work. I moved each frame to a point where the "face" of the hitbox hit 33 pixels always, it helps when jumping an falling back down. If they had been different, those animations could trigger each other and create a loop of doom, as I like to call it. Its funny as hell, but undesirable.

    Also, I believe you were not using the "Line of Sight" behavior, I might be wrong, but I used it now.

    Hope it helps. Feel free to further discuss this project, because there are still many challenges awaiting you.

    Best of luck!

    EDIT: Another detail about the player's animation is that the jumping and falling frames don't necessarily need to be higher and/or lower than the Idle animation, it's best to keep them linear because the jump action is enough to create the effect. It also avoids weird behavior on landing.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi there, maybe this tutorial may help you.

    construct.net/en/tutorials/basic-isometric-projection-753

    Also I agree with Newt, in some cases there's really nothing wrong with using sprites instead of tilemaps, but it might get out of hand depending on your project size, so just be mindful.

  • Hi there, I checked your code and there are some fundamental flaws in the logic and the hitboxes of the actors that may compromise their behavior slightly. Do you mind if I rewrite the code at least for you to use as maybe a reference?

    Also I would recommend looking at some tutorials on the matter. I don't exactly have a specific one to recommend.

    ps: what a f****** beautiful art, congratulations!