Print

Please login or register.

1 Hour 1 Day 1 Week 1 Month Forever

Login with username, password and session length

[Sambojin]

This is not meant to be a final version or anything, merely a draft to open up discussion on the subject. I've recently put my hand up to do some tile work for CF, and others have as well. This gives us all the chance to contribute, but it also raises some problems. Are we all going to work with the same technical specs?

I myself have a bit of knowledge of programming and understand just how much easier it is for both spriters and coders to complete a project if everyone is working from the same standpoint. While it may seem redundant in todays 16.7 million colour, 3D accelerated world, tiles and sprites as a whole have tended to be 256 colours, with a definate palette scheme for the programmers to play with. There's good reasons for this. Palette swapping, colour duplexing and colour cycling are all mainstays of games, because they work. They're quick, they're easy, and they don't hog cpu time. They also make a spriters life easy, because while you have to stick to a certain work scheme, you won't have to redo a sprite a hundred times just because one is a slightly different colour or is glowing. Basically, that ends up as a coders problem. But it's also a boon for coders, allowing them far greater versatility in their designs and options, and they will have the format for doing their GFX magic all nicely laid out for them. They've got a standard programming scheme to use, it really does help if us artsy types don't mess with it too much. It helps a lot for them to have a standard graphics scheme to work with as well.

So I prepose that we set up a tech-spec document for the graphics format for CF products. This will be a draft document at first, to make sure that any contributing artists can work easily withing it's limitations. It also gives potential coders time to consider the ramifications and abilities it will give them from their perspective.

I'll reserve the next couple of posts so we have room to update it, and I'll start by putting up what I think would be a good design draft. Some may consider it an overly limiting factor on their creativity, but once you've seen what it can do, I think you'll enjoy making your art under such a system. How many times have you ever used more than 20 colours in a 32x32 sprite anyway? That's 6 shades of those 20 colours mind you, so there's still plenty of options.

Anyway, I'll do another quick post stating why I think such things are handy, and almost necessary for future CF projects. Mainly it's just so all the spriters and coders can come at anything they're doing from the same level. It's a lot easier to make 20 standard palettes for us to use then to resubmit the same tile 20 times with a slightly different colour scheme. Plus, programmers love reserved palette entries, it's amazing what they can do with them

[Sambojin]

Things I'd like to see in the standard Chaosforge artist's specifications:

A standard 256 colour palette for basic work, with other custom palettes to be added for new colour schemes that fit across the range of sprites created. Two inital palettes, one basic, one for hidden texturing. Palettes added as necessary that have been tested on the whole range of sprites to check for compatibility issues. We've got 16mil colours to play with, we're only using a subset.

At least 8 reserved colours in the palette for programmer effects. Duplexed to 16 reserved entries. They'll probably never use that many, but it's handy for them to have.

Suggested standard control entries. Entry 0: really, truly, reserved black. Entry 1: Transparency. 2,3: sprite outline. Entry 4,5: eye colour.  Entry 6,7: glowy bits. Feel free to suggest more. These let the programmers simply do a "if pixel=this colour then make pixel now be new colour". Colour cycling, outline effects etc add a lot of variation for game-play style FX.

Palette duplexed. 20 seperate colour styles with 6 shades each. All entries copied to bottom half of palette, making a total of 240 entries+16 reserved colours for programmer jazz. Plenty of colour and shading possibilities still, with an option of hidden texturing. Change the palette so what appears to be two identical greens beside eachother to gray and dark blue? Your army camo outfit is now an arctic camo outfit, and you didn't have to redraw a thing. Hidden texturing rocks, but it is quite a task to get used to drawing sprites in this fashion. We can start off with two standard palettes, one to draw in, the second with the bottom half of the palette off-set so you can colour in the hidden texturing. Then we just make well thought out palettes rather than re-colouring or redrawing every possible combination of things.

Paper dolling. Think Dungeon Crawl Stone Soup's player characters. We will need to set up a standard x,y scheme for paper dolling our sprites. Where is a good point for hands to be? We need to know so our gloves will end up where they're meant to be, and not on the players chest. Same with weapons. We'll need to make up an appropriate scheme, perhaps several for different creature sizes. This is especially true for animated sprites.

What sort of animation will we do? I'm a fan of a 4 frame walk, 4 frame attack (two styles, cycled 1,2,3,4,3,2,1 and normal 1,2,3,4. Specified on sprite submission) and a 4 frame death sequence. It adds a lot of options and characterisation to sprites, and doesn't add too much workload. Although, even I admit that moving paper-dolled gloves a couple of pixels at a time can get monotonous.

Scaling and size. Not really a huge problem, but how much area do we have to work with? 32x32 would probably be ideal, simply due to the ranges of display resolutions the sprites will have to work with. As long as they're not linear scaled. Nothing ruins an artists work and sprite detail more than linear scaling. Bicubic resampling, indeed any other style of scaling, just not linear. Even if the scaling is done in memory at program start-up (no one likes a realtime cpu hog). 32x32 gives enough area to work with, and fits nicely in even mobile platforms for future consideration. I'd also suggest a 48x48 or 64x64 for larger enemies. I don't really care if it overlaps into the next tile, big stuff needs to be big. It'll be in it's own tile, it'll just look like it's bigger than one tile. Basically, z-blit the big stuff last, it's meant to be hogging space in more than one tile graphically.

So what do people think of this style of spriting and what would you like to see in your design brief if Kornel asks you to do some sprites or tiles? I'll u/l some examples to illustrate what I'm talking about in the next few hours.

[Sambojin]

reserved

[Sambojin]

reserved

[Sambojin]

I'll keep those two posts reserved. But think of it this way. I like making graphics. I'm pretty lazy. I could just submit whatever sprites I wanted to. Maybe I will. I know that the coding talent of ChaosForge currently outweighs the graphic talent, otherwise we'd have the whole range of games currently being sprited and pretty. So can we as graphics artists work with these mooks? We've got a current gold standard to beat...... I mean, he's only Derek Yu. He's only one of the best graphic makers out there. He's just the guy that I learnt (and re-learnt) how to make tiled sprites in roguelike games from. So can we as artsy's people and codey's types do some stuff? Otherwise, I'm just going to start annoying Kornel with random submissions of "art". You know there'll be some 4bit cyan shit, just to annoy him.

[Reef Blastbody]

This thread is way too interesting to be languishing for 30 days without attention and zero feedback at all.

I'm not an artist, nor am I a coder at all. I imagine people might have glanced at what you typed up and balked a little bit because it seems like a lot of start up work, but if I understand what you're proposing, that's only initially. Once you have a set of parameters and guidelines for scales, palettes, frames, etc, then anyone who was willing and able to do the spritework would theoretically be able to look at said guidelines, do up the work, and then plop it out nicely in a package ready to be inserted over some code, right?

I'm posting here right now because this not only sounds like an awesome idea, but because it should hopefully trigger that little "UNREAD MESSAGE" flag for people and get some attention over here where it belongs.

I'll u/l some examples to illustrate what I'm talking about

Please do! I think it'll be easier for people to understand why this is important. If you really want to get them fired up, try doing a fake AliensRL graphical mock-up, khe he he he.