search

planetarium / NineChronicles

Unity client application for Nine Chronicles, a fully decentralized idle RPG powered by the community.
https://nine-chronicles.com/
GNU Affero General Public License v3.0
349 stars 147 forks source link

Feature/stage asset load #4736

Closed eugene-doobu closed 1 month ago

eugene-doobu commented 1 month ago

Description

  1. 몬스터(스테이지)의 리소스 로딩을 로딩 타이밍중에 하도록 수정하였습니다.
  2. 스테이지 몬스터 관련해서 모호한 네이밍을 수정하였습니다. 지금도 네이밍이 모호하지 않나 생각이 드는데, 일단 추후 수정이 간편하게끔 리소스 형태별로 구분이 가는 방식으로 네이밍을 수정하였습니다.
  3. 몬스터 로드에 어드레서블을 적용하였습니다.
  4. 스테이지를 포함한 모든 배틀(Raid, Arena등)의 공통 코드를 전부 BattleRenderer에서 처리하는 것이 목표입니다.
  5. 스테이지 관련 코드의 의존성을 정리하고 있습니다. 아직 코드가 제대로 정리가 된 느낌이 아니고, TODO 주석을 굉장히 많이 달았으나 지금 동작에 문제는 없는걸로 판단되고 수정사항이 매우 커질것을 대비해 미리 pr 올립니다.

How to test

전투 테스트 후 문제가 없는지 판단합니다.

제 로컬에서 윈도우 빌드시 에셋 로드 과정에서 문제가 없는것을 확인하였는데, 어드레서블 에셋들이 제 pc어딘가에 저장되어 문제없이 로드된것인지, 빌드 자체에 어드레서블 에셋이 포함된것인지 판단이 되지 않아 모바일에서 빌드 테스트를 해봐야 할 것 같습니다.

Related Links

https://github.com/planetarium/NineChronicles/issues/4138

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6131 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +1037 -5094 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +27 -75 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +360 -245 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

jonny-jeahyunchoi commented 1 month ago

모바일 뿐만아니라 Ci 거친것도 확인해봐야될것같아요. 어드레서블 프로파일에 세팅을 로컬로 하더라도 유니티 빌드돌리기전에 어드레서블 빌드를 한번돌려서 라이브러리 폴더들을 갱신해줘야하는것으로 알고 있기는 합니다. 아마 로컬컴퓨터에서 빌드하셨던거는 어드레서블빌드를 한번돌리셔서 정상적으로 보였을가능성이 커보여요 @eugene-doobu https://docs.unity3d.com/Packages/com.unity.addressables@1.21/manual/build-scripting-start-build.html 빌드스크립트를 추가로 수정하면 일단은 workflow 수정없이 진행가능할것같아보이네요

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6131 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +1037 -5094 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +27 -75 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +360 -245 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

eugene-doobu commented 1 month ago

@jonny-jeahyunchoi windows빌드 확인했을 때 CI 빌드에도 어드레서블 에셋은 포함되어있습니다. 하지만 현재 전투 테스트는 GetActionPoint관련해서 액션 합의가 안된 느낌이라 테스트가 불가능한 상황입니다

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6077 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +962 -5115 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +294 -256 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6077 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +962 -5115 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +294 -256 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6077 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +962 -5115 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +294 -256 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

eugene-doobu commented 1 month ago
pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6077 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +962 -5115 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +294 -256 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6077 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +962 -5115 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +294 -256 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6077 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +962 -5115 Percentile : 100% Total files changed: 83 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +294 -256 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6060 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +956 -5104 Percentile : 100% Total files changed: 82 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +288 -245 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] commented 1 month ago

This PR has 6067 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

``` Label : Extra Large Size : +961 -5106 Percentile : 100% Total files changed: 84 Change summary by file extension: .meta : +18 -85 .mat : +1 -1 .asset : +503 -5 .prefab : +3 -1834 .overrideController : +0 -22 .anim : +0 -2435 .spriteatlas : +2 -0 .unity : +141 -477 .cs : +293 -247 ``` > Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean: - Fast and predictable releases to production: - Optimal size changes are more likely to be reviewed faster with fewer iterations. - Similarity in low PR complexity drives similar review times. - Review quality is likely higher as complexity is lower: - Bugs are more likely to be detected. - Code inconsistencies are more likely to be detected. - Knowledge sharing is improved within the participants: - Small portions can be assimilated better. - Better engineering practices are exercised: - Solving big problems by dividing them in well contained, smaller problems. - Exercising separation of concerns within the code changes. #### What can I do to optimize my changes - Use the PullRequestQuantifier to quantify your PR accurately - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases) - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile. - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile. - Change your engineering behaviors - For PRs that fall outside of the desired spectrum, review the details and check if: - Your PR could be split in smaller, self-contained PRs instead - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR). #### How to interpret the change counts in git diff output - One line was added: `+1 -0` - One line was deleted: `+0 -1` - One line was modified: `+1 -1` (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion) - Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.