Hello there,

I'm experimenting the z sort in order to make a quick isometric demo. I basically want to sort the order of each object inside a family depending on the Y.

I have done a part of it, however, I have some problem with the logic of the events. Basically, each player has 3 sprites (player skin, weapon, cape) where weapon is on top of the player, and the cape is behind. What I want is that if the player is above another element of the family, then all the elements of the player should be on top of the other player/object, otherwise should be the opposite. This can be tricky since the cape and the weapon should sort accordingly to the parent player.

I can sort the players, but the items do not sort well. Also, the sorting of the family doesn't work properly.

Does anyone have any experience with isometric games? Here the file I'm trying to make it work.

http://www.feribi.com/sort_problem.c3p

Thanks!

among us is not peer to peer

you can reconnect if the host leaves in the multiplayer plugin, just make sure to store the game state on each peer, when a host disconnects, connect to a room of the same name, everyone else in the game does the same, one of the players will become host, players never lost connection to the signalling server so they preserved their multiplayer ID, assign the objects to the respective players by playerID by having the player ID stored in them. If you keep player inputs the same and keep the game loop running for everyone while this is happening they might not realise it even happened.

bottom line is photon is easier to use but has less features, worse ping, is limited to blocking websockets traffic, 16 players per room limit, and is way more expensive at 0.05$ per both Egress and Ingress GB

for comparaison, "high tier" infrastructure like google cloud or aws go for around 0.12$ to 0.15$ for the first few Egress TB per month (ingress is free), while more budget friendly providers like vultr or digitalocean charge 0.01$ per Egress GB (ingress is free) and keep in mind that you won't be charged for most of the bandwidth since it's peer to peer.

nodejs exports for running multiplayer game instances headless were promised with the release of construct 3 a while ago, but might not come to fruition for a long time since scirra says that there is very low adoption of the multiplayer plugin so uh here'S a project to get you started i guess drive.google.com/file/d/1FmEtzZJt_18EVaAoL5sBFS6h69xCr1OD/view

I have heard that among us is peer to peer. They have been having huge issue with cheater, and is well known that in peer to peer is easier to cheat since the host can change the stuff.

— Constructorr Do you have any suggestion on how to approach the multiplayer logic? How would you explain how to develop the events logic to someone who is already really familiar with Construct? I'm about to start working on a small project that would allow a player to move in a scenario and solve some puzzles. But I would need to implement the multiplayer at some point. Is it possible to start the project and then implement the multiplayer? or do you suggest to implement the multiplayer at the beggining?

Thanks

Hey friend! Thank you so much for your anser!! I apologize for answering so late. Could you explain me how I get it with global variable step by step, please? I have not made it yet. Thank you!!

if you need to restart the level and respawn all the objects in their initial state, you have two options:

Make a variable that keep track of the checkpoint status. For example, the ID of the checkpoint sprite. If the player touch the checkpoint, set the ID to the variable. When the player dies, make an event that on restart level, the player will be set at the ID checkpoint X,Y.

Another way to do it, is to use the save/load as you already doing, adding the behavior "No Save" to the objects you don't want to safe. This one should work, even if I never tried it.

I appreciate your time Ashley, but honestly that was not helpful, nor did it answer my question.

> For example playing Pokemon Go made my Android phone get pretty warm (and that of course was not made in Construct)

I was never blaming Construct 3 for the device heat up, and yes I do expect some games could warm up a device. But in my case, it's literally extreme heat up within 1 minute of play. I already acknowledged the inefficiencies in my methods that's probably causing the massive heat up. Shouldn't I work towards making it better? maybe end up to heat up half as much?

If yes, then I would appreciate a more specific response, especially from you, from the list of possibilities above (and profiler/inspector charts) on which of these could be more related to heating up, than the other.

Unless, it is "None" of them could be related to heating up, and optimizing any of those would not help. But you didn't also mention that statement, so I am still confused if there is or not anything I should do.

Thanks!

Make an empty project and check if the phone warms up or it get too hot. I had the same problem years ago making a mobile game with Construct2, but now it seems that the problem is solved.

If the phone get the same result with the empty project, it might be a "problem" with the devices that you have used for testing.

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

I think it's more likely that what you propose will make things worse, not better. Either the developers or the players will be likely to mis-configure the option, and then the situation is worse than it was to begin with.

We can already publish the game with unlimited frame rate mode. I read on the forum that even someone is using it to make sure that the app run smoother in all devices.

The phone isn't going to explode. So I don't see all these problems. When you encounter a player with diver issues there is already a bad situation. You said that the Construct3 team can't do anything about it, but you could actually do something.

As I said, I did a test. the game was running at 25/35fps in a device (totally unplayable). I tried to use the unlimited frame rate and the game was run much smoother (50/60). Still, I have to blacklist that device because I don't want to publish my app as unlimited frame rate since my game it runs smooth in most devices.

So, if it is an easy implementation to do it you will make just the developers happy. I also think that it would be helpful if we want to debug stuff in real time.

For the record, since the introduction of WebGL in 2011, Construct games have rendered almost identically to native games. WebGL is basically OpenGL exposed to the web. So it's basically using the same rendering API as any other native game using OpenGL. (With WebGPU, this analogy will continue, but being more or less equivalent to the next generation Vulkan/Metal/DX12 APIs.)

The main difference introduced by browsers is the driver blacklist. There are many poor quality drivers out there. These can crash and glitch and ruin games. This is a serious problem faced by many native engines. There is little anyone can do about it. Sadly the state of graphics drivers continues to be poor. (Hopefully the next generation APIs help with this, since they allow the drivers to be much simpler.) Browsers blacklist known bad drivers so you get software rendering instead. This means the game runs correctly, but slowly.

So barring some kind of obscure browser bug we don't know about yet, the only explanation seems to be the graphics drivers. These are still a problem no matter which technology you use. You may find that when using some other game engine, it seems to be faster, but then you later run in to the crashes and glitches that the browser makers were trying to avoid. This can cause even worse problems, such as the game crashing or just showing a black screen on various types of Android devices.

So while you may claim that Android performance sucks, I think really this is just driver blacklisting on a small number of devices for a good reason. It's a matter of picking your poison - do you want software rendering or the risk of crashes and glitches? I think the former is the right choice.

Changing the framerate mode will only make this worse. It doesn't make anything faster, it only changes when frames are scheduled. Unlimited framerate mode will allow powerful devices to run up in to the hundreds, or even thousands, of frames per second, promptly drain the battery, and earn you poor reviews.

I completely understand the frustration with the drivers. I'm so far happy with the performance of Construct3, and most of the performance issue depends on how the events and how much we push the cpu itself. Today my friend tried again the game with Adreno 618 and strangely after one month it runs 60fps with no problem. Maybe the phone did some updates and now it works as excepted.

Ashley, would you consider to allow us to switch the framerate mode in realtime? I have actually did some test with it and I confirm that in some old devices if we enable the unlimited fps the game does run smoother (from 45 to 65 for example). So, it could be a possible solution for slower device. If we detect really low fps for too long we could switch framerate and push a little bit harder the CPU right?

I wouldn't concern about the battery issue. There are plenty of game that drain out the battery even while you charge the phone. These would be limited only in old phone I guess

RibisI had a test version on google play, but google censored me for the murderer boy scene ... (now he's a 21-year-old fat guy ...)

Lol. You can published ad internal tester so that I don't think they can't censored it until you published it. Message me at Ribis#7413 on discord, I would like to test it on my device. Also I think you need to specify the audience target at the beggining?