Introduction:

Hyper Dash is a large-scale project released by Triangle Factory. It's a game that has had many years of development, and is the project me and the other interns started on.
Throughout my internship I had 2 main mentors, a few seniors and contact with 2 other interns and many other programming colleagues who work on the newest project, but do have experience in the older ones.
The purpose of this internship was to get experience in the industry and be ready to enter the industry as a junior afterwards.
The internship ran from February 2025 - June 2025, and extended into a seasonal work for a few months extra.

My contributions:

The importance of starting with small tasks

Some of the smaller things I added at the start of my internship were things such as a confirm button, Unity analysis and interacting with the Steam API.
These seem small but are an important step to getting familiar with the project. It taught me about how to navigate my first large codebase, applying the code standards and code style, and gave an opportunity to get feedback on some less important tasks as a prep for the bigger leagues.
It's also the first steps into working independently and confidently, a line I'll be using multiple times throughout this blog as it's the most important thing I learned throughout this whole experience on a professional aspect.
Normally I wouldn't put a whole sentence in bold, but that's just how important it is!

In-house tooling and feedback loop

I had the opportunity to improve an in-house tool that was used to display some of the skins in the game.
My ticket was to:
- Add interactivity to our display tool for skins to assign visual overrides through custom muzzle flashes and SFX
- Add buttons with popups and text fields that create layered folders with proper naming conventions to have the new system easily premade setup for artists.
- Apply a constant feedback loop and iterate on the tool and its new features.

The most important thing I'd take away from this is that tools and their documentation need to be made with its target userbase in mind.
Artists loved visual details and info so throughout the process I learned to adapt documenting in a style that uses a lot of colors and icons, minimizing the use of text.
The parts for programmers could be more to the point and with longer texts. The most important thing to take into account was to constantly do a feedback loop and ask them to test it during the process.
I gained a lot of experience using Unity's C# side of its custom UI and how it manages its assets.

The Interactables, My first Herculean task in my programming career

Prototyping

Starting on this task I was assigned to make a first prototype of interactables/toys. These are 1 and 2 handed instruments and playthings that can be swapped to from weapons.
I made an action plan with some key features that should be focused on:
1. Weapons are picked up, never actively swapped to. We don't have a menu or a system to stow weapons and take them out
2. HD does not have a 2 handed system and some interactables needed this
3. Networking in HD uses an older system that nobody has worked with in recent years, forcing me to do this mostly alone, with guidance on principles of networking and not on application

All three are quite big and a lot of responsibility but I loved the challenge. I'll go over the process in the following sections.

Regarding prototyping itself, the biggest thing I learned is to iterate fast and its okay if it doesnt work immediately.
I'm too perfectionistic and want too many things at once. I needed to subdivide my own tasks and goals, and test every step of the way.

The Interactables Manager and the usefulness of patterns

My first big step after testing some instruments and getting the greenlight was making a core system that could swap instruments and support them in-game, using menus, over the network.

An interesting pattern I applied was to use Dependency Injection.
The system needed to work online and offline, where one interacts server-authorative to prevent the useage of unowned interactables through cheats.
I created a manager that can take the general input of a player and sent it to a base version of the interactables manager.
The online version did various safety checks, used networked variables as efficiently as possible and kept the actions of the interactables server-authorative.
The local version would have its own set of variables and could just blindly use them as it was only used in single-player and for previewing in the menu (also a new system with guns getting this feature too).

The most important achievement here was to fully remove the networking dependency of interactables. Edge casese were properly handled and only the manager had to know what had to be sent and received. This allowed for fast iteration of all the new interactables and a sustainable system
It was a big challenge to set up a system so large, having to take into account many things such as making weapons stow away and being able to be put back, having a generic enough base interactable to support instruments, confetti guns, and still have it be expandable for the future.
The most important thing I learned in this part of the project is how to apply patterns, and keep it expandable. I've done these things in uni, but of course it's different if the system has to interact with so many other systems.
It was important to draw and map out the classes before making them to run into a minimal amount of problems, and to constantly communicate the state of how its going to my lead, good or bad.

Networking, legacy code and the love to learn

Networking was definitely one of the biggest challenges.
We didn't get taught anything networking related at Uni, so I was unsure about how its applied, and its good practices.
The thing that will stay with me the most is that I calculated time to learn into the ticket's total estimation.
I had to learn both the basics and nuances of server vs state authority, how to minimalize and package networked data, how to do server-side checks, and much more.
It was amazing to have a codebase with some networking implemented, but there were basically no colleagues who remembered how to interact with the networking system in HD.
I took a day to plow through the documentation of Bolt, made notes about our own implementations and habits in networked code, and went over these with my lead.

