Automation approach for Unity based multi-player card game

-- When it comes to Unity-based[3] applications, there are very few tools in the market that may be viable as an option to test out journey-based games with components that are predictable in the game but what about unpredictable games like solitaire, rummy? There are tools that make components of the Unity application visible which can be validated using the unique ids but this isn't the case for a game with only cards and especially when we don't know the state of the game and the deck layout. This paper discusses the approach to bring efficient, generic, and reusable solutions for challenges while automating the logic validation of a card game layout for each move done. The automation approach spans the following areas: 1) The mechanism for detecting the native elements 2) Approach for customizing the element names and ids uniquely 3) Automating the game as per the standard logic by creating separate functions that take native objects as parameters. The benefit of this automation approach is that it runs on any device/emulator irrespective of the varying screen size and resolutions and across whatever the deck layout maybe. The client is done on python with a Unity platform support tool "AirtestIDE''[1] developed by NetEase[2] and the element detection is done through Poco[4] manager. We customized the element ids for each card with precision considering the attributes that will be required to carry out the automation flow.


INTRODUCTION
An application that has predictable user-based flows available on the UI is easy to automate, unlike solitaire that requires extensive use of card logics and sequences to test out the game move scenarios. The automation done for a card-based game developed on a Unity platform is not only difficult to automate in terms of the platform used but also for understanding the underlying approach for getting the logic right for move validation in the game. There is no known prediction for the game deck at any point in time. Therefore, this may boil down to the question of how is the validation carried out? To overcome this major roadblock, the proposed methodologies were 1)to customize the elements that were visible in the IDE as per the card suit, rank, and the card face visibility 2) to divide the game board into different regions where the cards are bundled/arranged 3)to create small utilities per se modules that are called to get the information related to the card/card bundle as per the customized element details provided during game development, this approach makes it easier to handle the unpredictable behaviour of the game. This approach was developed with a vision to have a unified automation code that could be used to run functional test suites for validating client and server logic of any gameplay. II.

LITERATURE SURVEY
The major building block that drove the logical validation of the game was element recognition and customization which covered the basic  We need to recognize the elements i.e. the cards and the card region so that we can just get the information of the movement of the cards from the source to the destination to validate the game logic.  The application is built using the naming conventions containing the card-related information.  Each card objects are categorized as per the uniqueness of each card in the card deck with each name containing the card suit (Diamonds, Clubs, Hearts, Spades), card rank (A,2,3,4,5,6,7,8,9, J, Q, K), card colour (Red, Black). Regions for card locations are defined and dynamically the regions' objects are assigned to the cards once card movement happens.  Movements of the cards validated if the logical placing is correct or not with defined expected results and the actual results after movement.  To ensure the sync of the server and client movements, the server response after each successful client movement is tracked down and passed to the IDE through an interface. The client and the server movements are validated if they are in sync. { "cardColumnPosition": "Tableau",  The region where the card lies in the table "cardColumn": "Tableau0",  The column within the region "columnChild": 0,  The node within the column where card lies "properties": { "value": "A",  The rank of the card from A to K (13 values) "suit": "Spades",  The suits (Diamonds, Clubs, Hearts, Spades) "faceUp": "true",  The card face visibility to user "colour": "Black"  The colours (Red, Black) } } Below are some tools based on the element object-based recognition, discussed for Unity application.

AirtestIDE:
 AirtestIDE is an open-source testing tool by NetEase which is useful for detecting elements in a Unity-based application. This makes use of the Poco manager to detect the element objects and also for the actions performed on the application.  It has an inbuilt ADB connection which allows any device to be easily connected for running the application under test. It also has a remote connection to connect to cloud/non-cloud port for emulators  It supports various platforms and for our use case it has a Poco assistant that helps in getting the object reference of the objects on the screen for Unity based applications  It supports only python client for scripting 2. Object-based Recognition: Object-based Recognition involves capturing the properties or attributes of the visible elements in the current frame like visible text, unique identifier, etc., Object-based Recognition allows using more than a single attribute for identifying the element uniquely, like using XPath and thus making less error-prone in locating the visible element in the currently visible frame.
Limitations: • Mechanism to read the properties or attributes of the visible element in the current frame is required.

III. SOLUTION BY JUNGLEEGAMES:
The approach for automation is to create a communication channel between the Unity platform and the Airtest. The approach for automation is to provide the objects library. We achieved this by utilizing an open-source SDK manager called "Poco". This library lets us get access to the elements object references, and properties. Once this is integrated into the game project then the initialization of the Poco manager happens during the game launch.
The device is connected to the Airtest IDE via ADB connection and we are ready to create a new project on the IDE. The game properties are accessed from the game with the help of the hierarchy manager in the Airtest ide.
The approach for automation is to provide the object of the source and the destination when a card movement happens. The elements are recognized by the Poco manager and the customized attribute values are available for testing. The Poco manager returns all the data properties as per the visible elements in the current frame. We access certain properties of the elements to define the navigation from one point to another as per our requirement. "The manipulation of the size" and the orientation of elements also can be done with the predefined Poco libraries.
There were some cons w.r.t the Airtest ide: 1. All the properties of an element are inaccessible. We overcame this by supplying all the data for the particular element into one of the data attributes of the element which we made accessible using Poco object.