adrianorcik / howto Goto Github PK

• A lot of popups need to be updated depending on the game state
• We didn't have an official pipeline on how don't do screens manually and reduce the duplicity of similar prefabs
• Our pipeline forced us to build similar prefabs and reference them to screens

• Create a modular UI prefab-based system able to build UI screens defined by code even in run time
• Prefab holder keep references on unified prefabs based on category such as atomic, groups, popups
• Ability to define screen template and change runtime depends on our needs and game states

• Modularity and flexibility of UI screens
• Popups generated based on the scripts or editor
• Runtime initialization
• Prefab caching

• Not stable codebase required to be re-tested almost after each code iteration
• QA time is burned by typical UI test cases

• Develop a simple UI testing tool that is able to run simple test cases and avoid basic human mistakes
• Run automatically on specific screens while QA is doing regular testing session

• Reusable test scenarios
• Run automatically on specific screens
• Various error handling
  • Button reference
  • Text or image overlaps
  • Navigation validation after button click
  • HUD bitwise validation, etc...

• UI architecture does not support any layer of UI elements management
• Each HUD element is referenced as a single or grouped game object, not flexible enough
• Features like a tutorial or specific screens required an out of box HUD layout
• HUD implementation requires a lot of redundant set active/inactive code

• Use a bitwise operation approach, each HUD element has a single bit value
• Flexibility power to define custom groups depends on our needs

• Flexibility & easy to extend
• Simple usage from code or editor
• Performance focused

• UI effects powered by the tween library what is not easy to use for non technical people for example like UI/UX people
• UI/UX designer wants to change or tweak something, the programmer is required to do changes in the code
• We haven't been able to support the UI/UX wishlist with the current implementation as well

• Developed custom UI particle tools to make UI/UX designers independent
• Support our custom UI/UX wishlist features like draw hand path or reusing scenarios

• Easy to use for non-tech people
• Ability to support our custom needs

Implementation

Linear effect

Custom draw effect

Redirect to project

• Game has a lot of customizable vehicles by skins or cargos
• For artists, it was time-consuming and not easy to use these visual tweaks in the scene

• Cargo rendering tool with the ability to preview cargos and skins
• Tool has the ability not only to preview objects but set up cargo transform as well

• Quick preview of vehicle skins and cargos
• Cargo & vehicle transform prefab override
• One change could be applied for all groups of vehicles

Redirect to the project

• Default tutorial implementation mixed with feature code, caused mess and problems in the code
• Not stable implementation produced new bugs while tried to be extended or changed
• Old implementation not flexible enough to solve D1 retention problem with changes of existing tutorial

• Modular-based system with own logic layer and kept own implementation above features code
• Support multiple tutorials and easy way how to A/B test them in the production
• Easy to implement new scenarios or modify old ones even for non-technical people
• Tutorial logic is segmented into specific components (camera, dialog, inventory) to be easily extended and maintainable

• Own logic layer, separated tutorial code from gameplay code
• Tutorial editor suitable for designers
• Ability to A/B test and improve the user onboarding
• Easy maintainable component approach

Old editor

Improved editor

Demo implementation in game

Redirect to the project

• Not exist reusable unified time-based cross-project implementation
• Missed manageable access to all timers in the game
• Every new time implementation is required to create a custom logic like events, time formats, etc

• Develop a unified timing system with the ability to use cross-projects
• Easy to use with predefined rules

• Access to all times in the game
• Support multiple time formats (count down, count up, etc)
• Events and actions ready to use

🧾 Architecture

• Hardcoded client game definitions are now enough flexible
• During development we needed to have multiple versions of definitions

• Used google sheet as main data holder with the ability to export JSON by with version by custom add-on
• Python script with the usage of google API gives as the flexibility to see what's happening on the central google drive
• Unity implementation provides easy to use interface to manipulate with this definition data

• By one click to download a game definitions
• Game definition versions

Google Sheet Add-on

Unity Definition Downloader Editor

Redirect to project