oosyrag's Forum Posts

  • Steam Deck will be running SteamOS, which is Linux based. So Linux nw.JS builds will already work and are supported.

    Edit: Windows builds should also work fine via Proton, which is also supported.

  • Your peer group events do not assign the peer object a peerID.

    So event 21 never runs, because there are no peers that have PeerID=Multiplayer.MyID.

  • I imagine you can. The Bluetooth plugin looks like it allows you to establish Bluetooth connectivity and send binary data, which should be all you need. How to implement is beyond me though.

  • You're setting the same bit of Peer.Touch to 1 regardless of if you are in touch or not in touch.

  • You can add the line of sight behavior to your player sprite object or the shadow light object. Use it to check if one has line of sight to the other. If it does then it isn't in a shadow.

  • Place the sprites that are causing the slowdown on your welcome layout. If they are used in both the current layout and next layout, they won't be unloaded and reloaded into memory.

    The slowdown will occur before the welcome layout instead, or a loader layout if you like.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Put the shadows above the object and use a blend mode.

    Edit: Misread your question. You can also use line of sight from your light source coordinates to determine if your object is in a shadow or not.

  • A single large image is not an issue, especially for a loading screen, since it wouldn't need to be kept in memory after that anyway.

  • How do you know how much VRAM Brawlstars is using? And how do you know that the loading screen image is originally 4k and not simply scaled?

    Also as Newt mentioned, Brawlstars is a 3D game. Objects are drawn at runtime, and not loaded from an image. From what I can see, many objects are simply colored in, which doesn't require a texture image at all.

  • The memory footprint of images goes up exponentially as they get larger. A 100x100 image has 10,000 pixels, while a 1000x1000 image has 1,000,000 pixels.

    Note that for mobile devices especially, even though the resolution on modern devices is as high as monitors, the dpi density is also much higher. Basically even though it is high resolution, the physical screen size is still very very small. You can use much lower resolution textures, with scaling, and it will be much harder for an eye to discern the difference on a mobile screen versus a monitor, even if both the monitor and mobile device have similar resolutions.

    To further optimize, similar texturing techniques to 3d can be done in 2d with repeating backgrounds and the canvas plugin (optionally with effects as shaders). Use the canvas plugin to draw the shape, and layered repeating backgrounds to texture large areas of it.

    Edit: As with tiled backgrounds, by extension the 9-patch object can also be used in certain situations to lower memory use significantly.

    More traditionally, 2d games make very heavy use of tilemaps to reuse a set of textures over large areas. When that is still not enough, different tilesets assets are loaded and unloaded as needed (via layouts in Construct). This is usually done when areas don't have much in common and assets can't be easily reused or shared between the two, such as different biomes.

    Note that tilemaps are not only useful for terrain. With a little creativity, they can be applied in other situations as well.

  • Pick a random point near the player to move to instead of directly on the player. Use for each, so they don't all move to the same random location.

    For each enemy, move to player.x+random(-100,100), player.y+random(-100,100)

  • Force own texture on a layer will prevent blend modes from affecting anything on other layers below it.

  • The things that stood out to me include abrupt change in speed (instant deceleration) upon jumping, complete lack of bouncing when hitting flat surfaces, and staying in place on the circles, even when clearly off center.

    If you're looking to go the physics route, I would look into pinball examples and mechanics.

  • I recommend using invisible helper sprites on either side of your main sprite. Upon pressing a direction, the respective helper sprite gets "activated". If the helper sprite is in activated state and not overlapping a wall, then apply the "turn".

  • I was intrigued so I downloaded the game. I'm almost certain there is no physics involved. I would treat it more like a Sonic style platformer instead, with slope sensors (you can use the line of sight ray cast feature) on either side to determine acceleration.