Hi, not really. This would more likely be an idea submission, which I already did in the past and was rejected by Ashley. This addon exists as a non backwards compatible alternative for people who want that behavior anyway.
Great post with lots of super interesting insights.
I've always wondered how deep the rabbithole of your payment system went. It's always seemed pretty robust, and I'm very happy to learn more about it!
Can't wait to see the next posts in this series :)
Thanks, fixed
download the addon and install the addon before you try to open the project.
The addon can be downloaded with the "download now" button and if you do not know how to install the addon, read this manual entry construct.net/en/make-games/manuals/construct-3/tips-and-guides/installing-third-party-addons
Audio in the background is managed by the audio plugin and is unrelated to this addon
Ah that would make sense I have no idea what happens when a 3D camera is involved, chances are it doesn't even use the same draw method i'm overriding :/
It should work on any layer yeah, but I never tried 3D layers, so it might come with potential edge cases you'll need to look into.
To be fair, yes you do sound like a bot.
To reply to your original message: This course was written when JS in C3 was a fairly new feature. While I think it still does have some merit, I would not use that paradigm anymore.
JS in C3 is a lot more versatile than it used to be, and using the subclassing is almost never a good idea nowadays. Also, to be perfectly clear, this is specifically a suggestion on how to use JS in C3, not how to use JS in general. Having to compose with a game engine, a partially exposed runtime and a toolset makes it much different than if you were using exclusively JS.
Now, I still don't understand why you would call using classes "super-imposing OOP on top of JavaScript Prototypes", but whatever.
Why does your message sound like a bot wrote it? I can't tell if you're just trying to advertise your link or if you're actually being serious.
Hmm yeah I guess that's true for the project you're making. That's interesting to think about!
That's the case for your implementation, and I suppose that in a game where everything either moves in a straight line or does not move at all, I guess that makes sense.
In a more general context, I can't see why just sending the position as well with the delta updates would cause any issue.
I don't know how the MP plugin works, but since pretty much everything in Construct can save and load from JSON, I can definitely see how it would be doable to implement this as a general purpose layout synchronisation technique. Unless the performance hit from saving/loading JSONs in substantial that is. But in real case scenarios you'd only tag the objects you want to synchronise and that should work fine.
So when you join, the server sends the full state and from there it's only delta updates.
The way I see it, the actual implementation would be pretty close to the way git works when handling text file contents. But then just like git, you can run into merge conflicts but in practice these would be the same ones as a regular implementation.
What's preventing you from doing exclusively delta updates?
I haven't done complex/large scale network implementations in a while, but after studying the subject a whole lot, lately I've just realised that it might be doable to just take a purely data oriented approach and have the entire game sync up to a "game state" object that keeps info on absolutely everything in the game.
The whole game is drawn from reading that game state object and interacting with it sends events to the state manager to tell it what values to update.
The state manager can then just keep track of a buffer of changes, and send that over the network to every other party.
Fixed
Yes in the future. No date planned however sadly.
Member since 3 Aug, 2015
Sometimes I do some cool stuff in Construct. Sometimes I like to talk about it.