Hi wolf7,

quite often the Construct 2 tutorials will be fine to follow in Construct 3. However, you are likely to find some changes, often differences in user interface.

As your new to Construct, and multiplayer is quite a complex topic, I would advise you to at least complete a couple of Construct 3 tutorials first. This will help you get a feel for how Construct works, and hopefully if you find something that doesn't match up in the C2 tutorials you will know how to work around it.

You may also find it useful to look at the multiplayer example projects, you can find them under the "advanced examples" tab on the start page.

You might want to check out Ash's post about optimising events with function binding, he talks about a strategy used in the expression compiler for constants.

https://www.construct.net/en/blogs/ashleys-blog-2/optimising-events-with-function-binding-964

This might be a little processing intensive but you could do it with cellular automaton. There's an interesting article at http://www.jgallant.com/2d-liquid-simulator-with-cellular-automaton-in-unity/ where they simulate water, including things like pressure and gravity. I've been meaning to try it out in construct for awhile. If you ignored the gravity sections (or limited it somehow) it would give you a gas simulation. This is how the old "falling sand" games worked.

I imagine this could be done by with 2 2D arrays ( or a 3D array with a depth of 2 ). You read from one array, apply the rules then write to the second. You can then apply that to a tilemap. On the next simulation tick you swap the 2 arrays over. The swapping trick is so that you don't modify the data you are reading from.

Another method is that you could have a number of "gas" sprites that are both attracted and repelled by each other ( based on distance ). The attraction will hold them loosely together, but the repulsion will cause the gas to expand. I haven't read into this too much but there is a method here https://peeke.nl/simulating-blobs-of-fluid

As Psynaptik says you can use the tween plugin, which is pretty easy. Create a white sprite and set it's color property to red, add the tween behaviour to it and then add a tween single property action ( property: color, value: yellow, duration: 5 seconds, etc. ).

Alternatively if you want to manually control each color step you can use gradients from the AdvancedRandom plugin. Define a gradient with color stops (0: red, 10: yellow). Keeping a variable as a counter, each time you want to take a color step increase the counter then use the AdvancedRandom.Gradient method with the counter to sample from the gradient and set the sprites color property. You can use that technique for more complicated color gradients as well, but the transition is always linear ( unlike the tween plugin ).

You can read about the tween plugin in the documentation here https://www.construct.net/en/make-games/manuals/construct-3/behavior-reference/tween

For more information on color gradients check out the tutorial I wrote about the AdvancedRandom plugin here

https://www.construct.net/en/tutorials/getting-started-with-the-advanced-random-plugin-30 the section on color gradients is towards the end.

If you just want to perform an operation with 2 parameters it's pretty easy, have the 2 parameters as number variables and the operator as a string variable. Then create a function per operator, called something like "operator_+". Then when you want to execute an operation call the function "operator_" & opString with the 2 parameter variables.

Here's an example with live evaluation

Doing something more complicated than that, say taking a piece of text containing any number of operations then it's going to be a pain. You could potentially just execjs like R0J0hound says, but it's a bit of a security risk ( users could evaluate anything... ). You would need a proper expression parser, like what R0J0hound implemented in his calculator project ( which is super impressive BTW ). But that's probably way more complicated than you were hoping. It requires breaking a piece of text into tokens, then creating a recursive parser that respects the precedence of your operators.

You might be able to implement reverse polish notation instead, which would be simpler to evalutate but users wouldn't understand it. The simplest correct option ( if you know JS ) is to write a small plugin that evaluates a string and returns the output value.

Now that the C3 runtime is properly released we're trying to increase the frequency on Stable releases. So hopefully you won't be missing out on new features for too long by staying on the stable channel.

Saying that, it is appreciated having more users on the beta channel. We're trying to wind up to stable release right now so if you hadn't noticed this it would have probably got into the next stable!

It depends on the included libraries, if you export a barebones project ( Space blaster for instance ) it only includes Java code, which compiles to a single DEX file. DEX is an architecture independent bytecode, so that project will work on any Android device. Only APKs which include "native" libraries will be architecture dependant, and I'm not aware of any first party plugins which include those. Same rule applies for third party plugins.

So I believe we're fine. I might do some more reading on the subject though.

Thanks for letting me know LuisCGForte I will check this out. For future reference it's better to file issues on GitHub when you find a problem.

Construct stores several types of data locally, mostly in indexeddb ( which for the uninitiated is persistent database managed by the browser that is saved locally on the computer/tablet/phone ).

1. Itself: Construct caches the files to run itself locally so that it can run offline, which typically doesn't take up that much space. I believe we cache the last 5 versions that you have visited, but Ash will have to confirm that
2. Demo projects: the projects that you can view on the start page are downloaded and stored in indexeddb as required.
3. Browser saves: when you save to "the browser" it goes in indexeddb
4. Recent exports: recent exports are viewable in the export manager and are saved in local storage, up to 10 exports are held and the oldest is deleted if you have more
5. NWJS files: when doing NWJS exports the files required to build that version are downloaded and stored in indexeddb. These are quite large, so it makes sense to store them locally instead of downloading them each time.
6. Layout: in construct layout customisation is split into 2 parts: overall and project. The overall layout ( sizes of bars and positions ) is stored in local storage, project is stored in the project file itself.
7. Recent projects: a list of recent projects and where they are saved is stored locally, so we can show you the recent project menu

Just to reiterate all this data is stored locally on your computer so we have no access to it. Most of the large things on the list (NWJS files, recent exports, Browsers saves) have menus you can view them, how much space they are using and have options to delete individual items. Hopefully this will help you narrow down what is using all that space. You can also clear the layout customisation in the settings menu, but that is unlikely to regain you any space.

We don't directly move objects to the disk as any sort of optimisation, but we make heavy use of "Blob" objects. Blobs are similar to files, but just loose ( not in folders or any kind of filesystem ). Due to the way they are designed the contents of the blob don't have to be in RAM, so some browsers may transfer blobs (temporarily) that aren't being actively used to the disk to reduce memory pressure. We don't have any control over this process, but I imagine it's unlikely to cause any storage issues. It also won't be included in the storage quota for a domain, or be deleted when you use "clear site data".