Sightlines

TOOLS USED: Unity, Visual Studio, Perforce, Figma, Canva, Photoshop

This project is a vertical slice of an original game idea. My goal was to practice UI implementation and design in Unity using the modern UI system (not UI Toolkit). My focus on this project was about learning how to interface with the existing system and figuring out the most efficient way to work within it. I was introduced to a new technique of building menu flows using a stack, each element representing a menu screen. Menu screens and UI widgets were built in a self-contained manner and converted into Prefabs for developer usability. Prior to starting the project I had completed a Udemy course that helped me get re-familiarized with Unity’s RectTransform anchors and pivots, as well as the animation system. Throughout the project I developed my own workflows and best practices for developing with these tools that I plan to share in a blog.

For more context about the game take a look at the pitch document I wrote included at the very bottom!

ROLES AND RESPONSIBILITIES

Created game concept. Designed UI wireframe and implemented in Unity. Programmed cross-widget communication. Setup button transition animations.

SEE SECTIONS BELOW FOR TAKEAWAYS

Unity Implementation

Each menu screen is built as a Prefab and added to this Menu Stack.

A major benefit of this workflow is that it allows the UI developer to make changes to the UI without having to check out a specific Scene. Scene merge conflicts can get very nasty, so the less developers making changes to a scene the better. Having all the UI self-contained in a Prefab gives a comfortable degree of separation that allows for smoother parallel development.

A look at one of the menu Prefabs.

Each widget is also built as a Prefab for ease of re-usability across other menu screens. A good example of this is the Footer Bar widget, which is on every menu screen. By using a Prefab, the UI developer can ensure consistency across multiple use cases.

A closer look at one of the widgets.

Each widget that needs to update its display upon given input has a script that handles updating the components. Here, references for needed components are made explicitly in the inspector via serialized fields. This approach was chosen over using a GetComponentInChildren call in script in order to add flexibility to the widget. For example, If GetComponentInChildren<Image> was used then the first child game object that has an Image component will be returned. This puts too much importance on the order of child objects which is an inefficient and unsustainable work style. Since the widgets are self-contained Prefabs, we can easily afford to make explicit references in the inspector.

Cross widget communication works like this:

The dotted lines represent event calls. When a widget is interacted with, an event is called. The root object subscribes to this event and decides which objects in its context need to take action.

Using events to handle this communication is a lot cleaner than requiring each object to be aware of one another using inspector references. Such a strategy does not scale well.

UI Design Process Work

First pass in Unity

Feedback on first pass:

title is too big, lots of lost space
skills don’t look like buttons, lack of language
skill widgets do not compliment developer icons, have their own style, are not lined up
layout rows are disjointed, breaks eye line
disjointed feeling between lobby and interaction panel, 2 layouts with different displays next to each other
developer icons are too small - that’s the whole purpose of this screen
details at top takes up a lot of space and feels very separate
too much negative space?
player lobby is too prominent, think about visual hierarchy
dev icons, skills, and descriptions all need to be contained in the same area