Thank you! Definetly understand most of it now, I think. I had already looked up some of it and have a pixel perfect camera in Unity set to 640x360 reference resolution and 32 PPU. But I didn't think about the quoted part when creating my assets so they didn't take up quite as much of the screen as I planned to. But now I know how I can think about it while creating the assets.
Sorry, I just have some clarifications to ask regarding this and the original question (thanks FLCL, I had a lot of the same questions). I get the concept of designing a sprite to take up 10% of the screen real estate or whatever. But my question is around sprites that don't necessarily fit in a perfect 32x32 box. Say, I want a bigger sprite so I work in 64x64, but 64 doesn't perfectly divide into 360 (though, 32 also doesn't divide into 360 so maybe this isn't even a concern). Is that going to cause jitter or will it not because it's placed on an authored resolution of 360x640 and THAT'S what is scaled, everything included on there and not the individual sprites?I don't know of any videos explaining it, but I can try to explain it a little better.
Let's think about just working in one dimension to start with We'll talk about X. The same principle applies to both the X and Y axis, but trying to consider them both at the same time might be a little confusing. And, for simplicity's sake we will use easy to divide/visualise numbers, not that these would be the numbers that you would actually use in-game.
So, you're designing a level in your game, and you decide that regardless of the screen resolution that the game is being played at you want the same visible area to be displayed. That means that if someone is playing at a resolution of "100 pixels" and another person is playing at a resolution of "200 pixels", their game view should be identical, albeit stretched to fit the resolution.
The person playing at the 200px resolution would not be able to see any additional details to the left/right, compared to the 100px player.
With me so far?
So when you design an asset, you are not saying "I want this asset to be N pixels wide", instead you are saying "I want this asset to take up a certain percentage of screen space". Therefore if you decide your asset needs to be 10% of the visible width, and your "native resolution" for the game is 100px, then your asset needs to be 10px wide.
So what happens when the 200px player comes along? Obviously 10px is not 10% of 200, it's 5%, so, in order to prevent your assets from looking smaller on the 200px resolution, we instead (In the game, via the camera) draw the game scene at the native resolution (100px) and then scale that up by a factor of 2! That way your 10px asset becomes drawn over 20px, which maintains the same percentage of screen width.
This scaling factor is done based on the resolution (And should be handled automatically by the camera. This is normally done via "pixel perfect" scaling or similar) So if the target resolution was 300px, the scale factor would be 3 and so on.
What you need to decide as the designer is what the native resolution of your game is, which gives you the concept of how "big" your assets will be in-game.
The reason we say you need to be careful when deciding a native resolution, is because when working with a pixel art game you want to choose something where it can scale to other resolutions using only an integer scaling factor (1,2,3 etc.) The reason for this is because when you do so, your scaled pixel-art is guaranteed to "fit" the pixels of the target resolution. For example:
If you have pixels draw at coordinates 0->3, and you need to scale this by a factor of 2, the output is that pixels are draw at coordinates 0->6. Those coordinates relate to actual physical pixels on a monitor.
However, if you took 0->3 and attempted to scale it by a factor of 1.5 you would get coordinates of: (0, 1.5, 3, 4.5) This is bad because those decimal coordinates do not relate to an actual physical pixel on the monitor. GPU doesn't know exactly how to render that, so it will make a best-fit (Which is normally rounding). That rounding means that sometimes the pixel will be drawn only on the integer part (e.g at pixel 1) and sometimes it will render in both pixel 1 and pixel 2. THAT gives you pixel jitter.
(It is also important to note that if the camera is positioned in such a way where it is not clamped to a "pixel relative" value, you can also get pixel jitter due to the offset, but thats a story for another time)
EDIT:
I found a link that explains the issue quite well with visual examples. This is actually the exact problem I had (Started at 720 native, tried to scale up to 1080)
Scaling my pixel art platformer from 720p to 1080p
I'm developing a pixel art 2D platformer for PC and smartphone, but I'm stuck on a technical issue. I chose to have a 32x32 tile resolution, and a 64x64 character sprite resolution. The levels aregamedev.stackexchange.com
Luckily I found another way of fixing it after some heavy googling. Still not ideal but it works to the degree that people might not notice if they weren't originally aware haha!
Makes perfect sense now, thank you for the thorough explanation! Now time to rework everything in 640x360. Hopefully it doesn't break too much stuff.
I'm a pretty big fan of those sorts of combat systems. Usually they decouple your attacks and the enemy's; as in, the way the enemy attacks (and thus, whether you get hit or not) isn't the same bar system you use -- I'm thinking of Resident Evil Gaiden and Undertale / Delta Rune here, mostly, which give the enemy attacks real-time elements. But the idea of it being strictly turn-based and having both you and the enemy on a bar system is something I don't think I've ever played. It could be novel and interesting for sure.
using UnityEngine;
public class MyAnimationState : StateMachineBehaviour {
override
public void OnStateEnter (Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
base.OnStateEnter (animator, stateInfo, layerIndex);
// Do stuff.
}
override
public void OnStateExit (Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
base.OnStateExit (animator, stateInfo, layerIndex);
// Do stuff.
}
}
maybe this will help you (see how he references the soundcollection)
Thanks! I actually just solved it (forgot to call the method I made, its always little things like that that get me lol) but I will definitely read over that thread and try to gleam what info I can, I appreciate it!
#ifdef UNITY_SWITCH
Debug.Log ("I'm a Switch!");
#else
Debug.Log ("I'm not a Switch!");
#endifOh that actually looks very useful! Will circle back to it if my solution turns out to be broken.
protected float CalculatePixelPerfectPosition(float unperfectPosition)
{
//Calculate the position in pixel-space (Still a floating point number at this point)
float resolutionPosition= unperfectPosition * m_pixelsPerUnit;
//Truncate the calcualted position to an integer and store in a seperate variable
int resolutionPositionInt = Mathf.FloorToInt(resolutionPosition);
//Subtract the integer component of the resolution to get a decimal "remainder"
resolutionPosition -= resolutionPositionInt;
//If the reaminder is greater than or equal to 0.5 (half a pixel) then increase the value of the integer position
if(resolutionPosition >= 0.5)
{
resolutionPositionInt++;
}
//Convert the resolution position back into Unity co-ordinate space by multiplying by the reciprocal (1/PixelsPerUnit)
return resolutionPositionInt * m_pixelsPerUnitReciprocal;
} //Truncate the calcualted position to an integer and store in a seperate variable
int resolutionPositionInt = Mathf.FloorToInt(resolutionPosition);
//Subtract the integer component of the resolution to get a decimal "remainder"
resolutionPosition -= resolutionPositionInt;
//If the reaminder is greater than or equal to 0.5 (half a pixel) then increase the value of the integer position
if(resolutionPosition >= 0.5)
{
resolutionPositionInt++;
} int resolutionPositionInt = Mathf.RoundToInt(resolutionPosition);
Hello! All the credit for this system goes to the Doom (2016) devs, there are some cool videos and articles about this system floating around, I recommend searching for them. The great thing about this system is how simple it is to implement and how flexible it is just like Weltall Zero says. You can make different types of tokens, like ranged and melee, or for special attacks from powerful enemies that have long cooldowns. You can make enemies steal tokens from each other (like when an enemy suddenly find itself right in front of the player and needs to attack) or quickly implement a difficulty system by altering the cooldowns or the number of tokens in the system. You can also add special conditions for requesting tokens so that enemies won't attack while others are attacking...you can do a lot of cool things!
