Tag Archives: slidewalk

Lookdev of 3 scenes

On 2017 08 09, I rendered this for the Slidewalk lookdev.

Slidewalk lookdev


Last night (early morning) I finished the Sub-Rail lookdev:

Sub-Rail lookdev

Looking back at my basement lookdev:

It’s quite apparent that the style has changed a bit. The environments are a bit different in scale and focus and this is probably one reason why the style has moved places.

Analysing the three renders

  • The basement scene is the most ‘cartoony’:
    1. Mainly shaded by AO. The AO is strictly controlled on a per element basis. Some don’t have AO at all.
    2. There is an ambient that gives a base cool colour.
    3. Then there are individual space lights.
    4. Parametric shading (eg pipes) is tightly controlled
    5. Textures are made contrasty to enhance the ‘cartoony’ look. Textures are also posterised, and colours are remapped for the ‘cartoony’ look.
  • The Slidewalk scene is mingling of more GI lighting with forced shading:
    1. AO-like shading is achieved partly by GI solution.
    2. There are also AO shaders where the darkness is emphasised.
    3. Spacer lights are still there.
    4. Apparent soft shadows both from volume spacer lights and AO.
    5. There is still parametric shading but you can see the influence of spacer lights on other surfaces beyond the floor it was originally (ie in the basement scene) intended.
    6. Textures were not posterised or made contrasty. Much of the ‘cartoony’ look is gone.
  • The Sub-Rail scene is dark and moody, which dictated the techniques I ended up using:
    1. AO for dark areas
    2. Lots of volume spacer lights achieving subtle shadows
    3. Use of spacer lights to reveal texture (eg vertical tunnel lights against bricks)
    4. Some textures were posterised to increase contrast (eg entrance wall)
    5. Specifically chosen textures for floor to reduce textural complexity.


In my Look and feel post, I pointed at things I should avoid, mainly pointing out at the realism of the renderings. But it seems that it’s hard to avoid given the nature of the tools I’m using.

First, the mapping issue. Laying down a map section as I have done in 3d is much easier to visualise than if I went with the 2d route. I think, given my existing skillsets, it would have taken much longer as well. I think it would have produced a different look, probably closer to the pegs shown in the Look and feel post. But having laid it out in 3d, I had started using 3d lights, GI, AO, etc. And this consideratio is ultimately what causes the look to be more realistic than I originally intended.

In the basement scene, the area is small enough that it’s manageable for me to isolate shading against certain lights, and force parametric shading on certain objects. This workflow is closest to a ‘2d’ approach (with the use of Tiled in mind).

In the Slidewalk scene, the area was too big. There were so many elements that needed considering that it would have taken me loads of time to adjust every section of it.

In the Sub-Rail scene, the scale was reduced, and the scene’s mood was darker, hence it was easier to manage even some parametric shading. Nevertheless, I could see I was moving on to the realistic territory here.

In lookdev, I’m trying to sketch out a look. But if I’m starting to sketch (ie quick renderings), I’ll end up using the most efficient tools. And if those tools are geared to producing realistic renderings, then I have to take another step to ‘dumb it down’. For example, it takes more effort to tweak a posterised texture than simply to use the texture itself. In the area of shading and lighting, that problem balloons to the point where it no longer feels like sketching, especially when many elements are being placed in the scene, and/or if the scene itself is large.


The question goes back to the 4 bullet points that was supposed to guide me in the lookdev:

  • Dark
  • Bright neon lights
  • Dirty and clean contrasts
  • Feeling of unease in the environment

With these in mind, what re-considerations can I make?


Certainly, the Slidewalk scene was not as dark as the other scenes. But I didn’t really need everything to be dark. However, the expansiveness of the scene and the flat and dull blueness was overpowering. I think there is no contrast the makes anything pop because everything is lit evenly. There’s no concrete idea of what the sky looks like (whatever is there looking up) because it’s just grey-blue. Perhaps shadowing of tall buildings out of sight? Perhaps shadow movements of overhead cranes or floating cars (if floating cars exist). Also, it must be emphasised that the expansive space helped create the problem of how to light it interestingly. The space caused me to abuse ambient lighting. One lession that I think I’m seeing in the Slidewalk scene is that even if the physical space is big, it can be (should be?) partitioned off using shadows or its inverse, lights. Whatever the case may be, the use of contrast can be used to define major sections within a bigger area.

In the basement scene, the darkness was not literal darkness, but that everything was subdued, and there were only a few sources of light. The littleness of the scene made the dark aspect easy to control, because the partitioning of lightness and darkness was done in small parts.

In the Sub-Rail scene, I think this was the most judicious use of lights given its relative size. I think this scene hits the dark aspect of the game: overall subdued darkness punctuated by slithers of light coming at different angles. In addition, there are volume space lights that partition areas within areas into light and shadow, eg ‘Sub-Rail’ text on car is shown clearly while other parts of the car are in shadow.

