If what you're trying to do is create and edit a player's individual "sacrifice" bar during gameplay, you need to add PeerID's to the objects belonging to each player, add those values when they connect, and then pick, by comparison of their PeerID equal to that of the peer sending the message, them when you need to check or modify a value associated with that player's instance of the object.

Do the players have separate sacrifice bars?

Don't do this.

If you want to know how double jump is programmed, and how to design levels for it, you should play platformers. For example, MegaMan. I strongly suggest you play any MegaMan that has a double jump type of ability, of which there are quite a few. And any that use wall climb, as playing both will teach you about the importance of spatial awareness and level design in a platformer. Also, play Halo 5. I realize a lot of people don't like the new mechanics (because they don't play like a classic Halo game, and I agree), but they are VERY solid, and are a good reference for these things.

Remember, all of your abilities as a player are tools to interact with the world around you. If a player falls, then jumps again, that will extend the reach of a jump they might not have otherwise made. Additionally, you could add a ceiling and wall that covers a hole in the floor, where the player must fall, and use double jump to the right to avoid a pit of spikes below. This is a common little design that you'll find often in platformers, it will become second nature to some.

It being second nature, though, is why it's so important to get it right. Making such a big change must be clearly defined, and have a clear reason for existing.

Take Blitz Breaker (https://www.scirra.com/arcade/action-games/blitz-breaker-demo-3167) for example. This game doesn't allow you to run, and instead vault anywhere at anytime. It's a neat way to set up mechanics, is clearly defined and easy to grasp, and feels like it really makes the experience original and fun.

Ashley, Ah, thanks a lot, this answers all of my own, and other's, questions very well. I'd been in a discussion before where someone had told me that LocalStorage was loaded into RAM with the game, and memory limitations, it's good to know that this was incorrect.

I guess it would be practical for browsers to handle these things more efficiently than that, I just wanted to prevent getting far enough in my project that changing the data management method might cause problems, and instead make sure beyond a shadow of a doubt that it wouldn't become an issue.

As for my memory concerns in terms of performance it currently is actually almost a 1GB. Not a big concern, I'm just trying to maximize performance. I see some slowdown when running a lot of programs, and monitoring it shows that memory is the only thing that's really affected so far. I have 4GB of RAM.

Anyways, thanks for the help! I'll definitely be referring back to this if I see other's express this concern again.

Nested loops are something to avoid if you can.

Every tick doesn't slow the game down, as it doesn't actually do anything. The event would be the same if you removed that condition. "Every tick" functions as more of a title than an actual condition.

If your goal is performance, the only things you can really do to improve it is to optimize your code, with almost no redundancy, and loops only when necessary, and don't use big images. If your image looks too pixelized, use an effect to smooth it out. Memory is one of the biggest concerns, especially on mobile. Typically the processors and graphics chips on mobile devices are decent enough to handle a fair amount of processes and effects.

In reference to sharing variables/information between players, I'd create an invisible object that's created when a player joins (both Host and Peer), and is associated with that player. Each player's info/variables would be added to those objects. Additionally, to sync that information, just follow the multiplayer tutorial and sync objects, as well as their instance variables (similarly to how Input is synced in the examples).

For any text based data, you'll obviously want to send that as a message between the users. If I were you, I'd store each user's hand (deck) on the host's side, regardless of where it is seen. Store each user's hand/deck in an array. When a value on each changes, send that array to the peers. For example, if a card is added/removed from a players hand, send a message through Multiplayer "'UPDATE_HAND', *HandArray.AsJson*". Make an event for when that message is received, set the Peer's array to the JSON in the message.

If you have any trouble, let me know. I don't have Construct 3, so I can't open your project.

In the meantime, I've decided to roll with the NW/Phonegap method. I'll still be looking out for a crossplatform solution, though.

Ashley, this is a question directly for you, as I'm not super experienced in all the details of Javascript.

I have a couple of more advanced questions:

1. Does LocalStorage exist in RAM/Memory at all times when the webpage (game) is loaded up?

2. Do you know the current maximum size in bytes that LocalStorage is able to use in Chrome, NW, and Android?

3. Is there a more efficient, cross-platform, method of saving and loading data? (Locally, editting project files at runtime)

My project contains an editor that extends a lot of Construct2/3's base functionality, and I've made it so that I can import sprites/tilemaps and edit them within this new editor. The details of the editor itself are a bit complicated, but it's designed to allow the user to export the project, import it back into C2/3, change a variable, and export the game from Construct.

The editor is organized by grouping Objects (using instances of a single object with multiple behaviors, with extra code within the Editor project to add functionality), 3D info (using Q3D), Sounds, Music, etc. in a Map, which is then loaded through a custom scripting interface on demand (Set up this way for level streaming, like UE's), therefore allowing the user to choose when and what information is using memory.

If the editor were designed specifically for game projects, this would probably actually work, as maps could be saved as separate files within Project Files, and later loaded on demand using AJAX. This isn't the case though, as the project is built to allow for instant switching between Editor and Runtime modes by command, as well as limiting control in the editor to allow players to create Maps, "Missions" (as they're called in my game, they're just story segments), etc. for the game and share them online.

Now, as you can see, the concern when using LocalStorage would be the amount of RAM used, if at all, both in the fact that a limit apparently exists and in the possibility of slowing down the game. The possibility that a project wouldn't reach the supposed 5MB or 12 MB limit?1 is slim to none, given all the information that exists within a single project (Storyboard and cinematic info, code, sprites/tilemaps, etc.).

On both PC and Android, I could devise a method for each that uses NW/Phonegap to write to a file that references the projects/maps that have been created, but obviously this method only works for PC and Phonegap compatible platforms. My goal is to hopefully port my game to both Xbox One and Nintendo Switch (When they decide to open up the Webkit for development) and have map creation available on those platforms as well.

So, after this far too long post, my question is, does a solution for this exist?

EDIT: Something I hadn't considered is the fact that cross-platform play is becoming a norm now. If a solution to this didn't exist, it'd be fine. Most people have mobile devices, and though it'd be a bit annoying to have to build mods for the game on a different platform, the base game (modding and multiplayer) is free. Annoying, maybe, but I doubt many gamers would complain about this.

Sources:

1. https://stackoverflow.com/questions/7267354/javascript-memory-and-html5-localstorage-limitations-on-smartphones

brunopalermo, nah, it's all good, I was wrong and arrogant.

brunopalermo, Ah, I see. Regardless, Ashley added to the manual to explain that the upper bound is exclusive.

AmpedRobot, in regard to your last post, did you say that you're using "is between 0 and 271" or "is between 0 and 270"? If so, that would be redundant.

If you use both these conditions, the result will be the same as if you'd only used "is between 0 and 271".

If what you want is to lock the angle at 270 or 90, just add round() to where you're setting the angle of movement.

AmpedRobot, I'd suggest not trolling the forums. Regardless, here is the official explanation for why this was made the way it was, given by Ashley: https://www.scirra.com/forum/viewtopic.php?f=151&t=196944&p=1145722&sid=82f00f8702353c836fae08ae9b337140#p1145722

dop2000, you were correct.