[📜일지] 댕댕이 서바이벌 #33 - 길찾기 Mk.2 with Job Sys.(上)

[태보미코(taebomico)]

개발일지 목록

#1 - 플레이어 기본 조작

#2 - 무기 기틀 세우기

#3 - 무기 종류 추가 및 업그레이드 구현

#4 - 기본 몬스터

#5 - 몬스터 스폰

#6 - 즉사 공격, 가까운 적 탐색, 데미지 표기

#7 - 플레이어 스텟

#8 - 성능 최적화 (움짤 주의)

#9 - Experience Point

#10 - 넉백 / 미티어 스트라이크

#11 - 경험치 및 레벨업 UI

#12 - HP / SP

#13 - 상호작용 / 타일맵

#14 - 활 무기 개선 및 추가 / 플레이어 팔로우

#15 - 패기 / 길찾기 (1)

#16 - 길찾기 (2)

#17 - 길찾기 (끝)

#18 - 맵 (1)

#19 - 맵 (2) / 공중 유닛

#20 - 맵 (3) / 실내 / 마스크

#21 - 장비 업그레이드 (1)

#22 - 장비 업그레이드 (2)

#23 - 테스트 플레이 & 중간 점검 (1)

#24 - 방패 무기

#25 - 경헝치 오브젝트 개선

#26 - UI / 길찾기 개선

#27 - 파괴 가능한 오브젝트

#27 - 미니 보스 (1)

#29 - 미니 보스 (2)

#30 - 무한 맵

#31 - 무기

#32 - 상호 작용 및 미니보스 보상 상자

잔말

마지막 일지로부터 무려 5주.

내일부터 다시 개발 시작! 이라는 글을 작성한지 4주.

댓글의 유혹에 넘어가버려 열심히 롤을 한 것이에요...

그 결과 시간 삭제.

다1~마 승급 강등 무한반복.

200포까진 찍었으나 수직 하강.

130판 더했는데 얻은 것이 없다?!

이제 진짜 롤 접음.

사실 롤 외에도 이것저것 했어.

유니티 멀티플레이어도 공부해보고...

여행 계획도 짜고...

문제 발생

