Skip to content

Latest commit

 

History

History
34 lines (24 loc) · 2.02 KB

Unity.md

File metadata and controls

34 lines (24 loc) · 2.02 KB

Unity Guidelines

Unity Editor

Make most or all gameObjects in the scene should be prefabs, separated into logical features. This allows the team to work in parallel without merge conflicts on the scene file.

Coding

Static vs Singleton vs IService?

  • If you are writing pure functions with no data, use a static class with static methods.
  • If you have data, and your component is part of the an app, use a MonoBehaviour that implements IService, and use ServiceLocator.Get<MyService> to retrieve it.
  • If you have data, and your component is more generic (e.g. a reusable package), use a singleton. Note, singleton MonoBehaviours are quite difficult to implement correctly and efficiently.

UXML

UXML Bindings

UI binding is the act of taking a data source and applying it a user interface.

Key principles:

  1. Bindings should be simple and automatic.
  2. You should be able to view and edit all data in the editor for easy debugging.

To implement UI bindings, we use three classes:

  • Property<T> - Some data + a changed event. These can be viewed and edited in the Unity editor.
  • Derived<T, W> - Transforms an IProperty into an IProperty.
  • Bindings - a helper class which makes it easy to take data from an IProperty and apply it to a UXML element, or vice versa.>

UXML Styling

Follow utility-first patterns. Essentially, keep USS classes very small and single-purpose.

Most styles you need will are in Tailwind.uss (inspired by tailwindcss classes) or HyperStyle.uss. If you need a one-off style, create a USS file with the same name as your UXML.

UXML Workflow

The recommended workflow when building UI is to edit UXML/USS files directly and view the results in the game view. Using UI bindings, you should be able to inject data into your UI templates and see the results immediately.