oosyrag's Forum Posts

  • You need to set the array size in the array properties. Anything outside the bounds of the array will be 0. Either have the size large enough to fit all your values, or use the "push" action to add array cells as you add values.

  • Use multiple sprites, optionally in a container or pinned.

  • Rather than a concern, its more that it allows you more flexibility to include more art if you want. For example, if you're using the same tiles for battles and overworld anyway, it doesn't make make much sense to change layouts.

    If you wanted a lot of different tilesets/environments, you could do a low resolution overworld tileset that includes a lot of variety such as forest, snow, desert, water, ect. and then a more detailed tileset for each of those zones for a zoomed in map that you would load in layouts as needed.

    The other example was characters - if you wanted high resolution art or heavily animated enemies ect, it would make sense to load them as needed in a separate layout rather than have all your enemies loaded in memory all the time, limiting your memory use for other things.

    If you don't expect to run into memory issues, then you probably could stick with just leaving everything on one layout =) Just wanting to chime in as it is pretty normal for JRPGs to load into and out of battles or changing zones, which would be the equivalent of changing layouts for us. It is usually because all the art they want to use in the entire game can't be loaded into memory all at the same time.

  • Using layouts will allow you to utilize memory much more effectively. You will have more room for detailed sprites when zoomed in and a greater variety of high quality images in any given area. Or you could use it to have more quality character graphics and animations.

  • You would normally use a third party program to do screen recording and sharing. Sine examples include Nvidia shadowplay, amd relive, plays.tv, fraps, OBS... There are many options.

  • You can use an invisible helper sprite - a horizontal line. If it overlaps with a block at rest, move it up. The distance between the line and the floor is the height of your tower.

  • You can do that, or add an event that disables it for peers.

    Then you need to sync the objects created by the generation algorithm.

  • Sorry, I can try my best to answer any specific questions you might have, but I will not be able to work on your project for you.

  • A simple way to get a collision point for a fast moving object is to stretch an invisible helper object (a line) from the previous position to the current position (or ahead, but that would be slightly more complicated). On the frame that the line collides with an obstacle , you shrink the line backwards towards the origin until it is no longer colliding, and reposition the fast moving object to the front of the line (with an imagepoint).

    This is called raycasting if you want to search and look into it more.

  • Your dungeon generation is being run on both host and peer side. Given that it is randomly generated, your host will have a random dungeon, and your peer will have a different random dungeon.

    You should have only the host create the dungeon, and sync or send all necessary objects and data to the peers so that they can have the same one.

  • Well one of the main advantages with construct/html5 is that you can at least be pretty confident in the consistency in behavior across platforms, if not performance or packaging process.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • For a phone app, it is separate from their browser app cache. They would need to go into settings, app setting, your app name, delete cache, and confirm.

    If they access your game through a web browser though, then deleting the cache for that browser will delete the data.

    Most well developed games (I believe) use both systems. For example, popular gatcha/lottery games like Puzzle and Dragons will store user data locally in the cache, and allow you to register an account to back up your data online. This is usually taken advantage by users who want to "reroll" their starting character, by not registering until they get their desired roll. They do this by clearing their cache to reset the game, and get another free roll from the tutorial or something like that.

  • Found an old example I made for something different, but may be of use to you.

    https://www.dropbox.com/s/8ete5kjdcjanz ... .capx?dl=0

  • I'd say there are many cases that use both methods, rather than saying everyone saves on a server or local cache only.

    Generally speaking, local cache is pretty reliable. The user has to go out of their way to delete it, and if they know how to do that then they should understand the ramifications as well.

    Regarding cloud storage, there are different levels of solutions for that as well. You could build an entire database server with a firebase backend for your app, or you could use Google Play Services, which will store at least high scores for your app just fine.

  • Hi dop,

    I can't give you a full solution, but I can offer some improvements. (I'm pretty much a physics newbie too)

    The resting on the floor problem can be improved greatly by using the native size of your floor object, rather than stretching it at runtime, due to rounding errors.

    The janky movement when dragging is caused by using a non physics method of moving around the object. As mentioned on the manual page, this is normally not recommended (drag and drop can't take into account collisions and center of gravity rotations ect, so the two behaviors will fight each other to position the object).

    I'm not sure whats going on with the two boxes resting on each other. Again try to make sure that the native size of the object matches what is placed in the layout editor to minimize rounding errors, although this didn't seem to help in this particular example.