04. Working with UI Team

⚠️ Important: Ensure you’ve completed everything in Wiki Section 1: Prerequisites and Wiki Section 2: Local Cloning Guide before proceeding to make sure you have the project setupped and ready.

Important notes

• If you don't have the rights to push changes into the remote repository send a message with your GitHub name included either to Niko (@BillTheBeast on Discord) or Helena (@Psykkis) and we'll fix the issue
• The main branch is intended to be protected from direct pushes, therefore all changes should be made into a separate feature branch and then merged through a PR into the main. (This will be explained later.)
• Remember to pull changes from the remote preferably daily in order to keep your local end of the project up-to-date. This helps reduce potential conflicts and makes sure the background tools and scripts should stay up to date.
• If you are using GitHub Desktop it, by default, doesn't have rebasing pulled commits enabled. This page shows how to enable it

📆 Project meetings

The main UI team meeting is each Monday at 10:00, if you can't make it to the meeting preferably send a message to Niko (@BillTheBeast on Discord)

Each sub team should preferably have one meeting with the UILead (Niko) each week, mainly to keep the leadership up-to-date with how things are going and to provide suggestions and corrections on things that have been done.

The meeting with the entire team (including battle-team, back-end, artists, web-site) is every week at 11:00 on Wednesday, and while it is recommended to be at that meeting, you can skip it if need be if you were at the Mondays meeting.

📄 Basic workflow

Start a new task

1. Make sure that you are on the main branch
2. pull from main
3. create your own branch based on main
   • Double check that you are on the branch that you just created
4. you are ready to start working on your task

Working on your task

• Check if the main branch has new changes and if so, then pull the changes and then merge them to your feature branch.
  • On Github Desktop you can do this by selecting the Update from main from the top bar.
    • Just make sure you are on your own branch.
• Commit early, commit often!
• Also remember that commiting a change doesn't automatically put into remote for others to see, use and test.
  • Remember to push them after commiting the changes to your local repository.
    • In Github Desktop this is done by pressing the Push Origin button on the top bar.
    • There should be an arrow upwards next to it if you have changes you haven't pushed, arrow downwards means that there are changes in the remote that are yet to be pulled to your computer.
  • Also remember that if there are changes in the remote then they have to be pulled first and you have to press the button again after that to push your changes.

Finishing your task

1. Create a pull request
2. Wait for someone to review your pull request before merging to main.

---

Branching

Primary Branch

We primarily use main branch for development.

Use the following naming scheme for the branches for the branches you create: UI/section you work on/changetype/name of the change you are working on

Feature Branches

Create a feature branch for every feature you are working on. for example UI/CharacterGallery/feature/CharacterSelection

• Make sure you are on the main branch before creating a feature branch
  • Make sure that you choose the main branch as the base branch when using GitHub desktop

Fix Branch

Fix prefix is used for bug fixes UI/CharacterGallery/fix/WindowScaling

Refractor Branch

To mark that the branch is used for a refractoring a section of the code or UI UI/CharacterGallery/refractor/CharacterModificationPage

---

Working with Unity

Here are some notes about working with Unity that I haven't categorised yet.

You can differ from these notes if you know what you are doing and can explain why you are doing so.

Editor

• Don't use Sprite Renderers but Images
  • Sprite renderers are intended to be used in the actual gamestate (ie. battle) but in the UI we should use Images to show our interface we have created to the player.
• Don't change the scaling of a gameobject from 1.
  • This causes a lot of issues usually since this also affects the position deltas of where the image should be placed in.
• Remember to set the anchors for the UI gameobjects as otherwise the window and the objects won't scale properly with changes to the window size.
  • Just remember that the anchor the object tries to use are based on the size and coordinates to the parent gameobject it is placed under.

Code things

• Remember that in code the Start method is called only once when the object is created.
  • Also remember that Start is the last thing called before the object starts processing the update loop.
  • Both OnEnable and Awake are called before Start.
• Try to avoid using Update unless necessary.
  • In most cases there is no need to call a code every single frame but only when needed.
• You can get each child object of a parent by putting the transform of the parent into a foreach loop. foreach(Transform child in parentTransform){}
• Try to avoid hardcoding references to other scripts and gameobjects.
  • This can be fine while you are testing something but the references can easily break if the location of the object or script changes.

---

• Data about the player and their account is stored inside PlayerData class.
• Data about the clan player is in is stored inside ClanData class.

Both of these can be accessed through the StoreFront script. ie. StoreFront.Get().GetPlayerData(GameConfig.Get().PlayerSettings.PlayerGuid,p => playerData = p);

Extra notes

fontit löytyy: Altzone>Resources>AllowedFonts assetista, mutta näin lyhyesti WorkSans fontit on ne, joita on tällä hetkellä tarkoitus käyttää

ollaan tekemässä mobiilipeliä joka vaati erilaisen tavan käsitellä laitetta käyttävän henkilön syötettä kuin PC:llä hiiren kanssa