next »

[enthrallstudios]

Hey guys,
So I have been wrestling with a decision on what size my platformer sprite should be. I know that in the old days sprites were like 16x16, but with resolutions today, won't that be way too small? Would 32x32 or 64x64 make more sense? The game is quite dark, and the gameplay will require a lot of wall jumping and megaman-style shooting.

Thanks!

[ink.inc]

any of those sizes will work

[moi]

16x16 is definitely too small, after it depends on your game because it will have an effect on the gameplay.
Just make a prototype

[enthrallstudios]

I guess I was just wondering what size most of you guys use. I haven't worked with sprites in years so I'm not sure what is the "norm" these days.

[Azure Lazuline]

Make a game with colored squares for all the sprites and try out different screen resolutions and sprite sizes until it feels right. THEN worry about making the actual sprite. If you arbitrarily decide on a size beforehand, then make the sprite before you make the game, then it's much harder to change.

[enthrallstudios]

Speaking of screen resolutions, how do you handle multiple resolutions with such easily distorted characters? Do you just throw up some black bars to deal with the older 4:3 aspect ratios? How about scaling your guys? (this might be better suited for the development forums.) I have looked at as many games as I could and it seems like most of them allow minor stretching and force widescreen with the black bars. I don't know how they scale them without them being very pixelated though.

[sublinimal]

Since technical limitations don't dictate sprite dimensions anymore, you're free from worrying about emulating old styles.

It doesn't have to be a square, it doesn't have to be a power of two. Spend your energy on making the character look like it does in your head.

[Azure Lazuline]

If you're using pixel art, generally you use a low resolution like 640x480 or 800x600, and scale up with nearest neighbor if the user wants a larger size. If you want it to not be pixelized at higher resolutions, then you have to make the art at the higher resolution.

[Retro-Rob]

I've been working on a megaman inspired platfommer on and off.  The main character is a 16x16.  He's in the mock ups below a couple places.


[img]http://robertmaherdesign.com/space200Large.png[img]

The game is intended to be viewed at 400% zoom but sometimes it'll zoom to 300 - 200% zoom level during some boss encounters.

[Lee]

Since technical limitations don't dictate sprite dimensions anymore

That isn't necessarily technically true when working in low level APIs like openGL* (well for the whole image/spritesheet, not individual sprites). However with high level APIs like SDL, Allegro and the like (basically any library which you can just call a draw image function) you don't even have to worry about it at all.

*While individual sprite size is irrelevant the size of the full image loaded to texture memory might not be. It is graphics card & driver dependant, some ONLY support power of two textures (1,2,4,8,16,32,64,128,256,512,1024...) which will mean the graphics will not even show up, more modern graphics cards should be fine although I think it may cause a very minor, almost insignificant, slowdown.

Bumping up the images to the next PO2 dimensions in the app immediately after the image has loaded is an easy one-off task which is pretty much negligible in terms of performance, this should mean the textures should work on all graphics cards. I'd guess the higher level API's do this automagically for you.

So yeah technically the image size (i.e full spritesheet or background image -not individual sprites-) may matter if you are using really low level stuff or using huge non power of two images may  be padded up to the next PO2 dimensions (or I could be wrong), which will just waste a bit of memory... For an example a 1025x1025 background image would be memory padded to 2048x2048, whilst just shrinking it by 1 pixel in both dimensions would lose pretty much nothing at all and would require no padding- as for that difference in memory requirements:(1025x1025x3 col channels = 3MB in texture memory, 2048x2048x3 colour channels = 12MB in texture memory) but images below 512x512 aren't worth worrying about because the difference in texture memory by today's standards are not even worth thinking about; although as I've kept mentioning this is texture memory (i.e. your graphics cards in-built memory) not the computer's memory and is generally between 128MB and 1024MB (but even 128MB can hold 170 512x512 bitmaps so perhaps worrying about size at all is just being pedantic).

tl;dr: sprite size doesn't matter but for large sprite sheets/bg images (i.e. the full image on your hard drive not the individual elements/sprites on the image) you may want to make sure they are not going to be so wastefully padded like in my example.

Also I believe most cards only accept texture sizes up to 2048 or 4096.



Regarding actual useful information: I would suggest you open a canvas at the size of your games window and just draw a rectangle at about the size that you think would be best for what you want. Or just draw a mock-up on a scrap of paper and try to copy the sizing from that.

You'll want to be thinking about how much background you are showing and how many characters can fit on screen at one time and draw the box accordingly. Using this you can then measure the size of the box you drew and base your sprites on that size. This is much better than choosing an arbitrary size.

Even though you can make pretty much any game with 16x16 graphics, having proportional sizing is a lot better and engaging. (for a game about exploration or relaxation you can make the character on screen small so you can display a lot of the background and surrounding area, for a 1 on 1 fighting game you can have intense close up focussing on the characters themselves, for a platformer you will always want to make sure enough of the level is visible so that the player can quickly see the path they want to take instead of having leap-of-faith type moments or potentially missing the correct route, etc.)

[SolarLune]

16x16 can be too small, but it depends on the resolution. 16x16 character in a 320x240 resolution game over a 32x32 character in a 640x480 game is basically the same (character to screen size-wise). If your character's 16x16, then you'll want a smaller resolution for the game view, and then to scale the screen up to a larger resolution.

[VoxelHead]

but with resolutions today, won't that be way too small?

Nope, just scale your resolution.

[enthrallstudios]

Hey guys,
Thanks for all of the advice. I think I am going with a more digitally painted style, so I'll probably stick with the actual resolution on the screen and make the character about 64 px tall. Thanks again for all of the advice. I'll have a devlog up when I get to that point. So hopefully I can show off my progress soon.

[Eendhoorn]

Just curious, why are we still using power of 2 sizes for tiles? I can imagine there used to be constraints by the hardware, but it shouldn't be a problem anymore nowadays.

[Azure Lazuline]

Because nerds like powers of 2.

[DavidCaruso]

(snip)

Your art in these shots is pretty awesome, but that amount of zoom is kind of unbearable to my eyes.

Just curious, why are we still using power of 2 sizes for tiles? I can imagine there used to be constraints by the hardware, but it shouldn't be a problem anymore nowadays.

Cleanly divisible into many common resolutions e.g. 320x240, 640x480, etc. and half-divisible (i.e. divisible by 8) into many others. And also you can do bit shifting for some operations I guess?

[enthrallstudios]

I only stated 16x16 or 32x32 to get a general size. I can do 33 x 67 if I want.

[st33d]

Just curious, why are we still using power of 2 sizes for tiles? I can imagine there used to be constraints by the hardware, but it shouldn't be a problem anymore nowadays.

It's still a problem on many platforms. Textures for a lot of things have to be in multiples of two before they're fed for rendering. That's how the graphics libraries are wired up. You don't have to worry about this sort of thing in Flash, but it's an issue you have to work around elsewhere.

Also - making the artwork before you have a working gameplay prototype is retarded. No one cares how pretty your game is going to be (except people who comment on Greenlight), make it playable first.

[ink.inc]

Also - making the artwork before you have a working gameplay prototype is retarded. No one cares how pretty your game is going to be (except people who comment on Greenlight), make it playable first.

trufax

[Fallsburg]

Also - making the artwork before you have a working gameplay prototype is retarded. No one cares how pretty your game is going to be (except people who comment on Greenlight), make it playable first.

Be honest, there are quite a few DevLogs like that as well.