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.
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
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.
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.
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.
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.
Knowledgebase for creating a Construct 2 isometric game.