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.
Example deal in Text Express, offering you 3 types of currencies(hints, diamonds and coins) for 4,99$
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.
Asking Tj'ien- Text Express' designer for more information
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. 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.
TXShopItem- handling the main functionality of a shop deal
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.
Disection of a currency shop deal template
Disection of a customization items shop deal template
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. This allowed to defining the color, style and font of the text all from the JSON file.
Making the word "SALE" in yellow via tags for rich-text
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:
Original deal
Mirrored deal
This extra diversity option was approved and "enthusiastically :)" appreciated by the lead designer of the game:
Approval for supporting several templates for the same type of deal (in this case currency deal)
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.
Asking the designer which option does he finds easier to use when he is going to create deals
old price field in JSON Custom data of a deal
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.
Example of improved JSON Custom data of a 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 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.
1st iteration Class diagram design for dynamic prefabs handling the GUI data from Playfab
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.
TXShopOffer class starts to become too big with too much references.
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.
2nd iteration class diagram design for dynamic prefabs handling the GUI data from Playfab
Later on, if new deals are created, a new class will be implemented, rather than just infinitely extending one class:
Separated class for handling "Customization items" shop deals data
Separated class for handling "Currencies" shop deals data
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:
Coins (the main currency of the game)
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.
Class diagram after implementing the Sprite Provider class
Discount calculation formula
When implementing the handling of the discount of a deal, 2 problems of the design I have created appeared:
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.
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.
Deal appearing in Bulgaria, where the main currency is BGN
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:
User manual on creating and designing shop deals in Text Express
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:
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:
