Effective Title: UI in AAA with God Of War
GDC Year: 2023
3 main topics:
How UI is built in the Santa Monica Studio (SMS)
How different UI screens were created
Lessons learned from the 2018 God of War for Sequal
How UI is built in SMS?
11 people are in charge of making the UI system for God of War Ragnarök.
Normally takes around 2 people to build UI. 3D art support and Technical designer in charge.
In SMS they also had 2D artists to help with creating concepts and sketching out basic design ideas for the UI. They also had a UX designer original from Naughty Dog.
How does the engine work?
Everything in the game is preallocated into Waddef.
Waddef is a data type used in the engine for SMS which was meant to store information.
A level is considered a Waddef. Some of the bigger areas will take up multiple of these Waddef.
Some Waddef is permanently active as it is information that the game constantly needs to access and use. Includes UI elements and information.
Even though the studio UI assets are set up principally in 2D they work in the 3D editor of Maya and a camera system. Normally just use a 2D system for UI which increases the difficulty.
Working through Maya helps utilize certain more optimized features that can be seen in the 3D space. Specifically when trying to polish the UI assets and implement fancier items.
They use a scripting API that helps search for specific items in the Waddef.
Using Lau for the tech workflow.
How data is managed in AAA?
Most people working with Unity are used to dealing with storing data in Inspector and attaching it to specific scripts. This means that the data is stored dynamically instead of in a static fashion.
This can lead to problems where working on a scene will change how data is stored constantly. Having two people working at the same time will cause conflict when trying to merge two builds together.
However, AAA studios will instead work with more static data. Helps when multiple people are working on the same file or section as there is less of a chance for conflict in merges.
Well, this is a relief to know what is one of the likely causes of merge errors that I had previously encountered before when doing group projects.
To put it in lamen terms Unity will attempt to save the project within certain areas but not care about specifics. Each scene in Unity takes up a certain amount of space in the designated Unity project area. The problem is if two people are working on one scene and by extension a specific subsection of the storage area and save their changes then Unity has a high chance of saving two different changes in the same spot. Combining those changes will cause problems as the version control might not be able to determine which of the two items to save there and where to place the other one.
Imagine having a cardboard box that is meant to fit one (1) item where the item fits perfectly into the cardboard box. Well, it would be very easy to fit two (2) of the same items at the same time into the box. They dont fit very well.
The solution to this is making more information statically placed as in designating specific areas for specific information. It's like saying a specific cardboard box is only used for small toys. That way you know to expect small toys if you open them later and a bit annoyed if it is something else
The static data (Usually done in JSON or similar data language) is then read by the code to efficiently run the saved data. Usually through the game engine and can run efficiently and quickly compared to having it run more dynamically.
The UI team worked one level above the engine but allowed for flexibility and running as efficiently as possible.
Comparison God of War 2018 Vs God Of War: Ragnarök
5 Realms Vs 10 Realms
88 Skills vs 132 skills
Some accessibility options vs 65+ options
Around 60k lines of Lua vs 105k lines of Lua
58 MB of memory for both games
Utilities, HUD, Menus
Utilities:
Out of box experience (OOBE)
Inspiration from Naughty Dog.
Giving the player the option to choose once they start the game instead of waiting for them to get past the start menu.
Quick option if they didn't care about menu options and wanted the recommended values or allowing them to go through all the options.
The largest Lua file was for settings as they needed to create all of the options and data values for the settings. Around 6000 lines just setting up the settings info. Ideally, instead, you use some other static way of saving the information.
They realized the options given by Naughty Dog for accessibility had grown so much and it had become tiresome and annoying to use. Instead, they decided to make some presets that would fit various types of people's needs. The groups they concentrated on were as follows: Vision, Hearing, Motion Reduction, and Motor accessibility.
This allowed people to more easily have the settings they wanted without taking the time to test each option to find the optimal setting combination.
The main menu setup was the same as the previous game where starting the game would allow the player to quickly start from the start of the game without needing to go through any loading screen.
The team didn't expect the challenges that came with setting up the review video of the previous game events as they needed to deal with how the engine would process video. This is because the engine is preallocating the data for video processing. They could only have 1280X720 but stretching the video and adding the fire effects allowed the video to look better without needing to do a lot to the engine itself.
The takeaway from the team was to pick when to fight the engine for more power or abilities. Doing so with the video would have cost a lot more memory and time as well as possibly breaking other areas of the game that required that memory allocation.
When supporting more options in the setting menu it can get confusing how to properly categorize many of the settings so that people have an understanding of where to go. What was decided was to use a combination of common categories as well as new options that would help guide the players.
Sometimes the team would place the same setting in two categories as play testing would reveal that these were features that people might find useful and want under one while others might never visit that category but still wish to use the available settings option.
Also helped to find some options that seemed harder to find than others.
Set up basic color changes for any settings that had been changed by the player allowing for them to more easily recognise what had been affected by the player.
Full controller remapping is a major issue that people ask for when it comes to accessibility.
The indie scene does not always have the resources to set up proper controller remapping. An example given of how they thought Indies created interesting accessibility options is Celeste. They can give various options that would allow for accessibility while not needing to present the amount seen in God of War.
The UI team also worked on the tutorials for the game through different UI prompts that would appear at appropriate times.
Effective tutorials through UI:
Make sure to teach them consistently. An example would be using the same pop-up in the same area so that players know where to look if they are doing something new or if they see something appears there they understand it is a tutorial instead of something else.
Make sure you're teaching one thing at a time. This is because if the player feels bombarded with mechanics to learn they might have challenges learning them and stop playing.
For sequels, it is important to give players a few seconds before showing the tutorial for a few seconds. This way if players have already played the previous game(s) they might remember what buttons to press or what to do. It would be important that the same or similar button layout exists from the previous game. However, the player may have changed it in the accessibility menu.
Try to find visual aids for UI buttons as it helps people know exactly where to look for the tutorial. This means players don't feel like they are wasting time in a useless scavenger hunt for a menu button or icon.
Limiting player input and keeping it brief will allow players to not spend too much time in a specific menu and forget what they learned as well as not get confused trying to remember the 20 previous buttons they had to press to finish the tutorial.
Fonts:
Use two main fonts for the game.
The first one is the header font which is stylized to better fit the game artistically. This one was called Berserker for God of War. Only really used for the title of the game and when entering a new area.
The second font works as the body font and the main one is used for most of the game. The font must be chosen that allows for readability.
God of War used the following fonts for different languages (As part of their localization efforts):
English, French, Italian, German, and Spanish (EFIGS Languages, which are the main Western languages): Gill Sans WGL
Arabic: FS Albert Arabic
Thai: SST Thai
Japanese: Likurei Std
Korean: Arial Unicode MS
Chinese S: M XiangHe Hei SC Pro
Chinese T: M XiangHe Hei TC
Also implemented a custom icon font which allowed for improved memory as they loaded all the icons as if they were font letters and only needed to call a single Unicode value.
Allowed macros for writers to have an easier time calling the different icons when setting up text.
How does SMS plan on using fonts in future games?
Currently, they scrap each glyph and font that is used in-game and are placed on a font file. Each file for each language is saved in their own Waddef and they are switched when changing the language of the game.
However, this would limit the available memory to the UI team if they tried to get more than three of these font sheets implemented.
A solution they want to try and implement is using GPU rendering to improve space usage. Instead of font, they would put a .ttf file. An example is the system called Slug which does this. Allows for more variety in font styles and features that the UI team might want to try out. Would also allow for emojis and colors.
HUD:
The story is meant to be the main driver at the studio when making new games.
The UI team's goal was to try and minimize the UI to help not impede the player from experiencing the game and enjoying all of the features. But this may affect the UX as there may be important information they need to deliver.
The main difference between God of War 2018 and Ragnarök is the notification system for items and events. Used a global queue to present all of the information one at a time. They realized this could cause problems over time as some areas would give too many items meaning that there would be a lot of time between the start and the end.
The future goal is to have multiple queues running depending on the area of the screen to reduce wait times and not have the player need to wait sometime before ending. Can be useful for speedrunning as they might finish a quest that gives a lot of items and reaching the next important item too soon means they won't have the UI confirmation fast enough and realize they lost a lot of time.
They also included supporting custom UI to help different players save time and understand where to go.
In God of War 2018 the player needed to fight until the top of a mountain to reach the portal that allowed them to switch between realms directly. Would cause problems as players might feel annoyed that the only spot where they could switch between realms didn't have a way of getting to faster.
Meanwhile, in Ragnarök, it had been moved to the gateway to allow players an easier time to visually see where they would be going as well as better represent what realms were currently closed or open. They also presented what quests would be available in each realm. This allowed players to have an easier time understanding what areas they could go to and what to do in them. Instead of needing to constantly navigate back to the quest menu.
Takeaways:
Recordings of players' games and the players themselves would improve understanding of problems. This comes down to the fact that at times people might find a problem but not know how to explain it or assume they are the problem when they can't understand something.
Try to keep the players immersed in the game not menus. If menus are simple then they can easily understand what to do and return to the game.
Try to have the UI built for scalability. You may not know when you need the UI to show multiple of an item that initially was not going to happen. Try to make sure to put constraints on what the UI can do so the rest of the team doesn't simply ask for more elements.
Learning from God of War 2018:
They wanted to improve the text scaling so that it was easier to read no matter the size.
Improve memory usage with dynamic layout.
Making the UI more understandable and easy to navigate.
2018 had very little space to show Kratos as the different tab buttons and menus took up a lot of space. This was updated in the newer God of War by moving Kratos to the side and adjusting how the UI would react depending on the layer. Menu buttons would disappear if not deciding what menu to go to giving extra space.
Made an internal rule where fonts would never be smaller than size 22 and go up from there. 60% of players now increase the size of the text UI.
But this meant the team needed to create more dynamic layouts depending on font sizes and other settings available. Most UI systems normally dont include this and require the system to be built. TIme-consuming but useful for improving localization and accessibility for users.
During navigation they implemented a zooming feature where the camera would approach or get farther away depending on the menu the players interacted with. Allowing them to understand what item or area to concentrate on as that was what they were working on.
Menus:
Case Study Enchantments:2018 allowed for long-term progression where each piece of equipment had a set of available slots that could be used to implement upgrades. This was made so that the player had to navigate to various menus to understand where their build was at any moment and see what still needed to be done to finish it.
In Ragnarök, it was updated to include the amulet system which made it easier to see what upgrades the player already had and what was missing from the build.
Case Study Skill Mods:
In the 2018 version there was an included system called “Bonus” This was meant to keep combat fresh near the end of the game. However, a lot of players didn't realize that was possible or felt it like an unnecessary chore to do especially if you're near the end when you just want to finish the game.
In Ragnarök, it was changed where skills are acquired after completing certain quests. Instead of having the bonus be a passive one the player is required to activate it to use it in the game.
Case Study Journal:
In the 2018 release of God of War, the text and images would just be rendered onto the page while in Ragnarök the text would be rendered more dynamically on the page allowing for it to appear as part of the page the player was reading.
As part of the AAA experience, the UI team was motivated to implement a system where the pages would flip as if it were an actual book.
It was challenging to have both the previous pages and future pages appear at the same time as it could easily ruin the experience for the player. They needed to work on a lot of unique assets to allow for the proper rendering when flipping the page. It was super easy for QA to break it.
Hozzászólások