Author Topic: 2D spritemodding  (Read 9903 times)

Offline Nanashi

  • Full Member Mark II
  • ***
  • Posts: 153
2D spritemodding
« on: June 21, 2012, 12:09:49 am »
I recently picked up AVWW, and found out that it's actually kind of an interesting opportunity to generate art resources for game projects. I figure if I go through the textures systematically and regularly, I should be able to generate an entire library of amateur 2D sprite art, which would make my game creation dreams a lot easier.

I started out with static projectiles, since that's kind of easy, but ended up doing a 16 frame water animation to replace Tidal Surge. I'd do characters, but the lack of a non-1f casting/jump animation kind of kills my desire to start out with that directly. I know the devs don't want to include it in the base game due to performance issues - but I'm hoping they'll eventually give the option to let us mod it in and fry our G/CPUs, as unlikely as that is. Is it possible to mod static images into animations? (I'd like to do a full Launch Rock animation)



Should probably do Fireball and do a texture replace for moss-covered barrels (I've lost 8 characters to these so far and zero to actual gameplay, so it's starting to get annoying). There's no coherent tutorial on the xml used in the particle file, but poking around with values is kind of fun.

Offline BobTheJanitor

  • Master Member Mark II
  • *****
  • Posts: 1,689
Re: 2D spritemodding
« Reply #1 on: June 21, 2012, 01:58:44 am »
Pretty spiffy. I like the cel-shaded sort of look you've got going on there.

Offline Nanashi

  • Full Member Mark II
  • ***
  • Posts: 153
Re: 2D spritemodding
« Reply #2 on: June 21, 2012, 10:45:36 pm »


Making a fireball replacer kind of alerted me to the oddities in AVWW's particle coding. I originally made a sideways fireball, but couldn't find a way to get it to rotate properly relative to self (stayrelative didn't work), so I ended up rendering it sideways for a flamethrower effect. Which didn't really work, because fireball is kind of a single shot spell that doesn't penetrate.

Tweaking a little more ended up with this:



It doesn't quite have the personality I wanted it to, but it'll do for now.

Offline Mirico

  • Newbie
  • *
  • Posts: 1
Re: 2D spritemodding
« Reply #3 on: June 22, 2012, 10:03:58 pm »
I really like how these are turning out, look forward to seeing more.

Offline Nanashi

  • Full Member Mark II
  • ***
  • Posts: 153
Re: 2D spritemodding
« Reply #4 on: June 23, 2012, 12:26:55 am »
@Mirico: Thanks!

This one is a bit shabby, and didn't take much effort, but I wanted to finish up the basic projectiles before I started making sprites.

I had a bit of a beef with Ball Lightning because to me, 1) It doesn't look like lightning and 2) It doesn't look like a ball.

It's a bit of a hack job, but it looks slightly better in-game than it does in these pictures. I wish I could make an animated gif, but the gif format has 256 colour limitations that make that impractical.



Can't really demo it without an avi file (which is way too much hassle for a dumb texture mod), but if you're bored and want to see what it actually looks like:

1) Put this in ..\RuntimeData\TexturePacks\Custom\Images\Particles\FireGasBlueDict\



2) This goes in Particles.xml in ..\RuntimeData\TexturePacks\Custom\Configuration\

Quote
  <g pattern="BallLightning">
    <p name="FireGasBlue" y="32" offs="-2, 2, -2, 2" mov="5, 10, 160, 200" rot="0, 360, 0, 0"  stayrelative="true"
       sca="0.2, 0.8, 0.2, 0.7, 1" anim="80" infront="0" infront_minspeed="0" emiss="0.02" shad="AdditiveAffectsLighting" ondeath="0" perframe="1" />

    <p name="FireGasBlue" y="32" offs="-5, 5, -5, 5" mov="3, 5, 160, 200" rot="0, 360, -0.5, 0.5"
       sca="0.1, 0.1, 0.1, 0.1, 3" anim="80" infront="-60" infront_minspeed="0" emiss="0.01" shad="AdditiveAffectsLighting" ondeath="7" perframe="1" />
  </g>

It's rather a lot of unnecessary trouble to go through though.   :P
« Last Edit: June 23, 2012, 12:51:26 am by Nanashi »

Offline Nanashi

  • Full Member Mark II
  • ***
  • Posts: 153
Trouble with Textures
« Reply #5 on: June 25, 2012, 02:18:41 am »
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 Design
With 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 usage
One 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.

Verisimilitude
Above 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.

Relevance
Now 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 based
This 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 code
And 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)

Offline Nanashi

  • Full Member Mark II
  • ***
  • Posts: 153
Re: 2D spritemodding
« Reply #6 on: June 25, 2012, 06:36:39 am »
This is a follow-up post to the previous one - I didn't want to make it even longer and I apologise for the gratuitous bump (there's no sage option).

It's a bit mean-spirited to do one-sided criticism without any material to back my words up, so I thought it'd be useful to give a practical demonstration of a few of the concepts from above. This is not a fair comparison because the images are not identical, but I've re-drawn the bright orange cabinet with something which I think better fits my art style and colour scheme. I've also removed the unnatural "radioactive glow" effect that almost all foreground objects seem to have in the alpha channel and replaced it with a drop shadow - compare it to the dryer and the filing cabinet on the bottom right, which still have the glow effect.



I'd like to think it adds a slightly different ambience to the game.

Offline marsvalient

  • Newbie
  • *
  • Posts: 1
Re: 2D spritemodding
« Reply #7 on: July 03, 2012, 08:39:05 am »
Dude... I signed up just to say how nice those look so far.

Really hope to see a completed set like this, would love to use it.

 

SMF spam blocked by CleanTalk