# Dynamic shop deals in Text Express
## Analysis
> *Problem analysis, Literature study, Document analysis, Domain modelling, Best good and bad practices*
### Current situation
Text Express contains a shop, which offers different deals. This is important for the organic growth and retention of the game, as there will be a different, personal deal every day and therefore more people would be interested in starting the game every day to see what new stuff are for sale. However, currently, in the Text Express, there are only hard-coded deals and for each new deal added or changed, an update of the game would be required. This makes the shop deals functionality very limited and slow to work with.
The latter shop deal is defined in Playfab. From Playfab, a designer can introduce a change of the price of the deal and the number of currencies offered in that deal. Then the text (amount and price) would update and appear correctly in the game shop.
However, if the ''coins'' are removed from the deal or replaced with another type of in-game reward, the deal would not update graphically correctly and a new update of the game would be required to showcase this change.
### Graduation Assignment
Provide a system to allow the correct representation of a deal in the game shop, no matter what data is provided dynamically in Playfab, using the given layout templates:
### Clarifications
#### *How deep should we go with the flexibility of the deals?*
After analyzing the given templates I noticed that there could be either one with currencies only or one with customization items only. As I would want to do this as flexibly, as possible I would imagine that Text Express's designer would like to sell ***customization items*** AND ***currencies*** all in one deal.
In order to receive more information on this, I addressed the designer of the game. In the end, he suggested that we do first "currency only" and "customization items only" deals and that later on, we will create more template assets for more situations.
#### *How to do it with Playfab?*
In order to know what is the best way to achieve dynamic and flexible deals, I did [research to understand how the current deals were set up in Playfab](/social-and-community-features-in-text-express/research/how-in-game-shop-deals-work.md). After this research, I understood that the in-game shop deals are directly configured from Playfab's **Store section**, where there is a place for including extra JSON formated data (custom data), which is received from the client as well.
#### **What is currently implemented *****in Text Express and how is it set up?***
All shop deals in the game already had functionality for handling the purchase, updating the price and showing the deal in the shop, but their GUI was always hard-coded.
## Design
> *Design pattern research, Decomposition, IT Architecture Scetching, Explore user requirements, Brainstorming, Prototyping*
### Control over single elements design
Having the opportunity to write custom data for each specific deal, gives a lot of advantages. In the layout templates, which were given to use as a requirement, could be seen that there is all kind of different elements. By dissecting the layout templates, those different elements were grouped and thus seen how they could be dynamically controlled as well.
#### Control over text fields
In order to make it as flexible as possible I've made each of those elements possible to control via the custom data JSON. After a library reseach It was found out that Unity's text objects support being [stylized the same as you stylize an HTML string](https://docs.unity3d.com/560/Documentation/Manual/StyledText.html). This allowed to defining the color, style and font of the text all from the JSON file.
###
#### Control over sprites
As later on there could be several UI templates for **currencies** and several templates for **customization items**, in the JSON data I've added a field which explicitly defines which template to be used. For proof of concept I've mirrored the **currencies** deal:
This extra diversity option was approved and "enthusiastically :)" appreciated by the lead designer of the game:
#### Control over the discount badge
In every template shop deal there was also a discount badge, showing that this price was currently cheaper than before. This had to be also controlled via the dynamic system, given as an assignment.
Again via the JSON Custom data when creating the deal I added a **discount** field, which will control how much the deal was cheaper. Either the discount in percentages or the old price had to be given and the rest could have been calculated in the game. Therefore, I asked my design mentor for preferences, as he would be the one creating the deals.
#### Overall JSON design
This led to having a field for each element from the deal template in the JSON Custom data, so that whatever you write in, it will appear in the in-game deal.
After figuring out how the deals could have their GUI be dynamically controlled via the custom data in Playfab, a solution for reading this JSON string and using its data in the game had to be found.
### Classes design
By following the [SOLID ](https://en.wikipedia.org/wiki/SOLID)principle for "Dependency Inversion" a class diagram was designed, in which the main functionality of a shop item (handling the purchase, etc.), will be separated from the GUI functionality which had to be implemented.
In the latter design there will be one dynamic prefab, which will have its background and elements change depending on what data is received from the Playfab deal. This way the **TXShopItem** class will be the high-level module responsible for the main functionality of the TX deals and knowing nothing about the GUI handling and the **TXShopOffer** will be the low-level module, knowing about the main functionality of the TX deals but also handling the GUI. This way deals, which don't need dynamic GUI handling will use **TXShopItem** and deals which have dynamic GUI will use **TXShopOffer**.
After having this design created and approved after revision from the company technical and design mentors, it was time to implement it.
## Realization
> *Design pattern research, IT Architecture scetching, Code review, Usability testing*
#### Classes segregation
While implementing the **TXShopOffer** class responsible for the dynamic GUI of a deal, I started noticing that the class became very big.
That is why I have researched possible solutions for such issues and found the SOLID **segregation principle**. That resulted in implementing its theory by splitting that class and prefab into several classes, each responsible for its own type of prefab- one for customization items, one for currency items.
Later on, if new deals are created, a new class will be implemented, rather than just infinitely extending one class:
#### Sprite provider
During the creation of the classes it was noticed that a lot of the needed sprites for the graphics were the same, for example in both layout templates it was required a sprite for:
1. Coins (the main currency of the game)
2. Characters presenting the deal (both deals could have the same characters)
3\. Chests (containers that represent a bunch of items)
Again following the SOLID- **single responsibility** principle and with the view to reduce the number of references in all classes and also improve the ease of creating a new template for a deal, I have created a specific class only responsible for providing the sprites, which will be needed in all deals.
#### Discount calculation formula
When implementing the handling of the discount of a deal, 2 problems of the design I have created appeared:
1. When you write the old price, you may accidentally write a price lower than the current price. In that case the percentages will positive as if the deal is now with a higher price. Creating the opposite effect of the feature- pushing away people from buying the deal, rather than attracting them.
2. When we set a deal selling it for real money, the system is using **USD** as the main currency. However, if this deal is presented in a country with a currency different than **USD,** the price of the deal will be completely different. Therefore, setting the **oldPrice** field in the JSON Custom data is not a possibility at all.
In order to tackle those issues, I've changed the field in the JSON to **discount** and there the designer would have to write the percentage the deal price is reduced. With that percentage, the old price is calculated with the following piece of code and everything appears correct, no matter the local currency of each country.
#### Additional products
In the end, after testing and having the system for dynamic shop offers good and running, I have created a user manual (guide), explaining the flow, which had to be followed in order to create a shop deal in the game, as well as all the different dynamic elements you can control via the custom data of the deal:
{% file src="/files/-MYQB6zjKqtLo9b8mk\_P" %}
User manual on creating and designing shop deals in Text Express
{% endfile %}
## Evaluation
> *Product review, Brainstorming*
Until now there were only hard-coded deals in Text Express and upon creating a new deal, a new update of the game would have to be required. Not anymore! Test Express now supports several templates for deals, which can be changed all dynamically from Playfab. Everyone can create a new deal very easily following a user manual.
In order to achieve all that core programming principles were followed, in order to provide flexible, easily extendable and readable code. Several iterations of design were done to get to the best possible and most useful way of creating deals.
When the feature was done a review was held, where I got to present what I have done and achieved:
{% content-ref url="/pages/-MXco3I73F0lTWvVCgvF" %}
[Dynamic shop deals - TX Review](/social-and-community-features-in-text-express/videos/dynamic-shop-deals-tx-review.md)
{% endcontent-ref %}
After the feature was released in the public build, it has been used by the designer to change, customize and dynamically tweak shop deals in Text Express. The designer of the game said that**:** *Having this ability to constantly tweak and improve the in-game offers, will lead to a larger player base as it allows easier testing on what people like seeing in the shop, and therefore more purchases being made and more satisfied players.*
### For the future:
In order to improve the deals further, an example improvement would be to add a field in the JSON Custom data, called **unlockLevel.** Then the deal would unlock only after you have unlocked this level. This would provide even more control over the deals, allowing a designer to create several deals once and they will appear automatically when needed.
Although this would be a great feature, in order to implement it, it would take a lot of time to configure the game to support it and this time is not available for me as my next assignment was to implement Social Authentication in Text Express, which is a prerequisite for any kind of social interaction:
{% content-ref url="/pages/-MXRRbfkZ-EZ1-tp6\_V1" %}
[Social Authentication in Text Express](/social-and-community-features-in-text-express/features/social-authentication-in-text-expess.md)
{% endcontent-ref %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://lyudmil.gitbook.io/social-and-community-features-in-text-express/features/dynamic-iap-shop-deals.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.