XpMonster's Forum Posts

  • Easy that.

    Trigger once somehow: Play (by name) - Audio File Name: choose("Track1","Track2","Track3" & etc.)

    On Ended (tag that will be shared in all tracks) - Do it again.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In theory (not in C3 tho). If host (as first player) leaves, you will be forced to drop connection, all users autonomously would select the second player, check if they can establish connection, if he's not - select third.

    But then...what if the original host didn't really disconnect? What if he just lost his connection for a short-period of time? 10 seconds and he's back, but players moved already to the second player who for example has worst internet. Would the game had feature of redirecting itself back to the original host if he's back? That's a lot of headache for developers with pretty small benefit for players too.

    I think implementing feature for hosts to pass their position to other players if they decide to leave would be better.

    Too much redirecting. It could be too huge depending on the game.

    This is not something developers practice often.

    If you just create your game to play with friends you don't really need this.

  • Not good at math, but if I understood what you need correctly then here's the answer:

    If you want to add exactly 1% of original Image Width (change plus to minus to decrease)

    If you want to add 1% of Current Width (change multiply to divide to decrease)

  • Use action System / Scroll to Position.

    However if you want camera to follow the player - add your character Scroll To behavior.

    In Editor you can't change it and there is no practical reason to.

  • Without optimization it will. Better make a simple proof-of-concept game first & then work on beautifications (like shadows & amazing explosions).

    Containers are always a good choice. Use them every time you can!

  • Hi.

    You only really need to send the most essential data to peers. Player coordinates, angle & etc. Everything that somehow gameplay-related, not just visuals. There is no need to share the whole map.

    e.g. If you need character's shadow - send only character's coordinates & angle. Shadows should be updated for each peer individually based on that data. There is no need to flood connection with this.

    You could make any online game, but you have to be very smart about what you send.

    Also you'd have to show us what you have updated so we could see what could be the reason for lags.

  • Here is updated version with swinging

    Probably took it too far this time xD

    Code is pretty raw and it is kinda clunky, but you should be able to take it from here.

    It was pretty fun though ;D

  • Jase00

    This is more psychological question than legal. Sentimentality clouds your judgement.

    Many of us develop commercial projects here spending months & years.

    I've spent quite a lot of time preparing both mentally & technically to make the project I'm working on. Sure many others here go through similar problems, but it is surely a hell of a journey for me.

    I only know Construct well enough to make the game of my design and there is no engine which could ever replace it for me at this point. Not when I'm so alone and project is too big for one person.

    So yeah I care for my project very much. It could potentially even kill me to lose access to it. But I want to create the best game I can and I need the best engine I can handle. Construct 3 is my one & only option and to hold myself with some hypothetical Scirra-crisis would be creatively suicidal.

    I have strong confidence in the engine I have chosen and people who work on it never made me question it so far.

  • I rather weird demand to be honest.

    This is a Web-Based Engine. (Online Engine, basically).

    Is there any guarantee that any Online Game for example will return you anything once their servers shutdown? That users will still have access to all the content they purchased throughout the years which in summary quite often would be likely more expensive than the overall cost you mentioned for Construct? There is no guarantees there and here shouldn't be any as well.

    If everyone uses the engine, everyone buy subscription and company has enough to continue at least supporting it. The more money they earn, the better future this engine will see. If everyone just slowly abandon the engine and stop buying subscription then there is no real need to continue supporting it anyway. Sure there will be some dedicated users & some nostalgia comebacks, but by the time they will all have it coming. You can always tell when Online Product is about to die.

    Scirra grows right now. Engine is now not only for ethusiasts & hobbyists, but now they make incredible focus on education which is a very solid direction. You have nothing to worry about.

    We're sailing steadily on the fore wind.

  • Most likely they will give everyone who already has subscription full access to Construct 4. So people can jump between Construct 3 & Construct 4 until one is stable enough so people can abandon Construct 3.

    Also there should be a very good reason for C3 to end! New engines aren't released for the sake of sequel. Construct Classic was like a proof of concept & Construct 2 a mature version of that concept. Construct 3 have taken that in the direction Scirra Team always was going for, solidified their ground.

    And now with a clear path ahead it is hard to imagine Construct 3 being replaced anytime soon.

    In my opinion the only reason for Construct 4 is expansion of Scirra Team which will allow them to finally have full 3D support. It will likely have two runtimes same as Construct 3 - Legacy 2D runtime & New 3D runtime.

    After some time support of 2D runtime will end, but it will be good enough so all C3 projects will be able to run on it.

  • This would go against the very reason of having containers in the first place.

    So as suggested, rendering object "invisible" & disabling collusions would be the best solution.

  • You should start using Families in your project, because you have too much repetetive code. It will simplify your work & make it far more manageable.

    If BonusStage events are included in Game events then it is likely there is a conflict between the two.

    For objects like this I would recommend to create a family, let's call it "Gateway" and include there sprites you want to use for such purpose. There in "Gateway" create a variable e.g "SendToLayout" and write there the name of the layout for each "Gateway" object.

    Example: Sprite "Bell" has in SendToLayout: "BonusStage"

    All you need to trigger this in events

    P.S You should probably disable Solid on object your character supposed to hit or make offset collusion if there is some good reason for it to remain solid.

    P.S.S Really advise to learn families. My "gateway" example is superficial use of the family. In fact, you could make all of your interactable object under one family with few extra variables.

  • applern

    mid((Browser.ExecJS("Date()")),3,13)

  • left((Browser.ExecJS("Date()")),16)

    This will retrieve first 16 symbols from the left side of the string which will show Day of the Week, Month, Day & Year.