INTERNSHIP
INTRO
To finish my studies I had the chance to work at Ubisoft Annecy on one of their most iconic titles : Riders Republic, I arrived in the Technical Design Team during the season 8 that welcomes the new big addon of the game : Skate.
During my internship the goal was to I handle some new features, create some tools to check the quality of the actual content, be a link between the different teams to make the communication easier and help for the the expectations and constraints of them.
FEATURES - LIMITED MODIFIED EVENTS
Quick Presentation
In Riders Republic, we have a special type of events that are accessible for players without downloading any update, those events can be played during a certain range of time. They are divided in 2 categories :
LIVE EVENTS
Live Events are the same quests than them you can find in the game but developers have modified some settings in them to create a new atmosphere in the race (number of opponents, the vehicle used for the race, the score limit, the weather etc..)
LIVE AREAS
Live Areas are new quests created by developers, player has a forced gear, he can test it freely or with a score to reach depending of the objective. The goal is to introduce to player new gear Live Areas have also some modifiers.
HOw it works
Those events are not directly modified in engine, they are modified on another online tool that communicates with the it. This tool allows to developers to easily change settings exported by the engine, after modifications, those settings are injected into the engine and override the default ones.
MY TASKS
My tasks consisted to add new modifiers in the online tool requesting by game design team and handle the implementation in the engine
1 - Force the music for Limited modifier EVents
Game designers wanted to force a music during Live Areas and Live Events, we were already being able to put a special music in the quest definition but the goal here was to set this parameter in the online tool, each music is part of a station (as a system with a playlist that contains tracks). Designers wanted to put a specific music or a specific station and allow to player to changes it or not.
2 - Force Outfits for Npcs in Live Events
As I mentionned before, we were able to set the number of opponents in Live Events from 0 to 11. Game Designer wanted for each ghost to be able to force a specific outfit directly in the online tool. The goal was to contribute to create scenarios in Live Events by changing the original opponent outfit by a new one.
Workflow
For those two tasks I had a similar workflows that is explained below :
Create a Technical design document
The first step was to create a document to propose a design of those parameters in the online tool, this document had to summarize what we already had,what we need and what will be the team implicated in the development of this feature.
For this feature, we had nothing regarding the music/station in the tool so we need to design a new section in the tool and plan for the exportation of the music settings from the engine to the online tool
For this feature we already had the possibility to force the outfit of the player in the online tool, so the section already existed, so I just reworked a little bit the design of it. For the export side, we only had the exportaion of the number of NPCs but nothing regarding their outfit because this feature what not handled at all in the quest.
So we had to create a new parameter in the quest itself and asked to GPPs to update the operator that handled the NPCs to allow it to take care of the outfits of each opponent.
Once this document was validated by the technical design team, I presented it to the people that will handle this feature. The gameplay programmer team and the online team.
Follow the avance of the devlopment
This step is more a step of support for the others team, the goal was to be sure the correct settings were exported from the engine to the online tool. Be a reference point for the tool team that implemented my design in the tool. Be here if anyone had a question and make the connection between gameplay programers and tool team. In the mean time, let the designers know what was the advance of the feature.
For the music, follow the advance of the music/station exportation from the engine to the online tool and be sure the design of the step one was applied to the tool.
For the customisation, as well as following the advance of the design in the tool I also had to follow the update of the operator mentioned in the step one and how it will impact the rest of the quest, and then we were sure everything works on the update side I had to follow the exportation of the new parameter created in the quest.
Inject the new settings in the engine
Once gameplay programers export the settings in the online tool and the online tool team implements the design of the parameters, I had to handle on the data side the overriding of those new parameters in the quest and test if everything was working
In this case the injection was easy because the parameter already existed in the quest, I only had to be sure it was correctly overriden by the one of the online tool, I updated the quest to add the injection of this parameter.
In this case, that was a little bit more complicated because, I had to create the new parameter to data side and update the script that handled the creation of the NPCs by connecting the new parameter to the target operator
Submit this feature to Game Designers
Once the feature is well implemented and tested, I prevented the Game Designers they can use it and stay at their disposal if the had a question about it.
INSTANTIATE TOOL & QUALITY CHECK TOOL
Quick Presentation
At Ubisoft we have some other tool that are developed inside the engine. Those tool are handling in C# and for the two next exemples help the designers in the creation of content.
Instantiate Tool
The instantiate tool allows to developers to create world elements necessary to make the quest working, this tool makes the link between those element and the proper setup of them. The tool is alimentated by script that are created in C# and runned in the engine.
Quality Check Tool
Quality Check Tool has a first version in the past and I had the chance to welcome the new version during my intership. The objective of this tool is to run a list of specific tests (related to each quest definitions) to test is everything is correctly setup. In the new version you can select different type of quest and know in few clicks what is not correctly setup in it. For each thing wich not properly setup a confluence page is linked to the asscociate test to make the correction easier.
MY TASKS
My tasks consited to add or update scripts for those tools
1 - Update starter Content/Balloon Templates and the Script
To start the Live Areas, player interacts with the starter content, this element had, in the past, a visual of balloon in it. For optimisation reason we decided to split the starter content and the balloon, but the problem was the visual of the balloon had some internal linked with the starter content. So in this case we had to update a script that is runned after the instantiation of the starter content to spawn the balloon, placed it in the world and make all the linked between it and the starter content. I also made a little rework of existing methods in the script.
2 - Add a Script to check Live Areas on the quality check tool
In the Quality Check Tool, we wanted to be able to check a maximum of quest classified by type. I was in charge of the Live Areas so I had to create a new script that check all it was needed in this type of quest.
Workflow
For those two tasks, once more I had a similar workflows that is explained below :
Organize the general structure of the script
The first step is to think about the structure of the script, to do that we can inspire from the already existing scripts that are checking similar thing. I also consulted the other members of the team to have some key to make a proper structure.
In this case I started from an already existing script so the structure was already here, I just reorganized a little bit the methods and the time when they are called.
For the quality check script I had to start a new one from scratch, first I listed all the things I needed to check, to do that I am gone in the quest itself and get the elements and variables that are mandatory to make the quest works. After that I created, in the script, the usefull methods I needed to get elements and variable inside the quest.
Write a first version of the SCript
Once we had a structure of the script, we can start to write. But for that we needed to know how and where get the information and elements we needed. To do that I contacted the tool team that was in charge of creating those tools and know what was the process to have access to each element.
For the instantiate tool, I wrote the instantiation of the balloon part, I contacted tools teams to have some information on how to access to balloon properties, in the mean time I worked closely with GPPs because they were making an update on component in the balloon which was impacting my script at the same time.
For this one I wrote the script entirely and contacted the tools team when I didn’t know how to access to an element. By the same time needed to think the script as more generic as possible to maybe reuse some methods of it for other checks for example when I wanted to the same properties in multiple object, I created one function and inside it I managed the specific cases. The goal is to make the utilisation of the tool easier when I was setting up it in the engine.
Test the script
This part is done in parallel of the writing of the script, the goal is to test every part of the script, try to break it.
In this case, when user started to run the script he needed to select some element in the resource browser. But user could cancel the action and by extension the script, in the case I needed to be sure element that were set up in the script, were deleted. When the script finished running, I selected elements spawned in the world and check if they had the proper setup, then I checked if the new elements were putted in the right folder.
Those scripts were a little bit different, the goal was not to set up things but to check if things were correctly set up and be sure the correct message was displayed to the user. I also needed to be sure, when a script returned an error message, the element was not correctly and it was not a specific case of a quest. In the other case, be sure if the message returned a success, the element was really well set up and it was not wrong setup missed.
To go further, I was intentionally making wrong setups to be sure the script detected errors and displayed it correctly.
MAke A review of the Script
When the script was written, we made a review of it with other members of the team, during it I explained step by step what I was putting in place and why used a method at a place and basically how the script is working. The goal was to be sure the script was correctly written, I missed nothing and find another way to optimize it if it’s possible. After the review, I made a rework regarding the feedbacks and repeat the operation to obtain a robust script.
Submit the script
Once the script is validated by the team, I submitted it, prevented the GDs that will use it and stay and reference point if they had any questions.
Thanks
I would like to have special thanks to Ubisoft Annecy to welcom me during four months and a half in the studio for my internship to lettings me enjoy a very pleasant working environment.
Thank you very much to all people that I loved work with and especially to the Technical Design team with which learned a huge amount of stuff.
Thank you all !