I would say that the basement and Sub-Rail scene lent themselves well to the dark aspect, while the the Slidewalk scene was naturally more problematic. And what I’ve learned is that if I’m doing a large space, then I must compartamentalise that space more.

Bright neon lights

In the same manner as above, the more contrast the scene has, the more bright neon lights can be successful. The neon lights give off a sense of civilisation when everything else is hidden in unknown. In the Slidewalk scene, everything seems exposed, so that nothing is really that hidden. This makes it weak even in this respect.

Dirty & clean contrasts

We can think of dirty and clean contrasts in one scene or the comparison of moving from one scene to another. The Sub-Rail scene is a dirty scene, mainly. The dirtiness relates to the brick, the trash, the chairs, and cautionary markings. The cleanliness relates to the lights (perhaps there should be broken lights?) and screens, the ticket machine.

Even in this respect, I think the Slidewalk scene fails, even though there are trash on the floor and the bricks are used as textures. I think there is too much brick everywhere that the dirty/clean contrast can shine. The floor, possibly, contributes to these non-contrastiness. However, the Slidewalk flooring itself, is stark and pops out, which is probably the best thing in the scene in terms of dirty & clean contrast.

Feeling unease

As mentioned, feeling unease might be more to do with gameplay, or even sound, but I think it’s worth a try to challenge myself into thinking about this more clearly in respect to lookdev.

I think the use of propaganda is a way, but that requires specific propaganda messages to come through, which means a specific design. Now,  the question would be whether ‘feeling unease’ can come through in terms of lighting and shading and use of space.

Possible devices to use to cause unease:

  • a flickering bulb
  • pulsating lights (SCAMs?)
  • unseen depths or corridors (Slidewalk scene, big drop)





GridMove Direction Limitation

As described in Rex’s own site about GridMove.Direction, this expression is only valid if the movement is to a neighbouring tile. In the Slidewalk system, however, although the construction of the Slidewalk path may be straight, the target tiles may be separated from each other for efficiency sake (ie less node paths to draw in Tiled).

It is inefficient to ‘connect-the-dots’ in C2 by tagging the tiles that the path goes over, so I’m instructing GridMove to move to the Slidewalk target tiles that are not neighbours, This makes GridMove.Direction invalid.

What I did, instead, was to do my own GridMove direction by comparing GridMove’s SourceLX/Y and DestinationLX/Y expression and generate a direction using conditions.

At this point, however, the conditions assume that the nodes are positioned in a way that it follows the lines for 8 directions, as it checks how the target tile’s LX and LY are different for the source’s corresponding LX and LY.


Slidewalk TMX and C2 system

The Slidewalk system, taken from 2400AD is implemented by using several components in Tiled, and hooking them up in C2.

Tiled/TMX Component

The Slidewalk is comprised of several objects which are the children of an ObjectGroup; the ObjectGroup, in effect, is a single Slidewalk entity.

Components of a Slidewalk

What identifies an existence of Slidewalk is not the ObjectGroup, but the individual Objects which must be named starting with the prefix sw. Each Object component of the Slidewalk contains the name of the Slidewalk it belongs to. The name of the Slidewalk is the name of the ObjectGroup.

A Slidewalk must always have a path. A path is a Tiled polyline. It must be named swpath. The path will later define the waypoints of the Slidewalk. The swpath Object must also contain an attribute called speed. This is the speed value of this Slidewalk.

A Slidewalk must have at least one entry-only point. This point is defined by using an Object (parented under the Slidewalk in question). It must be named swin.

A Slidewalk must have at least one end-only point. This point must be named swend.

A Slidewalk may optionally have an exit point. This exit point may also be a potential entry point. Every point, whether it is an entry, exit, or end point, must begin with sw. Then use the keyword in to indicate this is an entry point, and the keyword out to indicate it is an exit point; these keywords may be used in the same point, such as swinout.

The exit and the end points must also contain a custom property called exitdir. This is a GridMove direction that specifies which direction the player will move towards when deciding the exit, in order to get off the movement effect of the Slidewalk.

C2 Implementation

In C2 the first step is to get the swpathObject to mark the waypoints of the MTiles. In the same procedure, they are marked with the name of the Slidewalk they belong to. The waypoint sequence index is internally based on how Tiled writes it, which is sequential anyway, so the C2 loop iterator does this conveniently.

As the MTiles are being tagged as waypoints, they are being added into the InstGroup with a group named after the Slidewalk’s name, which uniquely identifies these series of MTiles for SLG and GridMove. They are added in the order they are looped, so the sequence is still preserved at this point.

MTiles are then further marked with their entry/exit/end values, as well as the custom properties as inputted in Tiled.

When the player moves on top of the Slidewalk, the On GridMove reach target trigger will check whether the player is on an entry point. If it is, a function called CreatePathFromIG is called whereby it takes the Slidewalk InstGroup waypoints and transfers those waypoints to the player’s own InstGroup moving path. CreatePathFromIG does something more, though: it considers the possibility of multiple entry points; it finds the MTile that the player has entered from, and starts retrieving MTile waypoints from that point until the end.