I could build up expertise.
I was already the sole person working on this large ticket, and at the point networking was done, I was both the expert on the system and networking as a whole in HD.
It gave me pride and confidence, and I got the chance to involve my other fellow interns in the project.
While I could tweak the system to the new things we needed, I could tutor them on the networking so they could apply it on their own, and assign them to the interactables themselves, continuing on my prototypes.

The weight of responsibility, the good and the bad

A very important topic I want to talk about is responsibility.
I had the chance to somewhat work like a lead in this part of the project which taught me an enormous amount.
It pushed me to learn how to truly subdivide tasks in the most optimal way. Not just for myself but also for other people.
My insights on building larger systems from scratch and how the pipeline for that should go was something I could only theorize about before, but I got to experience both the start of the project and the inclusion of others.
I've always been proud of my work and try my hardest, but I was pushed to my limit here in a very positive way. I got the space to experiment and improve, while getting guidance on deadlines and aiming for goals.

However, the thing that will stay with me the most is the pressure it brings to the table.
I love the workflow at Triangle, theres solid sprints being set up, and you're being guided through it... but this was definitely a tough period as a programmer.
I had no direct colleagues for a while, worked on this ticket that was taking up weeks, but I was making good progress.
Delving back into my past as an Occupational Therapist, I got to self reflect a lot and set up a different work-ethic and mentality for myself. I had to realise that it would take a while as big projects do, but I also had to step up and talk about any problems that came up.
It changed me as a programmer as I started realising that problems in a project are natural. They're not necessarily my fault, but they are my responsibility.
I developed a stronger resistance to work stress, and got a more realistic outlook. We handle problems as they come and avoid them by preparing.
Plan, Communicate, Plan, Continue is my new motto and even though I'm alone on a big ticket, I'm not alone in sharing ideas and implementations.

There's also some important pitfalls here to note! I wasn't included in a lot of meetings which felt very frustrating as I was the sole programmer on this project. Expectations were sometimes mismatch with how communication was interpreted, and plans had to shift dates sometimes.
If I'd be in this situation again I'd voice my problems stronger and try to put my foot down more. It's very hard to do as an intern, but it's important both for the project and me as an employee.

What did I learn?

Personal

1. Working in a team is a humongous strength, and communication is the tool to make it the strongest it can be
  The codebase could sometimes be messy and not everyone knew about everything in the project, but you could (and should) still always ask for help and guidance. Leads and seniors are there to guide, but do put in suficient work before you ask.
2. Think end-goal related
  This is something I still try to work on. I need to get to a finished ticket, and sometimes corners have to be cut. There's a realistic time-frame for it to be done in, and not everything can always be done.
3. Having a strong voice is good
  As a programmer, junior or senior, you're there to give opinions and thoughts. You won't get shot in the street for speaking up, it's expected. I've grown stronger and have less fear in talking up and voicing thoughts. Systems can sometimes change, and implementations can be (sub)optimal, and the space needs to be safe to discuss these things.
4. Applying my people skills in a lead-like role
  I've got a lot of experiences in different teams, but it's my first time assigning tasks to others and making the calls. My future goal will always be to become a lead in a project when I'm ready for it, but it was reassuring to having experience with the responsibilities in this role and it's given me confidence in myself as a person!

Practical

1. Networking
  Something I got to somewhat specialize in in both this project and Breachers. I'm very happy to have been able to delve into it myself as it's taught me how to tackle learning these big new things.
2. Delving deeper into patterns
  Patterns were something we often used in Uni, and I've used it in personal projects as well. There were however so many ways to approach the interactables system, and I wanted it to be a pragmatic choice. Research is important even if patterns seem well-fit for the job, and
3. Getting a strong understanding
  HD gave me the chance to hone a lot of basic skills and using a ton of programs to a solid level for future endeavors. An example is GIT, I could aways use it but now I've gotten confident in how I should use it and a deeper practical understanding on how to get the most out of it.
4. Learning how to make in-house tools for Unity
  Making in-engine tools was an awesome experience and something I could consider doing as my main focus as a programmer! It's got a lot of considerations in small decisions and being goal-oriented, which is something I keep striving to get better at.

Relevant Links

- Hyper Dash Meta Quest
- Hyper Dash Steam
- Triangle Factory Website
- No direct code snippets as I'm under NDA. Do feel free to ask me about general implementations regarding these topics and any coding related questions are of course also welcome!!!