I've seen some examples for ladders that swap from the platforming behaviour to the 8 direction behaviour ( set to up/down only ) when a ladder is activated. You could do something similar, but by having an invisible climbing surface on the edge of the wall.

Render cells are an optimisation that makes it easy for the engine to tell if an object is on screen, and only draw it if it's on screen. They only affect drawing though. Things like behaviours and events need to be applied even if the instance is offscreen, otherwise you would have unpleasant side effects.

The exact effect that behaviours have depend very much on what they do. When disabled the Pin behaviour doesn't actually tick. So it doesn't have any cost. DragDrop only updates during a pointer event ( mouse down, touch start, etc. ) so it's not directly related to ticks. Disabled DragDrop behaviours are ignored during the pointer events, so the cost is pretty negligible.

PixelImpact The main advantage of Google App signing is that the main key is held safely by Google, meaning you cannot lose it or have it stolen and compromised by a malicious 3rd party.

Normally when you sign an application you are basically saying that you made it. Whatever system runs your application can see if it's been tampered with, and decide not to run it as well. Unless someone has your key and passwords they cannot sign as if it was you.

In the Android ecosystem you sign the APK and it goes unmodified until it reaches the user, so the users device can tell you signed it. If the key changes then neither the store or the user can confirm that you created the APK, so it's considered invalid.

The Google App signing changes this. You sign the APK, and the store verifies that it was you that signed it. Then the store signs it with a different key it holds securely. The end user only ever sees the last key. This means if you need to use a new key, you can securely tell Google your using a new one and to not trust the older one anymore. Users don't see any difference.

There is a second reason to do this. If you decide to use the newer Android App Bundle (AAB) format you need to use app signing with it. The reason being that AAB files are like a half built APK. The store decides what parts of the AAB are needed by the user, then creates an APK from those parts and signs it with the key.

I don't believe you can swap to using Google App Signing once you've published an app, because the users device would not recognise the signature. But I haven't read into it much.

Ah so psuedo code is a term used by programmers. It's demonstrating roughly how an algorithm works using a fake programming language which is easy to understand. But unless you know a written programming language your unlikely to understand it unfortunately.

Yes you would want arrays for this, one per "chunk" to hold a list of lights in that chunk. Then I'd use a separate dictionary which is used for finding the array for each chunk.

It probably wouldn't be that quick for me to implement something like this unfortunately, so I can't really send you an example made it Construct right now.

Well most of what I know is theory, I'm part way through implementing it for Wings but that is all 3D and written in JavaScript, so it's not apples to apples really. I basically just have the Ambient Occlusion effect at the moment.

I did make the procedural terrain generation example which covers some of these concepts. It stores data for chunks by packing tile data into a JSON object, converting that to a string then placing it in a Dictionary. The Dictionary being keyed with the location of the chunk.

There's plenty of room for optimising that project and tweaking other stuff, it was mostly meant to show off the ideas.

If you want I can give you some psuedo code for it. But some experience reading code would probably be required? Not sure what your background is, quite a few construct users would struggle with psuedo code.

Maybe Scirra or even a third-party developer could create something like 'spill lighting.'

In practise this style of lighting is VERY specific to this kind of game, and generally quite closely linked to how your game works. The only reason why I know so much about it is because I've been doing research into voxel lighting techniques for my own game project.

Well the simple option would be to use the inbuilt shadow lights.

As for a more complicated solution:

The first thing that comes to mind is for each tile find every nearby light, calculate the distance then pick the shortest distance.

If your game has less than 10 lights then this is fine, the cost is minimal. If your going to allow the users to place lights... Well you could have 10 thousand plus it's going to run slowly. So how to speed it up?

First optimisation is to use the Manhattan distance instead of Pythagoras. Much faster, but it's visually quite different ( diamonds not circles ). This normally suits tile/voxel based games though.

Second trick is spatial partitioning. If the maximum range of a light is 8 tiles, then split the world up into 8x8 chunks. When you need to look for nearby lights you only need to check the current chunk and it's immediate neighbours. This makes for a worst case of 575 lights to check, instead of the whole world, and finding the lights is pretty simple.

If you want to simulate sunlight then a good trick is treat every tile that has no obstruction above it as a light source. This gives you an approximation of indirect illumination for sunlight, which is nice.

You should only be updating these light values if the world changes, not every tick. If you use spatial partitioning then it's easy enough to update the 9 chunks centered around the changed tile which could be affected. For sunlight it's a little more fiddly unfortunately...

There is another trick you can do which improves the quality of your lighting, but I'm not sure how you'd manage it in Construct. Basically the trick is to calculate light for the corners of tiles instead, then interpolate it across the tile to give you smooth lighting changes. If you make solids completely dark then this will also give you an Ambient Occlusion effect.

Thank you for the feedback, we will update the documentation with the missing parts. Some ACEs available in the beta will not yet be added, as we have a policy of not adding features to the documentation until they are included in a stable release.

The documentation does include a mention that the privacy policy is required during the guide section, as well as a brief description of "Is configured" but not in the description for the property. Which will be resolved.

Before using adverts inside your game you need to specify your application ID, publisher ID and a privacy policy URL on the Mobile Advert object. Without these values the plugin will not be able to start. If you do not have a privacy policy yet then you can place a filler website address in it's place, but this should be replaced with your actual privacy policy before you release your game.

The plugin will be automatically be configured and ready to go as soon as your game starts. You may want to check the "Is configured" condition in your game to see if configuration failed for any reason; such as being on an invalid platform or one of your properties being incorrect.

I'm afraid using Google Drive with Construct is limited to "general access".

Google Drive supports an "app mode" which restricts the application to a single folder, but unfortunately then users cannot see or access any of the files the application creates on their account. We decided during development of cloud save that users should be able to have access to their projects without needing to use Construct. Hence we went with the only alternative which Google offers, which is "general access".

If you don't wish to give this level of access to Construct then I generally advise users to use Dropbox instead. We use their equivalent of "app mode", as it does allow users to access the files as well as limiting what the application can access.

— this thread is talking about the new feature added in todays beta release which allows you to disable the collisions on a per tile basis in a tilemap. Which means you don't have to have a separate invisible tilemap for collisions anymore. Although that approach does allow for additional flexibility in how your collisions behave at runtime.

newt you could always have 2 copies of each tile, one with collisions disabled. I would have thought normally you'd want to change the visual aspect of a tile if it went from solid to passable. Even if you didn't this would give you the flexibility to do it later if you wanted.

Ensure you have the tilemap bar open, the select the tilemap you want to edit. Double click the tile you wish to edit. On the right hand side a properties bar should be visible with a single check box "Use collision" untick it.