How Big Should a Platformer Character Sprite Be?

[Odolwa]

I'm currently trying my hand at some sprite art and I wanted to settle on a particular style along the lines of Mega Man X or Shovel Knight. To practice this I went to The Spriter's Resource site and acquired a sprite sheet for X and Plague Knight (PK). After I carried the sprites across into the sprite editor of GM I found that the sprites for both characters came out at about 32x32.
When I put PK into the room (with a view size of 640x480) I found the character to be quite small compared to how he appears in the actual game. Specifically, he is twice as big there.
Playing around with the numbers a bit I found that a view size of 800x512 and doubling the size of the sprite in the sprite editor yielded the closest match to the dimensions I observed in the game. However, when I tried setting the size of the sprite with 'image_xscale = 2' and 'image_yscale = 2', PK ended up looking slightly blurry compared to the scale increase I achieved in the sprite editor.
At this point I'm wondering if it's common practice to try and draw character sprites as small as possible (i.e. 32x32) and then later scale them up in-game as a way of saving memory in the sprite resource tree? Can the sprites be compressed to a 32x32 scale when exporting, because if increases to detailed sprites with 'image_x/yscale' results in blurry pixels and problems with collision checks, I don't see how I can use them at anything other than 64x64 (i.e. I initially draw them at the 32x32 range and then scale up in the sprite editor).
Can anyone else explain this? Do you guys keep your character sprites at the 32x32 range or 64x64, particularly in relation to platformers?

 

[hogwater]

Decide on the resolution of your game, then decide on the relative proportions of the sprites/objects. IE: The player is 1/8 of screen height, etc.

 

[Nocturne]

Can anyone else explain this? Do you guys keep your character sprites at the 32x32 range or 64x64, particularly in relation to platformers?

In general, you should never scale the sprites in the game, and instead choose a base resolution for your game (like 320x180 or 1920x1080, etc...) and create sprites, tiles and backgrounds to suit that size. You would then scale the game up to the screen/window size you require using views so that everything maintains the same aspect ratio and doesn't blur.

 

[Odolwa]

Apologies for the delay in responding, as I have to go look up things when I get feedback on a topic I haven't worked with before. In any case, if I understand it correctly, GM's default resolution is set at 1280x720? I have decided to just stick with this as other posts on this topic suggest working with a 16:9 ratio which would be best suited for most devices, although I'm only really focusing on desktop for now anyway.
On that note, my intention was to use the fullscreen mode, so alternating between different resolutions (on my own computer) didn't really result in major changes in what was being displayed. I suppose it's more about fitting different sized screens anyway.
The question I'm trying to figure out now is if there are specific view sizes I should be using for a specific resolution? For example, I currently have mine set at 640x480. Is it just about choosing what works? If most sprites are 32x32, or 64x64, will I have to redraw the irregular shaped ones, say a boss, to fit that space or does blurring become less of an issue the larger the sprite gets?

Sorry for all the questions, but it feels like this is a big decision I have to get right before I commit to it 100%.

 

[Nocturne]

Sadly there is no "correct" answer to this kind of question... Really you have to weigh up certain factors and then work around them, namely:

1) What platform are you developing for? This will determine what screen size is predominant (like for Steam it would be 1920x1080, for mobile you'd be looking at 720x1280, and for browsers it's probably 1366x768) as well as the general aspect ratio (16:9 is generally best, but you can go with anything!)

2) What aesthetic are you going for? If you want to use pixel art, then you will be looking ar BASE resolutions (not SCREEN resolution) of anything from 640x480 down to 120x85... if you want to use vector art, or high res pixel art then you'll generally want a base resolution of at least 1024x768 and over.

3) How do you want to scale the game? There are a few different ways to scale a game to fit different screen sizes, with the easiest being to let GMS do it for you by keeping the base aspect ratio and adding black bars to the side. Other than that you can scale everything yourself to fit the screen, and you can increase/decrease view sizes to show more/less of the game.

So, in general, you want to decide how your game is going to look first, then choose an appropriate BASE resolution and then finally setup GameMaker to scale this base resolution adequately up to the SCREEN resolution. Regardless of what you choose, there should never be any blurring of sprites or other content because of scaling. Look at other GM games and see how they deal with this (for example, check out the awesome Boss 101 as it has massive boss sprites and scales a smaller base resolution up to a full screen resolution beautifully).

 

