As for the lighting method I propose, well, I left this vague on purpose, because I don't really know how it should work ! It will depend on the technology that will be used for the Lighting system, I am sure it has to be something more complicated than drawing and overlaying some shaded polygons, since it will have to respect multiple light sources that in return should interact with other light's shadows. And it should be fast! I'm thinking that you should be able to lit an entire level just with lights!

I have no idea what libraries can do that, so I don't know how they will work, blend together or whatever they might have to do. What I wanted to depict is the workflow and how lights should affect other light's shadows and bump-mapping, with just a few clicks.

Well, in my mind blending modes gives the user freedom whether the individual Shadow Lights should be screened or added (dodged), hence why the user should be able to turn the Shadow Light effect opaque.

With the tests I have made I reached the conclusion that screening individual lights looks best, since (I think) we're dealing with 8-bit rendering here. In the real world, light is additive, but that would require a floating point rendering rather than 8 or 16-bit colour depth. Floating colour for this kind of engine is way overkill, so I don't feel it is necessary. And Add-blending tends to create ugly blobs when two light sources are mixed together. Yet the user should have the freedom to choose what to make of the effect.

This is a gif of the simple test I did with the lighting.

imgur.com/Mojlpsn

It is created with the same methods described by Ashley in the lighting tutorial. Although I am stuck with a limited number of lights, this is four dynamic lights with the demo running smoothly. I think this principle can hold at least ten lights at once on my regular laptop, I haven't tested it though, but using blending modes feels quite fast. And since I have a background in compositing, using blending modes for lighting feels very logical.

I am no programmer though, so I really don't know if it's more efficient to blend these lights using alpha channel.

But I do agree that AE's layer system provides both goods and bads. It's fast, but the flow of things are restricted by the layer order.

To be honest, I don’t really get how those nested layers could work with lighting, I’m not familiar with the term (I guess they are something like layers within a group like in Photoshop?)

You are correct, nested means "layer within layer" basically.

But for lighting it's a cumbersome solution compared to just screening all the lights in just one black opaque layer which is multiplied on the background.

When I do graphics-related compositing I use nested systems all the time, but I can't really think of many uses for nested layers really. The only situation I can think of is when you have several separated objects you need to blend as one, such as screening together two objects and them blend the result with something else. I still feel it's a completely redundant solution to the lighting system. It's not very intuitive.

I hope I don't sound too negative here, I enjoy C2 a lot. But you want your tool to work intuitively, and for the lighting blending I see no more intuitive way than how you visualize it in your mockup.

The only thing I feel is missing from your video is a clarification how the Shadow Light object is blended with underlying objects.

Currently it looks like it's using alpha channel to achieve the shadowing effect. I think Ashley mentioned this can limit the user freedom how the Shadow Light object effects your scene, and I agree. Like if you change the blending mode on the Shadow Light, the alpha of the object will screw up the blending effect.

If the Shadow Light object is opaque as default, the user have the freedom to choose which blending is the most suitable.

• Have only one light source? Multiply the Shadow Light. Can be done on the same layer as your other objects as long as the Z order is correct.

• Have multiple light sources? Screen them together in a layer that is multiplied on your other layers.

Or just go crazy with any of the other blending modes.

That's the most intuitive and flexible lighting solution I can think of concerning the blending.

Awesome mockup video, — Very explanatory.

> would it not be the best solution if the Shadow Light object produced an opaque layer with the falloff gradient already in place inside the object?

>

I don't like this kind of solution since it assumes everyone wants that. The current system is more flexible: you can avoid using a sprite and have infinite-range lights, you can use a custom sprite with a stepped/pixellated fade-out for different styles, etc...

That's why I asked if others find it useful. I don't assume everyone finds it useful, but I know I would benefit greatly from having a falloff with just one object.

But why not make such feature togglable then, if possible? Then everyone can have it their own preferred way. Infinite range, or limited. It's the user's choice.

It isn't creating the falloff that is the problem here, it's the limitations involved when doing the falloff manually.

Doing it the manual way requires one layer per light. And like you explained in your tutorial, each layer requires significant extra computation. It would require to dynamically show and hide layers on demand, as opposed to just creating and destroying Shadow Light objects. And since layers can't be created or destroyed on run time, so I'm stuck with a limited amount of possible amount of light sources.

So my point is more that my suggestion would allow an

• Virtually unlimited amounts of lights on just one single layer.

• You wouldn't need to have the background on top of the shading layer.

• And no need for nested layers, which I assume would take more time and effort to add to Construct 2 than just adding a falloff to the Shadow Light object.

But the reason why having it opaque is helpful is that the Shadow Light objects can then easily be blended (screened/dodged) without the need for limiting and complicated workarounds.

Hi everyone. I have recently begun to do some prototyping for a game that is going to be based a lot around light and darkness. I did some research with Construct2 and realized both the potential and limitations of the Shadow Light object.

I did some experimentation and came up with almost identical solution as in Ashley's tutorial. And weirdly enough I posted my findings and suggestions to Scirra the same day as the tutorial was posted... Some kind of omen? Perhaps, but I rather believe in creepy coincidences.

As I have already posted my suggestions to Scirra I thought it could be a good idea to post them here as well, to get feedback from you end-users.

Following Ashley's principle of "putting light in the darkness", rather than putting "shadows in the light", would it not be the best solution if the Shadow Light object produced an opaque layer with the falloff gradient already in place inside the object? If the shadows and the falloff are just one object it becomes very easy to blend several lights together. You just Screen or Add/Dodge them and they will blend nicely on just one single layer. And this single shading layer is all that you need to blend with your background. Removing (or adding) shadows manually from unwanted areas becomes very easy by just placing something bright or dark on top of the Shadow Light objects in the same layer.

The advantages of this is:

• Only one single layer is needed for shading your levels.

• No need for nested layers.

• The amount of Shadow Light objects is not dependent on how many layers you have. This allows for easy dynamic creating and destroying of an arbitrary amount of Shadow Light objects.

If the falloff is (internally inside the object) multiplying the shadows, that could lead to interesting effects. Like if the falloff had a bitmap like the Sprite object, that would allow for a custom shaped falloffs, like tinted colours and shapes. For example, imagine if you have a mounted lamp on a wall, and you want to place a light source on it, you would want the lamp to cast shadows on the wall. You could then have a customized falloff that matches your lamp sprite, creating the illusion that the lamp is also casting shadows on the wall. Perhaps even play animations, which would be handy for flickering light sources such as torches.

Do these suggestions make sense?

If you users out there would create a game with shadows and light, would you prefer a method similar to what I have described here?

Would these features be helpful, both technically and artistically?

At least I think so, but I'd love to hear other's opinion on this.