Noid: Unannounced game
Website:
​
Genre:
3D Adventure Game, Multiplayer
​
Platform:
iOS, Android
​
Contribution:
Tech design, Gameplay, GitHub
Tech Design
We were developing a multiplayer 3D adventure game targeted toward a younger audience. The project was cancelled and never announced.
​​​
Pipeline between developers and designers
As a tech designer, it is important to be able to communicate with the disciplines that build up the studio. ​At times, there may be a discussion regarding features that were required to be created by the developers, from the design team. In order to make sure that all stake holders were on the same page, I participated in design, developer, and feature meetings.
A way to make sure that features were continuously communicated was by writing design documents and flow charts. Since the features were evolving with development, keeping the documentation up to date was crucial.​
​
Interactable prototypes
I had the opportunity to work closely with both designers and developers in order to prototype interactions and activities. A wide variety falls under this flag, as it could be as simple as click-to-animate or more advanced with interactions setting in motion events and changing states of the in-game environment and it's objects.
​
Navmesh
Navigation with the use of the Unity Navmesh surface, obstacles, and agents system was on my table. I created a system that would aid the player by navigating them through certain areas. This system affected in-game character behaviour and animation states.
Here's a video of similar navigation made for research purposes, using Synty assets.
​​
​​
​​​
​​
​​
​​
​​
​​
​​​​​​​​
Icon generator tool
A colleague and I created a tool to create inventory icons for the game in order to simplify and speed up the process for artists. The icon had the option of taking specific assets with an attribute, create and place the new icons in the correct location in order for the icons to be shown in-game.
​​​​​
GitHub: Branch health and merge testing
We had weekly playtests of the game and its features. It was my responsibility to make the necessary preparations in order for the team to playtest. I made the build and tested it to see if it was functional or not. If not, then I communicated to the feature owner regarding the issue. If time allowed, a fix was merged and a new build was made. Before merging we tested the changes before they were added to the main branch. We did this in order to make sure to not add further issues. As I was the one preparing the playtest build, I took the opportunity to check the updates that were waiting to be merged.
​
Many things can happen when working with version control which is why it was important to have daily communication with the back-end developers regarding Git and the state of the project.
​
Creating a Release Build
As part of being responsible for playtest builds, I was also tasked with making production builds. In order for the game to be presented in the best way, these builds were made sure to contain as few bugs as possible.
I worked closely with QA to test the daily production build and look for bugs. I was in constant contact with one representative from each discipline, who were tasked with communicating any bug fixes needed.
It was important to maintain the communication so we could meet the deadline of each benchmark. We did not miss a single one.
​
The state of the production builds were communicated to the board and stake holders.
Bonus
Noid invested in my coding skills by purchasing C#-courses. This increased my understanding of the project and the code dependencies, which made working on the project even more interesting.
I had the opportunity to collaborate and learn from our sister studio, Toca Boca, where I also gained the Toca Boca Certification for playtest with kids.