oosyrag's Forum Posts

  • Use the Multiplayer - Add ICE server action.

    Add ICE server

    Add a custom Interactive Connectivity Establishment (ICE) server used by WebRTC to establish connections between peers. There are a couple of built-in public STUN servers used, but you can also provide your own TURN servers to enable connectivity through certain kinds of NAT. A username and credential can also be optionally provided if the server requires them.

    An ICE server is a blanket term for both STUN and TURN servers.

    You want to put this action before connecting to signaling server.

  • Everything you need to know:

    construct.net/en/tutorials/supporting-multiple-screen-17

    construct.net/en/tutorials/supporting-multiple-screen-17/handling-multiple-aspect-2

    In summary, you generally don't need to worry about resolution at all, full screen scaling will take care of that for you. There are too many resolutions to target. Note that some phones have higher resolution than pc monitors!

    What you do need to take into account and design for is different aspect ratios, by dynamically positioning your static hud elements, and also deciding what parts of your layout/background are acceptable to either get cut off or show extra of.

  • Just gonna chime in again, all the advice above is good, but I wouldn't put too much weight on 8/9/10... You can go try, but in my opinion it shouldn't make a huge difference. I especially wouldn't recommend going out of your way to chop up your event sheets into arbitrary numbers of events with hard limits, more so if readability and organization are sacrificed.

    On the other hand, if it does help readability and organization, refactoring is absolutely a good idea.

    Specifically for performance though, as I mentioned before, keep an eye out for inefficient loops and things that run every frame that don't need to run every frame by using triggers instead (#1 in George's list).

  • No, it should not be solid and be exactly the same width as the main, solid collision box.

    If it is wider, then you'll run into collisions when approaching from the side. If it is narrower, then the main collision box has a tiny section it can get stuck on from above.

  • For your collision box, add an additional 1 px collision box at the base of it. If this one overlaps the normal one (someone is standing on top of someone else), it pushes one or both rapidly off to a side until it is no longer overlapping.

    If you don't want to use two separate boxes, you can also use is overlapping at offset condition to check below.

    game.capcom.com/cfn/sfv/column/131422

  • I vaguely recall something about music or sound playing will prevent tab suspension.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • Also, why do you use full 1080p background in a mobile phone? I'm just curious.

    Many flagship phone have higher than 1080 resolution. The OnePlus 7 pro is 1440 x 3120 (the normal OnePlus 7 is 1080), with a 90hz refresh. Games that let me turn on high framerate mode definitely heat up my phone more than those that don't.

  • Numerous collision events (20+ Physics objects, only two of them moving)

    This could be an issue, but the numbers don't look very large to me.

    High-resolution sprites! 40+ of them! (max is the background 1080p)

    This is more a memory issue, probably not related to cpu/gpu heat.

    600+ Events (not grouped, all of them in 1 layout/event-sheet) and 30+ global variables

    The number of events is unlikely to be an issue, but certain events like long running loops can be. Also limit the number of events that run every tick, and turn pretty much everything you can into triggered events. Updating text every tick can be particularly painful.

    Layout size: 15300 x 1480 (however, scroll-to enabled with viewport of 1920x1080/scale outer)

    I don't think this would cause any issues.

    Other possible factors: Layer Scaling (not constantly), Time-scale set to 1.5, Photon plugin?

    Unlikely, but you can test each of these individually pretty easily.

    Also how is your game running at 120 fps? Thought it was capped at 60, unless I missed an update somewhere. Maybe your phone is a high fps device as well. I don't recall if there was a way to limit it, but this popped up in a quick search that might be worth trying. construct.net/en/tutorials/limit-framerate-build-fps-1381

    Otherwise, its probably mostly up to you to isolate certain things you think may be causing high usage and test and test and test again.

  • You can mix saving methods if you're careful about it.

    In your example, you can save your settings separately from the game state by writing to localstorage upon applying changes. Then just load those settings after using the system-load action when continuing.

  • In the animation editor, click the bottom most button on the left "Edit the collision polygon".

    I recommend right clicking and using the "Set to bouding box" option, on both of the frames.

  • It has to do with your collision polygon changing in between frames, so as he's walking, it triggers the collision event with the edge object again when the frame changes. He doesn't move fast enough to get his collision polygon out of the way before the next tick.

  • Use a bullet behavior.

    Set angle towards player.x, player.y

  • You do not have permission to view this post