Matteo Graizzaro

In my starting weeks, everything was new and covered by a shiny patina, there was so much to discover every day!
I started by getting acquainted with the tools the team used to organize and manage the development workflow, which were:

Asana

New tasks every day, and they are all centralized in this handy software.

Slack

Every time I had to call a colleague for help, contact a broader group of individuals, or note something down for later, I used Slack and the many chats and rooms the company had prepared for every discipline.

Sourcetree

A tool I was already accustomed to thanks to my many personal projects, but I was still surprised by the use of modules.

IDE of choice

To handle the coding I was free to choose between various software and I settled for Visual Studio Code for the server-side, attracted by its handy terminal, and JetBrains for the client.

Docker

A totally new tool I discovered during my stay at Whatwapp, is used to manage all the local server that simulates the game in various development states.

Google Meet

Hand in hand with Google Calendar, I extensively used it to meet with other colleagues and discuss all sorts of topics.

Many of these tools were especially useful during the COVID pandemic period, which forced me to stay home and experience a full-remote workflow, that later on became a hybrid with an in-person mandatory day a week.

After set upping everything I needed, I was tasked to explore a tool called Beamable so that I could introduce the rest of the team later, during what promised to be a major migration effort of the entire game server infrastructure.

The migration happened, but unfortunately not with the aforementioned tool, instead, the company decided to use another one, called Nakama, nevertheless, the time spent dissecting the game logic helped me adapt more easily and in a less long timeframe.

An exciting ride that doesn't happen every day, with new challenges around every corner, during which I was lucky to receive the help of numerous developers from the teams of all games, because we were all together in this monumental effort, consisting of understanding, adapting, reshaping, and converting code that had not been seen by human eyes in years.

As a Junior I was shielded by the Senior and Lead Developers, that took the brunt of the challenge and started developing flexible modules we would later use to code the game features, free from some of their complexities, such as currency transactions or server objects saving and loading.

Personally, I had my hands full with learning a new coding language in the form of TypeScript and using it to migrate various features, such as the minigames Candyland (a Slot Machine) and Galleon (a Match 3 game), or the club's Chat and Managing (member's promotion, kicking, etc..) systems, I contributed to the friend's Chat and Donations systems as well.
In many of these cases, I had to refactor slices of code or rethink part of it to fit the uniquenesses of the new infrastructure. This was not limited to the server, but also the client-side needed some tweaking here and there to make everything run smoothly.

When everything was near completion, we started testing the game to spot any weakness, helped by other members of the team. I cannot remember a testing session ending without finding at least a couple of edge cases to fix the next day.
Testing so extensively a game was something I had never done before, and it taught me a lot about how stressful can be the process of polishing a game, and I have now more respect for the UX and Testing branch of game development.

Once the server codebase migration ended and we could catch a break, it came the time to maintain the integrity of the source code and learn from the errors of the past. Such lessons came in the form of more flexibility via a restructure of the modules that composed the game using a monorepo configured with Nx, paired with the introduction of e2e tests developed with Jest to guarantee stability in the face of future updates.

I took responsibility for performing the majority of these changes and I authored the refactoring of many sections of the game, such as

• Candyland: A minigame resembling a slot machine, with many subsystems, unlocked daily at the reach of a threshold.
• Club's race: A recurring event that sees clubs compete in a leaderboard subdivided into leagues where the victory factor is the amount of a specific currency (a seed) getting sacrificed. The race seed changes weekly.
• Friends: Many subsystems connected with the friendship between two players, like the exchange of currency or the managing of their chat.
• Events: A flexible module that allows scheduling tournaments of different types with entry costs and segmented rewards.
• Openapp: The code responsible to rule over a player connecting to the game; many checks are performed during this action.

Thanks to this opportunity I was able to grow my knowledge of the server's inner workings.

Between March and April of 2023, my team was tasked with developing a new tournament to inject life into the stagnant experience of the game Burraco. The event would ultimately last only 3 days, but for that ephemeral amount of time, almost 2 months of work were needed to develop all that introducing a new feature entails.

This time I was entrusted to alter the existing infrastructure to fit the intentions of our Producer. Before getting to work I took care to understand how all the components involved would normally behave and to be 100% sure that no core parts were disrupted with my later refactoring I coded a web of e2e tests that would cover the normal flow and the many edge cases.

Once the time to dive deep into developing the feature came, I first used the provided design documentation to lay out a plan of intervention, which I later applied under the supervision of my Lead Riccardo Sacchi.

The fabric of the server was both solid and flexible enough to withstand my changes, and I was able to easily inject the code necessary to calculate the unique point system of this event and handle the refund for the entrance fee if a player were not able to play (due to a min number of participants mechanic).

Overall the experience taught me much about how to implement someone else intentions while keeping the codebase reliable and scalable.