[Odolwa]

1. At this moment in time I'm mostly focused on Steam first and browser second.

2. The game will be using pixel art as I'm aiming for something like Shovel Knight (SK). This part has me a little confused in that SK allows you to select different resolutions from high res to lower (it's available on the DS, for instance), but has been purposely made to look like a NES game. Based on this, does the art become hi-res purely by selecting a certain resolution, or sprite size or is it down to how detailed the sprite is going to look, i.e. is a SNES character sprite considered hi-res compared to a NES character sprite?

As for Base resolutions, I'm not entirely clear on this either. Up until now I was just working with 1280x720. The only way I've seen this being changed so far was in a tutorial where this was achieved with 'surface_resize(application_surface, width, height)'. Does this count as a Base resolution change, or a screen resolution change...or both?! How do I know which is which? Does GM have an option to change resolutions, or am I meant to do it manually in code?

3. As regards changing scaling, there was another tutorial I came across about this too where that was achieved by changing the values for 'view_h(/w/x/y)view' as part of a script based on mouse scrolling. The problem here is I feel unsure about what I'm scaling up, or down to, i.e. if GM does it for me, what am I aiming to achieve by poking around with it? Am I looking to just match the view I set, or am I scaling in and out until the interpolation is no longer noticeable, if that's even a thing...?

In the meantime, I've been playing around again with the values for the Plague Knight sprite in my continued efforts to match the real game counterpart. So far, I have taken the 31x31 sprite, put it into a full screen game, bordered (via GM) and interpolated, with a view set at 400x225 (400/225 = 1.77776 by the way, i.e. 16:9 scaling (does that even matter though?)).

When I compile, the dimensions are basically spot on, but the sprite appears a little more fuzzy than in the actual game. Does this suggest an issue with scaling, or am I going about this all wrong? If I can get this right, it might make everything else I'm trying to figure out a bit easier to understand.

 

[Nocturne]

I wrote some articles about scaling a while back...

https://www.yoyogames.com/blog/65/scaling-for-devices-part-1-the-gui-layer
https://www.yoyogames.com/blog/66/scaling-for-devices-part-2-the-game-view
https://www.yoyogames.com/blog/67/scaling-for-html5

Have read over them. They are for GM:S 1.4, but the concepts and methods outlined are equally applicable to GMS2 (although some of the view codes will need updated to use cameras).

 

[Odolwa]

OK, I read the articles and started an entirely new project to try out the full scale code provided in the second article. The project uses the same 31x31 sprite I've been using so far, the Create event of the sprite object uses the same scaling code you provided with the only change being the values of the base scale values (i.e. var base_w = 400; and var base_h = 225), the view and port of the only room use these same values and the room is set with a dimension of 1024x576.

Upon compiling the game for fullscreen, the sprite still has the same fuzziness it had before. I can't tell where I've gone wrong here. Can you suggest anything?

 

[hogwater]

Hopefully that's a typo and you have a 32x32 sprite.

 

[Odolwa]

The sprite I downloaded was set at that value, but even after adjusting it to 32x32 it's still fuzzy. On a side note, I've tried sprites from various games and many of them do not neatly fit the 32x32 range, so I don't know what kind of black magic they're using!

 

[hogwater]

That doesn't have anything to do with the scaling, but you're usually going to want even numbered sprite dimensions.

 

[Nocturne]

Upon compiling the game for fullscreen, the sprite still has the same fuzziness it had before. I can't tell where I've gone wrong here. Can you suggest anything?

Make sure interpolation is switched OFF in the Game Options. For pixel art you never want to have interpolation enabled...

 

[Odolwa]

Ok, so after turning off interpolation, I locked the sprite to the x/y coordinates of the mouse and started moving it around the room to test the scaling. Unfortunately, while the blurring is no longer an issue, the pixels are distorting ever so slightly as the sprite moves and when I reach the middle of the screen there is a much more pronounced shift in the distortion. The best I can describe it is something like tearing, where a line of pixels in the sprite crossing this anomaly gets compressed twice as much as anywhere else on the screen. Is there any way to deal with this?

 

[11clock]

I personally like to keep my characters between 1/15 and 1/20 of the screen height. Sometimes down to 1/30.