지난 번(#26) 일지에서 다인 플레이를 위해 길찾기를 개선해주었어.

하지만 이번에 맵을 만들고 실사용하려니 문제가 발생했어 !

1타일 단위로 계산하다보니 작은 콜라이더와 플레이어가 한 타일 내에 있으면,

콜라이더가 플레이어의 위치가 되어 벽인식을 하지 못하게 돼.

덕분에 사진처럼 절벽 아래의 적이 절벽에 붙은 플레이어에게 곧바로 향하는 모습이야.

이를 해결하기 위해 1타일을 4개의 타일로 쪼개주었어.

단순히 4타일로 타일 체크랑 범위만 수정해주면 해결돼.

하지만 이렇게 해결하면 문제가 생겨.

약 7000개의 타일 길찾기 * 땅/공중 타입 * 4인 플레이가 필요해.

그런데 지금 알고리즘으로 그걸 시도하면

내 컴퓨터 기준 빌드 후 약 3ms를 소요하게 돼.

보통 쉬지않고 움직일테니 매 프레임 계산하게 될 테고,

크지는 않지만 작지도 않은 문제라고 생각했어.

따라서 해결책으로 생각한 것은 두가지.

1. 길찾기 알고리즘을 개선하자.

2. 유니티 잡 시스템을 사용하자.

먼저 1번이 더 쉬운 방법일테니 고민해보았어.

길찾기 알고리즘 개선

길찾기 알고리즘을 구현한 방법은 마지막 길찾기 일지에 작성되어 있으니

궁금한 사람들은 참고해보도록 해.

길찾기 시스템을 만드는데에 가장 도움이 되었던 자료부터 소개하도록 할게.

https://youtu.be/ZJZu3zLMYAc?si=Om_sn45uauBzylJu

How do vector field Pathfinding algorithm work ?

이 유튜브 자료에서 어떤 방식으로 이루어지는지 간단히 확인할 수 있어.

https://www.gdcvault.com/play/1027659/Pathing-in-Age-of-Empires

GDC 발표 ppt에서는 에이지 오브 엠파이어에서 어떤식으로 플로우 필드를 만들었는지 확인할 수 있어.

발표자료를 인용하자면, flowfield는 3단계를 거쳐서 만들어져.

1. 각 타일의 이동비용을 나타내는 Cost Field.

콜라이더 등의 이동 불가능한 부분도 체크해

2. 각 타일의 거리를 나타내는 Integration Field.

BFS를 사용해서 사진의 별부터 인접타일들을 탐색해.

3. 각 타일의 방향을 나타내는 Flow Field.

해당 타일의 근처 타일들의 거리를 종합해서 현재타일의 방향을 도출해.

내 길찾기 시스템을 보았다면 알겠지만, 나는 이 Integration Field와 Flow Field를 통합해뒀어.

내가 제일 처음에 자체적으로 알고리즘을 생각해 만들었던 길찾기는 BFS를 사용하지 않았었고,

방향 지정하는 방식을 이후 BFS 적용하여 구현하면서 그대로 가져왔거든.

Integration Field로부터 flow field를 만들어주기에는

콜라이더에 따라 벽에 비비지 않도록 방향을 지정하기 위한 조건 설정이 너무 복잡해서

내 수준에서는 힘들다고 생각했고,

BFS 알고리즘 사용 시 이렇게 성능이 개선될줄 몰라서 인접 타일을 모두 체크하기에는 힘들거라 생각했거든.

어쨌거나 결국 integration field를 만들며 flow field를 같이 만들어주다보니

다음 슬라이드의 최적화 방법을 적용하기에도 무리가 있더라고.

나는 상하좌우만 탐색해서 거리를 1로 주는데,

얘네같은 경우에는 8방향을 탐색해서 거리를 1로 주더라고.

다만 그러다보니 16가지 방향만 나오게 되나봐.

나처럼 상하좌우만 탐색하게 되면 8방향이 나오게 돼.

나는 이걸 그냥 Lerp로 두 방향 벡터의 중간을 향하도록 보간해서 방향을 설정해주었고.

얘네들은 이걸 해결하기 위해 FMM을 적용했는데,

거리를 에이코날 방정식?같은걸 이용해서 적용하나봐.

https://www.numerical-tours.com/matlab/fastmarching_0_implementing/

Dijkstra and Fast Marching Algorithms

여기에서 확인할 수 있고,

마름모 꼴로 거리가 동일하던 것이 원형과 비슷하게 거리가 동일해져.

그리고 방향벡터를 미리 캐싱해두고 flow field를 작성할 때 사용하는 것 같아.

나도 lerp가 아닌 미리 캐싱해두고 사용하면 되지 않을까 싶었는데,

내 방식으로는 벡터간 계산을 해서 캐싱해둔 값을 나오도록 하는 것이 불가능하더라고.

따라서 나는 알고리즘의 최적화는 불가능하다고 판단하였어.

위 슬라이드에는 내가 말한 것 외에도 정말 많은 최적화 기법들이 설명되어있으니 궁금한 사람들은 읽어봐.

유니티 잡 시스템 사용

결국 내 알고리즘이 구린데 개선법도 없으면 방법은 하나야.

구린 알고리즘을 더 빠르게 실행되도록 하자.

이를 실현시킬 수 있는 방법이 바로 유니티 잡 시스템을 사용하는거야.

이제 이번 일지의 주제로 가보자.

유니티 Job System이란?

혹시 잘못된 내용이 있다면 정정해주면 고마울 것 같아.

나도 이틀밖에 사용 안해서 잘못된 내용이 있을 수 있으니 간단히 참고만 해 !

이모저모

나와 같은 뉴비들은 dots인지 ecs인지 성능이 좋다고 하지만 와닿지 않는 내용이었어.

그러다보니 관련된 내용인 잡 시스템도 딱히 관심이 없었는데,

요번에 사용해보니 정말정말 쉽게 잘 되어있어.

나같은 뉴비도 이틀만에 기존 시스템 옮기기가 가능했어 !

다른 이야기인데 중간에 유니티 멀티플레이어도 잠깐 찍먹해봤는데 정말 쉽게 잘 되어있더라고.

그냥 컴포넌트 넣어주면 알아서 서버측이 물리 계산하고

클라이언트 측은 키네마틱으로 연산 안하고 서버로부터 결과받아 동기화하고.

문제는 요 딜레이가 있다보니 요걸 어떻게 줄여야할지 몰라서 찍먹하다 다시 내할일로 돌아오게 됐어.

어쨌든 이런저런 신기능들이 많아지고, 유용한게 꽤나 많아져서 유니티가 조금 다르게 보여!

잡 시스템

본론으로 돌아가서 잡 시스템이 무엇인지에 대해 이야기해보려 해.

물론 나는 뉴비니깐 그냥 뉴비 관점에서 이야기하는거고,

자세한 것은 기술 블로그 등을 참고하는 것이 더 좋을거야.

https://docs.unity3d.com/kr/2018.4/Manual/JobSystem.html

C# 잡 시스템 - Unity 매뉴얼

유니티의 잡 시스템은 링크 문서의 설명에 있듯이 멀티쓰레딩을 하게 해주는거야.

멀티코어, 멀티프로세스, 멀티쓰레드 등 너무나도 어려운 용어들이 있는데,

뉴비는 그런거 모르겠고 그냥 사용할래.

공학은 잘 사용하면 되는거야 !

위 링크 문서의 다음 페이지에서 설명되어 있으니 읽어보아도 좋고 간단하게 설명해볼게.

우리의 기존 방식은 혼자 열심히 여러 일들을 순서대로 일해서 끝마치는 거야.

멀티쓰레드를 이용하면 여럿이 여러 일들을 각각 동시에 수행하거나, 일 하나를 쪼개서 수행할 수 있게 돼.

위 설명대로 멀티쓰레드를 사용하면 분업이 가능하니 엄청나게 좋겠지?

하지만 장점이 있듯이 단점도 존재해.

위 예시를 이어서 설명해보면 동시에 일을 하다보니 서로 꼬인다거나

우리가 감독하러 갔더니 동시에 일하고 있으니 체크가 어렵거나...

그러다보니 개발하기가 어렵고,

어떤 프로그램 돌리려면 멀티코어보다 코어 적어도 클럭이 높은게 좋다 ! 이런 말이 나오는 거 아닐까?

즉 잡 시스템은 위 단점들은 보완해서 안전하고 쉽게 활용할 수 있도록 도와주는 친구야.

우리는 활용만 잘 하면 되니, 간단히 개념만 알고 어떻게 사용하는지 알아보도록 하자.

Job System의 사용

뉴비들은

위 예시의 일처럼 Job System에 시킬 Job,

잡 시스템에서 사용하는 변수타입인 NativeContainer,

여러 Job 사이에서 순서를 정해주거나, 모노비헤이비어에서 대기하는데 사용할 JobHandle정도만 알면 될 것 같아.

간단한 예시도 하나 만들어보도록 할게.

플레이어와 100000명의 고정된 숫자의 적의 거리를 구하는 예시야.

이걸 Job System으로 변환해볼거야.

빌드 후 체크해보면 다음과 같아.

약 20ms의 시간이 소요돼.

Native Container

https://docs.unity3d.com/kr/2021.3/Manual/JobSystemNativeContainer.html

NativeContainer - Unity 매뉴얼

1. 먼저 잡 시스템에서는 기본적으로 값 타입만 사용할 수 있어 !

값 타입과 참조 타입에 대해선 찾아보도록 하고

간단하게는 int, bool, float 이런 친구들과 이런 친구들만 담긴 struct 정도라고 생각하면 좋을것 같아.

즉 우리는 참조타입인 Transform이나 GameObject 같은 클래스를 전달할 수 없어.

(Transform은 유니티 추가 패키지에서 사용할 수 있도록 해주는 애가 있긴 해)

2. 그런데 우리가 보통 잡 시스템을 이용하는 이유는 거대한 데이터를 처리하기 위해서일거야.

따라서 이 거대한 데이터를 담아줄 NativeContainer라는 구조체가 존재해.

우리는 이걸 배열같은 느낌으로 사용할 수 있어.

얘는 valueType이라고 나오는데 포인터를 사용해서 그런가? 이유는 잘 모르겠어.

어쨌든 내부적으로 요 인덱서가 구현되어 있어서 우리는 배열처럼 사용하면 돼.

https://learn.microsoft.com/ko-kr/dotnet/csharp/programming-guide/indexers/using-indexers

이차원 배열같은 다차원 배열은 어떡하냐 ! 라고 한다면

array1[y][x] = array2[x + y * columnSize] 요런 식으로 해결할 수 있겠지?

3. 잡 내부에서는 읽기 전용, 쓰기 전용 애트리뷰트를 설정해줘.

읽기란건 var a = container[idx]; 요런식으로 값을 받아온단거고,

쓰기란건 container[idx] = a; 요런식으로 안에 뭐가 있든 값을 대입해주는거야.

읽고 쓰기 둘 다 한다면 해당사항은 없겠지만.

4. 얼마나 오랫동안 사용하냐에 따라 Allocator 설정하고 사용 후 Dispose.

할당자에 따라 속도가 다르다는데 솔직히 잘 모르겠고,

TempJob이나 Persistent를 사용하면 되는 것 같아.

TempJob의 경우에는 Update문 내부에서 1프레임 동안 계산하는 경우 사용하고

Update 문 마지막에 nativeContainer.Dispose(); 해주면 가비지 발생이 안하나봐.

Persistent의 경우에는 Destroy 시에 Dispose 해주면 될 것 같고.

위에서 말한 것들을 종합해서 기존 코드를 변경해볼게

사실 Job용으로 보통 사용하는 Mathmatics라는 라이브러리에 int2라는 구조체가 존재하는데 예시를 위해 하나 만들어주었어.

위에서 말한대로 Transform같은 클래스는 담아주지 못하므로 따로 위치를 저장할 배열을 만들어주었고,

그 외에는 어려울 것은 없을 것이라고 생각해.

Job

https://docs.unity3d.com/kr/2018.4/Manual/JobSystemCreatingJobs.html

잡 만들기 - Unity 매뉴얼

https://docs.unity3d.com/kr/2018.4/Manual/JobSystemSchedulingJobs.html

잡 예약 - Unity 매뉴얼

이제 우리가 시킬 일을 만들어줄 차례야.

그 일을 Job이라고 해.

1. 크게 우리가 사용할 것은 두 종류가 있는데, 하나는 Job, 나머지 하나는 ParallelFor 잡이야.

ParallelFor 잡은 size 값을 넣어주면 그 size 값 범위만큼 무작위로 접근해서 서로 나누어서 일을 끝내.

즉 1에서 100까지 result값에 더하라고 했을 때 일반 Job에서 1부터 순서대로 100까지 더했다면

ParallelFor 잡으로 만들어준다면 1~100을 무작위로 여러개의 일하는 친구들이 접근해서 result값에 각자 더하는 거지.

결국 각 요소가 서로에게 관여하지 않는다면 parallelFor 잡이 훨씬 속도가 빠르겠지?

2. 각각 IJob, IJobParallelFor을 상속받은 구조체를 선언하면 이게 잡이 돼.

이 인터페이스를 상속받으면 Execute / Execute(int idx)를 구현해줘야하고,

이것이 일하는 친구들이 자동으로 일할 부분이 돼.

3. 일을 시킬 때에는 Schedule / Schedule(사이즈, 배치카운트)로 메인쓰레드에서 실행.

ParallelFor에서는 사이즈와 배치 카운트를 넣어주면 알아서 일을 나눠서 여럿이서 수행해.

우리가 신경써줄걸 일을 나눌 크기인 배치카운트 정도인데

요건 사이즈에 따라 워커수에 따라 적당한 배치카운트가 존재하는 것 같아.

모르겠으니 32로 할게.

우리의 일은 순서가 상관없이 각 요소가 독립적이니 ParallelFor로 만들어주었어.

Point 구조체에 뺄셈도 magnitude도 없으니 추가해주도록 할게.

JobHandle

이제 일할것도 만들었으니 일을 다뤄보아야겠지?

https://docs.unity3d.com/kr/2018.4/Manual/JobSystemJobDependencies.html

JobHandle 및 종속성 - Unity 매뉴얼

1. 잡의 Schedule을 호출해 잡을 시작하면, 반환으로 JobHandle을 받아.

요 JobHandle을 사용해서 잡 간 순서를 설정해준다거나,

메인쓰레드에서 대기를 해줄 수 있어.

2. jobHandle.Complete()를 사용하여 메인쓰레드에서 대기해.

메인쓰레드라는건 우리가 유니티 스크립트 코드가 실행되는 것을 말해.

위에서 잡 시스템은 멀티쓰레드라고 이야기했으니

내가 일을 시키고 그 일은 다른 친구가 맡아서 해주고,

나는 시킨 다음 밑줄의 일을 시작할거야.

그런데 저 일의 결과값을 이용해서 다음 일을 해야할 수 있겠지?

그 때 jobHandle.Complete()를 사용하면 저 일이 끝날 때까지 나는 멈춰서 기다리게 돼.

비슷한 느낌으로는 yield return 코루틴;이나 async/await이 있을 수도 있는데,

위에서 설명한 내용을 읽었다면 다른 개념이란것을 이해할 수 있었을 거야.

유니티 잡 시스템은 여럿이서 일을 하는거고,

async/await은 혼자 일하는데 일을 순서대로 하는 것이 아닌 이거하다 저거하다 하는거지.

예를 들면, async/await은 서버로 요청을 하고 답이 올때까지 멈춰있지 않고 다른 일을 하듯이.

지식이 얕다보니 설명하기 어려운 것 같아. 부족하다면 추가 설명을 남기도록 할게.

unitask 이야기를 추가하자면,

await jobHandle; 을 해주면 해당 잡이 끝날 때까지 기다리게 돼.

요 작업은 jobHandle.isCompleted가 true가 되는지 update 시점마다 체크하게돼.

만약에 평균 프레임보다 잡이 오래걸리게 된다면 메인쓰레드가 멈춰있으니 게임이 멈춘 것처럼 보이겠지?

그런 경우에는 위 isCompleted속성을 이용해 코루틴에서 yield return null;을 해서 완료를 대기시킬 수도 있을거야.

3. JobHandle.CombineDependency로 묶어주거나 Schedule 함수에 넣어 순서를 줄 수 있어.

job1과 job2가 있을 때 이 두 일이 끝난 뒤에 메인쓰레드가 진행되야 할 수도 있을거야.

job1Handle.complete(); job2Handle.complete(); 요런 식으로 대기시켜도 되겠지만

JobHandle.CombineDependency(job1Handle, job2Handle).Complete();
요런식으로 기다려 줄수도 있겠지?

또는 job1을 끝내고 job2를 해야하는경우

var job1handle = job1.schedule();

var job2handle = job2.schedule(job1handle);

job2handle.complete();

요런 식으로 작성해서 잡 간 순서를 보장해줄 수도 있을거야.

요걸 종합해서 완성된 코드를 작성해볼게.

이제 실행시켜보도록 하자.

위에서 약 20ms의 소요시간이 걸렸었는데 지금 걸린 시간은

7ms로 70%가 감소했어 !

프로파일러의 아래 잡이라는 곳을 보면

메인 쓰레드에서는 저 잡이 complete 되기까지 0.461ms를 대기했고,

각 잡들의 항목을 눌러보면 0.46ms정도씩 소요한 것을 확인할 수 있어.

앞 부분에 idle이 길게 있는데 아무것도 안하고 놀았다는 거야.

저 동안은 우리는 position을 nativearray에 넣어주는 작업 10만번을 하고 있었겠지.

요 작업도 job에서 한다면 더 단축되겠지?

그 부분은 parallelforTransform이라는 친구로 해결할 수 있는 것 같고, 궁금하다면 시도해보도록 해.

나는 다음 내용으로 넘어가도록 할게.

Burst

사실 또 하나의 중요한 작업이 있어.

바로 Burst 컴파일 속성을 붙여주는거야.

위에 속성 하나만 붙여주면 끝이야!

마지막으로 유니티 에디터 위 메뉴에서 Jobs 메뉴의 Enable Burst를 켜주면 돼.

없다면 버스트 패키지 설치해줘야하고.

우린 얘가 뭘 하는 애인지는 우리같은 뉴비는 몰라도 되고 그냥 컴파일을 더 최적화 해준다나봐.

그럼이제 다시 빌드하고 체크해보자.

체크해보면 0.46ms 걸리던 친구들이

0.034ms밖에 걸리지 않는다는 것을 확인할 수 있어.

거의 90%이상 감소했어.

즉 우리의 작업은 20ms 중 7ms로 감소했으니

일반적으로 했다면 13ms의 작업이었던 건데

이게 0.034ms로 감소했다는 의미야.

13ms -> 0.034ms.

정말 놀랍지 않니?

단순 데이터 처리를 하는 작업에 적용해준다면

어렵지도 않고 간단하게 정말 큰 성능 개선이 될 거야.

끝

사실 내가 작성한게 맞는 내용인지 확신은 가지 않지만

일단 굉장히 성능이 향상된다는 건 알 수 있을 것이라 생각해.

글이 길어지다보니 내가 적용한 내용은 다음 일지에서 작성하도록 할게.

도움이 되었다면 좋겠어 !

IJobParallelForTransform 사용 결과

위 매 프레임 TransformAccessArray 생성 시 당연하게도 최악의 성능. 총 35ms소요

아래 Awake에서 미리 담아뒀을 경우. 총 2.5ms 소요

사진 업로드가 pc에선 잘 안되서 패스...

결론 - ParallelForTransform로 변경 시 6ms => 2.5ms가 되긴 하지만,

배열 크기나 내부 요소가 자주 변동되는 경우에는 사용에 제약이 있을 듯 하다.

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[태보미(taebomi)]

마즘. 글 작성하는데 2시간 정도 걸려서 힘들어져가지고 본문에 한번 시도해 봐! 라고 작성했는데 그냥 한김에 마저 해서 추가해보겠음 ㅠㅠㅠ

[태보미(taebomi)]

해보니깐 확실히 2배정도 빨라지는 것 같긴 한데 요소 변동 없을 때만 사용하기 좋을 것 같음. 기존에 매 프레임마다 position값 nativearray에 전부 복사해주듯이 transformaccessarray 생성자에 transform배열 넣고 초기화해주면 훨씬 느린듯.

[개발용더미(sy1mn1t4y83k)]

개고수..

[태보미(taebomi)]

[에뚜(ssss4610)]

성능 확실하네

[태보미(taebomi)]

[흉황(smk4397)]

[태보미(taebomi)]

[bowmore(qcs5jom3x9tq)]

[태보미(taebomi)]

[ㅇㅇ 1(106.102)]

진짜 초고수...

[태보미(taebomi)]

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[태보미(taebomi)]

유니티가 되게 잘되어있음! 알아야할게 본문에 나온 3개고 요거 그냥 갖다쓰면 끝이고 길찾기는 예전에 이미 다 구현은 했었으니 약간 데이터지향적인 마인드?로 변환하면 생각보다 간단함. 갓니티인듯

[얀테이(lose7560)]

[태보미(taebomi)]

[ㅇㅇ 2(183.109)]

[태보미(taebomi)]

[불타는키보드(1bnmaker)]

[태보미(taebomi)]

[호롤롤로(59.9)]

쌉고수!

[호롤롤로(59.9)]

[태보미(taebomi)]

[카퍠인(happys96)]

진짜 족고수ㄷㄷ - dc App

[태보미(taebomi)]

뉴비인거에요!!!!!!!!!!

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[태보미(taebomi)]

[ㅇㅇ 3(121.149)]

TempJob이나 Persistent가 속도가 다르다는데 솔직히 잘 모르겠고 =>
https://docs.unity3d.com/Packages/com.unity.collections@2.2/manual/performance-comparison-allocators.html

[ㅇㅇ 3(121.149)]

정성스런 일지 감사 예전에 님 일지에서 도움도 받았음

[태보미(taebomi)]

요쪽 문서에 있었다니.. 확실히 더 빠르다고 할 정도의 차이가 있네요. 피드백 감사합니다 !

[ㅇㅇ 4(61.253)]

잘 몰라서 그런데 저거 job system이 결국 synchronized concurrency인 거죠? multithreading이 아니라 multiprocessing 아님? 진짜 모름.

[태보미(taebomi)]

아뇨. 문서 읽어보시는게 더 정확히 아시겠지만, 병렬 처리됩니다.

[^ㅇ^(221.163)]

정말 감사합니다. 당신의 일지가 저에게 조금이나마 도움이 되었습니다. 계속 응원할게요

[태보미(taebomi)]

도움이 되었다니 다행이네요 ! 감사합니다 ! 앞으로도 힘내는거에요