Trouble with textures (Very long read!)I'll start this with a simple image of a rework-in-progress of the rusty wall texture, because it'll set a precedent for the mini-essay about to follow.
I like to imagine sometimes that with any game, there's a little artist and an engineer having a war with each other. The artist prioritizes aesthetical beauty and the engineer prefers mechanical beauty. These two are frequently incompatible, but it's somewhat unfair to say one is less important than the other. Without the engineer, there is no game, period - but the artist is by and large in charge of communication: Any information the game relays has to cross the gap between the artist's medium and the player's interpretation.
Anyway, I'd like Mr Park to forgive me for any perceived slights to his creation, because he frankly has put in a crapton of effort into the artistic resources for the game alone - and EVERYONE has subjective aesthetic senses.
Personal Guidelines on DesignWith any repeated background texture, the larger the ratio of the tesselation size to the screen, the better the final result. AVWW uses basic dimensions varying from 64x64 to 256x256, which tends to get repetitive on the eye very quickly. This particular image is in 1024x1024 (The game isn't programmed to handle non-square proportions). The obvious problem is that the larger the file size is, the longer it'll take to load and the more memory it's going to hog.
This is not unmanageable. The image above is only 383KB despite using alpha channels, but although the default textures are usually pretty small, certain textures such as the WallPlasters 1 and 2 are over 1.3 MB despite only being 256x256. This is probably why they're unused (at least, I haven't seen them in-game yet) and they're probably artefacts from old versions of the game. To keep file sizes down, ideally, I'd like to use an extremely limited palette, which ties into the following guideline.
Responsible colour usageOne hallmark of old spritebased platformers - any stage with an intensive amount of action on it will be aided by a background which is not visually demanding (note that elaborate backgrounds are fine if you have a good reason for it. This is why all art "rules" are merely guidelines, as in writing.).
Visually demanding factors:
-Intense colours.
No good 2D game made has ever used bright fuchsia as a backdrop. This is mitigated by using a limited palette, an overall colour theme, and desaturated colours. Saturated and bright colours are usually reserved for foreground and interactive objects only. AVWW's colours tend to be oversaturated (WallFarFuture4 and WallRuralBrown are pretty nasty on my eyes).
-Contrast. Large amounts of colour contrast or clashing colours in the background are extremely distracting. Games which do use brightly coloured backgrounds such as Mario and Sonic etc tend to go with colour consistency as a result, but note that this is also a very good reason why Mario and Sonic are not traditionally consistently dodging massive volumes of projectiles and enemy spawns tend to be small.
VerisimilitudeAbove all, consistency needs to be key. Semiotics features into this somewhat - It is important to be able to tell that an enemy is an enemy. This is actually one of the worst bits about AVWW's current art flow and I think why it (unfairly) gets flak as having "bad" art - as an example, some enemies are actually glorified particle effects and as a result, it's difficult to distinguish if a jellyfish or the projectile it shoots is an enemy.
Power-ups almost always need to have artistic cues. So do main characters - ever reflect on why castlevania main characters almost invariably have white hair these days? (Simon Belmont was an obnoxious shade of orange) It's not just because it "looks cool". (Note that AVWW does a fairly good job with character cues). Enemy projectiles often glow obnoxiously in games too, while player projectiles aren't necessarily very engaging - because an enemy projectile is best when it can be labelled as "danger" (some games do this with particular shades of colour for enemy projectiles, or by giving them specific flashing outlines, etc).
Mr Park has talked at depth about the "scrapbook" effect of stock art, so I'll not go into that here.
RelevanceNow that all that manifesto crap is out of the way, how does this relate to my current project? The sad truth is that sometimes AVWW's design conflicts with artistic design and presents it with severe limitations. A lot of modern artistic techniques to break up the monotony of backdrops are limited by this.
AVWW is portal basedThis is by far the biggest problem. If AVWW was mainly room-based, like a jigsaw or like a more traditional metroidvania with edge transitions, creating unique backgrounds would not be difficult. As it is, the best compromise is generic - that window in the picture above there was added as a background element as a demonstration. Sure, it "looks" fine, but, it actually creates a plethora of issues. What if a door, floor or wall spawns on a background element?
Every background has to be flush directly with the screen, you can't create any illusion of depth because of doors and as a result something like this
http://www.vgmuseum.com/mrp/cv-sotn/screens/new-extra3.png, which is pretty basic, can't be done. (or even a flat backdrop which doesn't match up with doors). If it was mainly an edge-transition game, this wouldn't be as much of an issue because most non-area-transition doors wouldn't exist and portal transitions would be special.
Some considerations include changing the door art itself, but I sometimes feel that having each room stand alone as a complete element (perhaps even having its own background and putting the onus on the room designer to keep things consistent and lined up) would have enabled greater artistic expression. Changing that would involve a silly amount of work though, so that's probably unlikely to ever happen. This means I have to find an artistic workaround, or just accept that dumb clipping happens.
Overzealous Memory Management codeAnd it's a beautiful piece of code, to be sure - but there's some quasi annoyances. This also relates to the window above - after placing it, I realised that external background layers are actually only rendered on call. If at any one point in time, the external background layer (the stuff outdoors) isn't being rendered onscreen, it gets unloaded from memory and the entire image through the window will black out. It's kind of disconcerting.
I think AVWW's internal backgrounds in this current state may be doomed to be somewhat claustrophobic (Note that the above issues mainly arise from private modding, if I just created my own rooms, it wouldn't be an issue), but it's going to be an interesting challenge to work around. (At least underground textures would be easier, because it's easier to mentally justify random clipping)
