Over the past 9 years in the gaming industry, I have learned a lot of different tools and used them to develop and operate games. There is no way to talk about some, some are no longer relevant: for example, building and exporting a GUI json file from Adobe Illustrator, and some solutions will be relevant for a long time.
Today I want to share a ready-made solution / tool for working with game data. This solution is suitable for any project, it can not only make life easier for a beginner project, but also get excellent results for a large project like Pixel Gun 3D, which is more than 8 years old. Accelerate the establishment of types of Game offers from 2 weeks to 3 days, and speed up the development of other features by 2-3 times.
In the article I will consider different options for solving the problem of configs, the article will be useful primarily for technical game designers, programmers and those who want to simplify their life in game development.
I gained my experience in designing a good project architecture by creating a hit project and operating it for 3 years, after leaving, there was a need to find an alternative tool that would be available to every developer, regardless of what platform he develops for project and what engine it uses.
When I came to the PixelGun3D project, the first thing that met me and what I had to deal with was 100500 GoogleSheets tablets with a huge amount of scattered data that needed to be somehow structured and form a single system and, as a result, the ability to speed up the development of the project and reduce the number of possible bugs and errors on the part of the GD.
The task was divided into 2 large blocks:
Create an architecture for centralized entity configs;
Prepare a tool for convenient work of a large number of Game Designers.
Results achieved with PixelGun 3D
Number and complexity of configs
• There were 30 different configs for different entities → now there are 7 configs with a single structure
Development of a new type of GameOffer
• Before 1-2 weeks → now 2-3 days
Development of filters and issuance conditions in different systems
• It was 4-5 days ago → now it’s 2-3 hours
Errors in the establishment of content
• Were 1-2 times a month → now 1 time in 2-3 months
• +17% due to more accurate Offers and diversity for different cohorts of Players
System mastering threshold
• There was a black box of logic and parameters where only 1 master of the box knows how to set it up. It became a transparent magic ball, with which the new June GD figured out new systems in 3-4 days
If you do not understand well what this article is about, in order to better immerse yourself in the topic of gaming data, I recommend watching my video on → DevGAMM ←
The development of tools and research took place in several stages, I considered different tools and services with which I have been working for the past few years, most of the solutions have been tested in practice in different projects.
Due to the fact that the Pixel Gun 3D project is a full-fledged operating project with a huge audience and decent income, certain requirements and criteria for evaluating the selection of “candidates” were formed, I will tell you about those who did not pass the rigorous selection:
Good for a quick game prototype and a small Unity project.
An excellent tool for getting acquainted with the basic concepts of the EAV-model (Entity-Attribute-Value) and the component system.
The work of many game designers becomes a pain if features are poorly structured. You have to constantly merge UID entities.
No online, synchronization of a single configuration file occurs only through Git.
Works only with Unity.
There is no way to split a single file into different JSONs.
The last point became the cornerstone. When the online project is huge, and every change in the settings requires downloading the entire file (unless you have your own system for creating differential configs during deployment), then the amount of traffic costs a decent amount and can become a bottleneck for the development of the project and business.
I will not focus too much on this decision, since in fact it was one of the first experiments among such tools. The ingenious developer and one of the founders of the Haxe language, Nicolas Cannasse, created it for the MotionTwin and ShiroGames studios.
Of the features, it can be noted that it has an interesting built-in tile game level editor.
We dropped this option for the same reasons as Charon.
Good service, I personally had a hand in the creation and development of this service. The main idea and architecture of the future service were laid with my direct participation.
You can read about the benefits of this service on the developers’ website, but I’ll tell you why this decision was also rejected.
Price. With huge online Pixel Gun 3D and traffic volume, you would have to pay approximately $7-9 thousand per month. This is not a key factor in making a decision, but it is definitely worth considering in financial planning.
One of the criteria and principles sounded like this: “We need the ability to quickly change data structures and banal hacks.” Still, in game development, time and iteration speed often play a decisive role, so the ability to quickly collect something from feces and twigs is a good plus, there is no such possibility in the service, only architecture, only beautiful and correct.
The project already exists and management is configured on GogleSheets sheets. Moving completely to a new service is a huge amount of work that can greatly slow down the development of the game and the release of new content.
The database with configs is stored on the Balancy side, and there is no direct access to it.
This is a proprietary service, the Bus factor must always be taken into account. If only a few people are responsible for the operation of the tool, if one of them falls out, the service may become unsupported, because. you have no access to either the database or the service code itself. In such a scenario, further development and operation of the project is blocked, which ultimately results in huge risks for the business.
Articy and Beamable
These two tools are tailored to specific tasks.
For example, Articy is made with an emphasis on screenwriters and narrators. There it is convenient to form huge stories, follow the development of characters, and so on.
Beamable is a huge combine with a lot of features, but they are all suitable for specific needs, and they did not fulfill the requirements for our task + it was quite expensive.
Solution on google sheets
I tried to make a semblance of an admin panel in Google spreadsheets using native tools. I had to take into account dozens of additional parameters, validation and other things.
A lot of time was spent on bringing the tool to a convenient form. In addition, anyone with editing rights could accidentally break something, for example: When moving columns, you can break a formula or query query if they do not respect the order of the columns.
In general, the result turned out to be quite good, but not the one that I would be completely satisfied with, especially since I had to do a huge amount of extra configuration steps for easy management and configuration settings.
Where did you stop
At some point, I remembered AppSheet – a service that allows you to set up an application on top of Google tables, synchronizes data and makes it convenient to work with them, the result is GoogleSheets + AppSheet = PineappleApplePen, if in one phrase: “All the power of Google sheets in a convenient shell.”
AppSheet has a section where you can set up and manage the display of a Google spreadsheet – UI, UX, displays, columns, options, and more. On setting up and creating a Google Spreadsheets management architecture, I hope someday I will write a separate article or make a stream.
PG3D had a huge number of ready-made tables, some of which were already suitable for use in the service, it was enough just to import and build the application.
The rest did not fit into the requirements for the structure of the database, so they had to be rebuilt. For example, the game had 7 separate GameOffer tables. After structuring configs, parameters and creating a universal system, 1 single table arose, which took into account all possible options for game offers.
This is how the final table of the GameOffer system looks like in Google tables:
The same one configured in AppSheet:
Key features of AppSheet
Validation of input parameters. AppSheet knows what parameters to specify in specific cells. For example, in the video I’m trying to write letters in the Amount field, but the app only allows me to enter numbers.
Auto-generation of ID according to any convenient rules. You want a numeric ID, you want a GUID. Maximum flexibility.
Ability to set dynamic filters.
The ability to make a reference type and specify a reference to a record in another table + the ability to make a convenient organization of localization keys.
The ability to conveniently organize the storage of tables and data. Tables can be stored in different places and have different access – in the application, all this is collected into a single system.
The ability to upload image files to any resource and conveniently view game entities.
The ability to write your own log (history of changes) and the separation of roles, who can view, edit, create and delete. In other words, your own CRUD manager.
Conveniently view and manage content from mobile devices.
The probability that the service will cease to exist is quite low. Google bought AppSheet a long time ago and has been developing and improving the service ever since.
Very, very, very flexible possibilities for creating any structure and architecture of a feature.
Flexible customization of UX and UI of the user, and control over the display of fields in different scenarios.
Another powerful advantage of such a system, if everything is set up well, is the ability to see where and at what points game items and their status can be issued.
Creation of automations for various actions. For example, you can make sure that the CEO sends a report on changes in the project to the email every day.
Can be used for any engine: Unity, UE4, Cocos, Defold and more.
There was also a minus, although it is not critical. The account that changes the data in the Google spreadsheet will always be the author of the application, so logging and separation of roles must be implemented within the application.
Free – when used by a small team in test mode.
$20 – when used through one account and creating an internal system for separating roles, login and passwords.
$20 – for each new account, if you use account access.
At the end of the article, I will share a story from personal experience. Once I spent about 600 thousand rubles of personal funds on the development of such a service and received … 🥁 – nothing. The service was written in PHP, and now the existing code is dead weight.
Good experience, but now you know the alternative and there is an opportunity to use AppSheet on any project for almost nothing.