All posts by faulknermano

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.

Considerations

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.

Re-considerations

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?

Dark

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)

 

 

 

Advertisements

Look and feel

Though I’ve already done a bit of art for the game, I’ve honestly been fluffing about this one for quite some time. I didn’t have a definitive look and feel so i’m setting one up now.

I had been discussing with B about how to really get into terms with this. I think my main problem, which includes the art I’ve already made, is that the inspiration came from simply an attraction to a particular artwork (in this case Gray Shuko), but had nothing to do with the theme or the feel of the game itself as I want to depict it.

This is 2400 AD:

Playing it when I was but a babe, I can summarise the overall feeling in several points.

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

Note that while certain feelings are not readily expressible from a lookdev perspective, it helped to focus on the overall emotion/feeling I was having when I played the game, because that is the sort of thing that motivated me to develop CITIZEN. Perhaps what seems unrelated might actually be useful when the time comes. Who knows?

As B pointed out, the darkness comes from the black background, and the ‘neon’ probably comes from the magenta-coloured gui frames.

The ‘clean’ is obvious, because the graphics are simple. But I think I there was a ‘dirtiness’ in line with what was going on as a game, so that there are those contrasting elements, especially when going from one area to another (eg entering a room from exterior).

The feeling of unease is harder to track down, and I think that’s more of a gameplay issue, at least from how it looks like right now. I think however, that it will also inform other design aspects, like how the robots will look like, and perhaps even how sound, or the writing is done.

With those 4 points guiding me I scoured for anything in the web for indicators that may give me an idea how to hammer home those things. The thing was, I didn’t necessarily look for the most beautiful images, because I knew that beautiful images were stuffing up my efforts to have an actual theme to the game.

Good examples and why

Dark, neon, simple shapes. This is one of the prime lookdev reference images. Note that I’m not aiming for pixel art, but rather, aiming for the simplicity in detail, as well as non-assuming design.
The colours are muted in the darkness, and the outlines are aesthetically-pleasing.
From the game ‘The Last Night’; again, not about pixel art — and not even about the sidescroller viewpoint, which is not what CITIZEN is, but rather, the dark mood.
From the game Black Annex, I keep this peg to remind myself of simplicity in rendering. Granted, this is rather austere, but the game (gameplay itself) gives a connection between the look and how the game responds and feels spatially, so that simple renders can be given a lot of life, and other considerations and compromises can be made depending on how the graphics are used.
The space is cozy; the rendering is more in line with my initial art. The outlines are pleasing (again), and the proportions are not so realistic.
Not every location in CITIZEN is in darkness, so in exterior situations, I think this lighting condition, and overall feel, is close to the feel I’m going for. I won’t be able to really represent atmospherics, but the cyan haze is appealing.
Though not dark, I can imagine myself filling in the darkness and the mood and tone. The appeal of this image is of the minimum detail to represent the scene. It looks very game-y, The colours are represented more matter-of-factly; while I prefer grading the artwork to fit the darkness, I keep this peg to remind me that I don’t have to go too overboard with it.

Lighting considerations

In respect to the Good Examples shown above, the most use of lighting was the picture of The Last Night which features area lighting, where one portion of the screen will affect a surface’s diffuse colour. This is fine as long as no shadows are implicitly cast (ie by use of explicit harsh lighting).

Note that even when neons were used in the abovementioned image, the overall effect was still diffused; as it is pixel art, there’s an acceptance of these compromises. The artwork that I have to develop should also have the same acceptability using those compromises.

A good example of area-based lighting. It’s basically a masked colour layer that sits on a particular region, affecting those elements that come underneath it.

Proportional considerations

The image shown on the right is probably the kind of character proportions/shape that I want. This means it is realistically proportioned, but not particularly realistically shaped or accurate.

Bad examples (to avoid)

While appealing in of itself, the rendering is a tad too realistic: reflections, soft and hard shadows which require any character in the scene to be rendered as such. Textures are also too subtle. I would like use gradient of colours more often than textures.
From ShadowRun, this is too realistic.
While I love this game, the rendering — like Fallout — is done with too many hi-freq textures.
Though I had originally imagined a scene in the Hills in the same mood and feel as this, this is the sort of lighting that is not practical to do, so I avoid not only these types of lights, but a pitch black exterior, where the only light will inevitably have to come from point sources.
Too simple to the point where I won’t get my tone. Outlines, when too thick, end up brightening the colours, which is the reverse of what I want to do.
Though a beautiful image, the grading is too biased and ultimately too realistic.
Amazing to look at, nevertheless, even static light sources where pronounced shadows are produced is going to be a problem. However, lights above the reach of the main level (eg player, npc, ground-level env), might be ok, even when animated like this picture. Rain might also be a good thing to explore at a later time.

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.

 

Animation sheet commands – addendum # 2

Issuing commands in order

Commands are processed in the order they appear in the intend_list. However, there are 2 types of commands: state, and action. State commands change the sprite variables, and Action commands both change sprite variables as necessary, and also change animation (that is, generate a new lookup).

Directional commands (d:#) are the only State commands. They change the seq_dir variable but they do not issue a PlayerSetAnimation implicitly. It allows for other situations to do that.

NPC animation sheets

NPC animation sheets were created alongside Player animation sheets and they are essentially copies with the main exception that all animation functions as described in the original document have an additional argument passed on to them, which is the UID of the sprite being changed.

In animating Player, this was easy because all references to Player was the same. With NPCs, it’s made so that it can accommodate changing animation across multiple sprites.

NPC animation maps

In the same way, NPC animation maps have been created on a per-NPC basis. Each NPC will have its own animation map named according to the name of the NPC.

NPCs in Tiled

Tied with the animation sheet system, the Facing parameter in Tiled, like the one for the Player, orients the NPC at load time (ie modifies the direction).

Details of how NPCs and other entities in Tiled are defined will be covered in later topic.

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.

 

 

Limiting the vision

As I asked in my previous post, is limiting the vision of a game due to technical limitations good or bad? Should we look to other tools that would live up to the expectation of accomplishing that vision, or should we just stick with what we have and make the best out of it?

But I think my question touch a more philosophical note in me, and I’d like to write it that way.

Vision?

What do we mean by vision? Let me put it honestly in the argumentative spirit it came from: when someone says they don’t want to ‘limit the vision’, and when they’re relying someone else to actually realise the vision, it means that they want a free ticket to every ride in town, at any time, for any reason at all. What they mean is feature creep. They might want to add stuff in; particles, explosions, heavier models, bigger textures, other bells and whistles. They might want to add a new kind of gameplay because they think it’s more interesting. Or maybe they want replace the whole engine.

They might say they’re expanding the vision of the product. They put it that way because it sounds better than ‘I changed my mind, because I was never really sure to begin with; let’s do it this way instead.’ Better not to look as dumb as they really are, so they make it out they had this in mind all along.

When you work alone, your decisions will echo in your bones, because if you decide to change game engines, you’re passing sentence onto yourself and doing the time yourself. There’s not much room for ego because there’s no one else around to pass the buck to.

But when more people are involved, let say in a thing called the Creative Company, ‘expanding/modifying/altering visions’ becomes a problem because it’s easy. It’s easy for people who are actually detached from the actual creating process to think of ideas. When there are no consequences to your thoughts, you obviously will just think of any shit that comes into your head, right?

So, am I saying, that easy==bad? Sure. Because it’s usually borne in the bed of laziness. easy==lazy. That’s precisely why it’s bad. That’s precisely why it’s not an idea you can depend on to be sound, no matter how clever it sounds now. Some people in the past introduced the argument that it’s helpful for ideas to be free from the burden of the hard toil necessary to achieve it because, said this person, if anything is seen too hard to do, people will likely lose heart and abandon an idea that would have otherwise been brilliant. Fair point, and it explains a lot of great things in the world, like slavery and cotton fields, to name one of many. Despite its seemingly sound reasoning I’ve only heard it from the mouths of those who don’t know or don’t want to dirty their hands to work the fields. I think my reasonable answer to that argument is that if people forego a good idea because it’s too hard, the only thing lost is the elite’s vainglory, and we can definitely lose a bit of that. And, perhaps the idea is simply not good enough to sacrifice what has to be sacrificed. Perhaps the idea is only good for those who have nothing to lose by having it.

Technocreativity

I think that creativity is expressed primarily by the limitations we impose on ourselves. I don’t believe in the propaganda that boasts that you will can express your creativity because new doors/features/tools/technology have now been opened to you. For example, as recent as a few months ago, a Disney-esque Samsung ad declares at the end: “We make what can’t be made so you can do what can’t be done.” Clever and nonsensical advertising, sure enough, but the point they’re making is even more nonsensical. The consumer actually does nothing. All they’re doing is — what’s the popular verb for this nowadays? — consuming a product. Or they’re consuming an experience. You’re made to believe you’re empowered.

So, in the same vein, is technology empowering us to be more creative? No. We are just more reliant on technology to express our creativity. It shapes or forms how our expressions look like, but it doesn’t necessarily improve them; it doesn’t make us more creative. We might have a greater palette to choose from, but excepting those who are obsessed by stats, why should we give a fuck how much greater our palette is? But that is the problem, isn’t it? Aren’t we all us obsessed by stats? Don’t many of us largely concern ourselves with specifications: which has more VRAM, more Ghz, less latency, more bandwidth, read/write speeds, terrabytes, etc. We are sold and are persuaded that we are better off creatively because we have better hardware or software. And I wonder, how should we rank ourselves against the people’s creativity generations before? Should we, given how we’ve technologically advanced, fancy ourselves superior?

And if new technology doesn’t make us more creative, why should we update our progs at all? Because new technology is our medium. We have no choice because we are born to it and to the dizzying rate of how it changes. But it’s no Muse of Creativity. It will not heal anyone of laziness. In fact, it is far easier to be lazy because there are too many conveniences at our disposal. And even the sincere among us are more readily confused because technological possibilities are too narrow a framework to build creative minds.

If technological updates are too fast, it is no sin to stay where you are. If you can keep up, move on to the new.

The only thing the differentiates a good and a bad decision is the laziness not to know the difference.

 

Why C2?

For the past many weeks, I’ve been focusing a lot on the development of the animation sheets. But because of this, I hadn’t touched the former aspects of the game for some time, and when I got back to it, there were some issues that were brought to the fore, such as the Beltway being broken. To be honest, I was utterly surprised at this, since I had no recollection, or notes, that say that it had been broken when I left it to develop the other parts. There were also other things that I noticed that needed changing as I tested the implementation of the animation sheets along with overall player movement.

I found myself a bit overwhelmed and a bit tired, as I sometimes do, from having to debug C2 events. For all the user-friendliness it has, it can still be be quite opaque especially if you’re trying anything abstractly complex. It’s not totally the fault of C2, but because of its lack of modularisation, or object-oriented framework within the event system, picking apart why something doesn’t work requires a bit of jumping around, trying to sort out which are workarounds to some weird behaviour, and which ones are meant to do something actually functional.

Anyway, for several minutes I stared at the monitor, and I was seriously debating why I’m developing this game in C2, and not in Unity, where I have some experience in, and the fact that I’m actually good at coding (at least good enough not to doubt my ability to see the project through). Not only do I code, but I’ve been in the CG industry as a 3D artist and TD for 15 years now; on that alone, Unity is more of a familiar programme than C2. But I had a discussion with my wife who takes these technical diatribes with calmness and puts out good arguments, and the result is my rethinking of my situation.

So the question is: why C2?

It began with the fact that C2 made things simple. But what I’m doing with CITIZEN is not so simple. And that reason seemed to be not good enough.

C2 is fun because of the event sheets. But though the event sheets are effective, they are effective as procedures. They are less fun, and less effective when you want some object-orientation or inheritance, which is so useful when when I started delving into certain gameplay concepts that I wanted to implement for the game.

But I think one of the strongest reasons is one of a balance between a simplistic framework, and the relatively blackbox type of plugin filtered into the C2 editor which results in less bugs during development. This is both a pro and con. Taking Rex’s GridMove/Board/SLG/InstGroup system. These are separate systems working together as one. But it has some learning curve to understand how it all of them work. In fact, some components actually need the other, so they’re really necessary modules in order to come up with something like an isometric grid framework. But once this framework is up, the input and output (eg On reach target, On move accept) is unambiguous, and can interact naturally with any other event/behaviour in C2. Why unambiguous? Well, first, the C2 editor registers the event, so it’s part of the choices. Unity, on the other hand, can be quite confusing in this respect; what event handler is being called?; a search through the documentation is necessary.

In Unity, it is possible to get a well-written framework, but you’re going to have to try it out first before you know what you’re going to get. Sure, that’s the same with C2 plugins, but the C2 plugin framework shields you from some the randomness of 3rd-party scripting. C2 plugins follow C2’s rules in order to play nicely with C2. You’ll spot a lemon faster.

But I think the most important aspect to plugin frameworks is simply that they can be added in without messing things up. I don’t have syntax errors in C2 compared to Unity, so if something doesn’t work, syntax doesn’t necessarily some into the picture. Even data types are managed.

I think the best example I can think of is trying to implement Unity’s 3rd-person controller setup to your own game. There’s so much going on in that package that if you try to fix it to behave how you want it, you’re going to mess it up so much that you might as well write your own to begin with. Unity is so flexible, but unless something is so well written, with open-ended framework development in mind (like, for example, PlayMaker), the Unity environment is pretty much like a sandbox.

C2, on the other hand, is more like a playground. You can’t move the playground that’s there, but you can add other stuff into it, transforming it into something new.

At the end of the day, this is just a hobby so it’s important to have fun. Fun is a major motivator. It’s obviously not fun when I have to deal with the awkwardness of C2, or when I have to refactor my events. It’s not fun when I accidentally change the image-point on one of my images and having no undo option for that. But nevertheless, it’s fun to figure out how implement features on an engine that offers a good starting framework.

Without a doubt (in my opinion, at any rate), it is primitive tool when you consider other production engines out there, open-source or otherwise. I think it is easy to outgrow the tools due to the ever-expanding ideas for a game. That’s partly why I had to limit the ideas that I was coming up with. Is that a bad thing? No, but I think I should like a separate post about that. 🙂

I think, however, in the future, after I complete CITIZEN in C2, I will more seriously consider using Unity for other projects that may require a more expansive toolset, especially one that may yield a better game by going 3D.