My work

  • First role as a Technical Game Designer.
  • Created abilities, weapons and enemy characters, according to the vision and specifications of combat designers.
  • Worked on data structures and created tools with VBA Excel and Python to handle data and speed up production.
  • Owner of the technical implementation for the UI and UX combat elements.
  • Designed and worked on prototypes for the creation of interactive elements.


Project specifications

  • X-COM-like turn-based strategy
  • Single player Switch game
  • Exploration-based overworld with combat encounters
  • Base game + Multiple DLCs released
  • Made in Snowdrop

Ubisoft Milan was my first role in the AAA industry and the first role I had with “technical” in the title. I started as a Junior Technical Game Designer and was eventually promoted to Technical Game Designer. As it implies, my time at Ubisoft Milan was heavily technically oriented: most of my work was about creating content, systems and design features directly in-engine, while the design side of it was often delegated to specific designers. This does not mean I never worked as a game designer, but in Ubi Milan it was definitely a secondary role for a TD. The organizational structure allowed me to work in several feature teams – for instance, combat, UI, UX, and more – as it changed over time, depending on the needs of the production team. For example, when I worked on the DLCs of the game I moved to support level designers with environmental interactions.

The main tasks for Technical Designers in Milan were:

  • To be the bridge between code and design.
    • We were required to understand principles, terminology, and techniques used by both programmers and designers.
    • We were expected to provide Game Designers with the technical information that allowed them to work on new features based on limitations and capabilities.
    • We proactively designed systems and solutions to be open for future customization that was not even considered at that time.
  • To prototype quickly and iterate even faster.
    • We had to account for temporary solution to become permanent if necessary and to work accordingly.
    • Priorities changed quickly, so we needed to be ready to switch from one feature to another, to understand the underlying structures as soon as possible, and to be able to pick them up even if we never worked on them before with as little guidance as possible.
  • To support the production with personal initiatives, if we wanted to and if it did not interfere with the main tasks.
    • We worked on custom tools (VBA, Python, etc) to expedite production when possible.
    • We were encouraged to design features and were able to produce prototypes to present to creative direction.

Listing all the specific things I worked on during the development of M+R would take a much longer post, because, as explained above, it was normal to jump from a feature to another and getting involved in several feature teams in some capacity. To sum it up in a brief list, I worked on:

  • Character creation: I was tasked with creating enemies with several abilities and different attributes, implementing them in the engine.
  • Player Progression: I worked on the progression of each character and the unlocking of abilities, weapons, and the likes.
  • Ability creation: one of the first things I worked on were the titular Sparks, which acted as supporting characters granting different abilities when equipped to a character.
  • Quest progression: both on the base game and the DLCs, I worked on the interactions and the quest logic to progress in the story.
  • UI and UX: the system to display AoEs, projectile trajectories and other preview data was a major contribution of mine. I worked in a feature team with designers and programmers, and together we created the whole combat UI.
  • Bugfixing: Everyone’s favourite tasks. Ubisoft Milan worked on an unstable main version that was cyclically frozen to allow heavy bugfixing sprints, which usually occurred before major milestones.

Overall, working in Ubisoft Milan was extremely important for my professional growth. I learned how to adapt quickly and to work in tight deadline with a big-sized team. Unfortunately, not everything went well in the project, many issues stemmed from the studio composition and mentality. To name a few problems:

  • While the TD team was pivotal for the production, there were only five of us. Time was allocated inefficiently because of this, so that when the production crunched, it produced a lot of pressure on few people, but the situation was not much better when the production followed a more relaxed schedule.
  • The production followed a “design-first” approach to game development. The design of features was supposed to be paramount and bending the designs to technical limitations was kept as a last resort, no matter if there was a similar, easier-to-implement design within technical constraints.
  • Although I had a Game Design background, I was thrown in the production with no onboarding or mentoring about the “tech”-side. I spent most of my free time studying autonomously to close the gap with other Technical Designers and even then, I had to learn on the go. While I learnt a lot through this approach, having a few weeks of mentoring would have avoided many mistakes that came with not knowing how the already-implemented systems worked.

In any case, at Ubisoft Milan I met some great colleagues and friends, and learnt so much it would fill a book. I cannot help but feel grateful towards by former group of TDs and the Lead: they were all masters of their craft and working with them incredibly helped me become a Technical Game Designer.