oosyrag's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.

  • I use C2 regularly on my Surface Pro 3. It is far from the best in terms of usability, but it does get a lot of use simply due to how portable it is, while still running Windows. I do use a Bluetooth mouse, as I can't stand trackpads and I was unable to get away with touchscreen/pen only (the pen is definitely nice for making quick placeholder doodles though!). The keyboard cover is both good and bad - it isn't a "great" keyboard and can be floppy and awkward in certain positions, but the simple fact that it IS a physical keyboard beats an OSK by far.

    In general I was less inclined to pull a traditional laptop out in many situations as I would a tablet, like waiting for a kid to get out of class. It is great for the random idea I got in my head I want to try out or jot some notes down, but for serious production mode it will never beat a desktop. Seated at a desk with peripherals such as mouse keyboard and monitor I'd say it is more or less equivalent to any other laptop.

  • Local storage (and the save behavior) is indeed stored in the browsers app cache, so it will be possible to be wiped manually. This is normal and fairly common, such as on many phone games if you wipe the app cache, it will be reset as if you just installed it.

    You'll need a cloud service or some sort of web data storage to back up away from the users device if that is your intention.